So there is the LGPL, which might be a good choice for my libraries, but has similar restrictions to the GPL that I simply don't want to require people to adhere to.

I then found the CDDL, and I really liked the way it was written. It's unfortunate that it's incompatible with the GPL or it would be my top choice for pretty much everything. But it's not compatible, and I don't want to keep my software out of the hands of developers of GPL'd software.

None-the-less, the CDDL is one of the few file-based open source licenses, and one of my requirements for some of my software is that I need to mix in some commercial libraries which are obviously not open source. The best answer might be a dual-license model, but as far as I can tell, I wouldn't be able to mix in proprietary code with a GPL license, so the GPL version of those products would need to be severely crippled, which might not make sense to do at all.

The only course I can see clearly working is releasing the following:

• For libraries containing only open source code, dual-licensing the CDDL and LGPL (allowing GPL developers to choose the LGPL license, making it compatible)
• For applications containing only open source code, dual-licensing the CDDL and GPL, for the same reason as above
• For libraries or applications containing open source and proprietary code, licensing only under the CDDL is the only option. Nothing compatible with the GPL can contain proprietary code in my understanding.

For this reason, I will try to keep as much of my code as possible in the dual-licensed projects and available for all open source developers. However, many of my applications themselves will be mixed in with proprietary code, and this will be released only under the CDDL (with the proprietary code released under its own license, all fully documented).

Of course, all of my past work up until this point is still available and can continue to be used under the MIT license it came with. Most of my future code, however, will not be released under an MIT license. None-the-less, if you opt for the CDDL license on my future projects, it has the handy addition of allowing you to mix it in with any proprietary, closed source code that you want, as long as you keep the original code and any modified files based off of the original code under the CDDL.

Due to all the confusion and incompatibilities surrounding the current crop of open source licenses, I was very tempted to simply write my own. But that would just add to the confusion, so the best choice right now seems to be to play along while being as open as possible.

I will be sure to fully document on each project homepage the licensing model of the project and what it means for others wishing to redistribute the source code.

Related articles

• Is Copyleft Really Right for Open Source? (intridea.com)
• My take on open source licenses (spf13.com)
• Why the GPL Matters (avdi.org)
• Why Open Source misses the point of Free Software (gnu.org)

The functionality will include the ability to manage the entirety of a business or individual's web presense, from domain names and websites to providers, datacenters, servers, and more. Manage them all in one place and interact with them in intelligent ways--get renewal reminders, login links to all services, relevant contact information displayed on related pages, and much more.

This project came about because I was tired of having to manage my various web assets in all different disconnected places--my registrar for domain names, my various hosting providers and control panels, all of my websites, pages, and projects around the web, and more. It was all just getting to be too much, and while there are a lot of organizational tools, none of them seemed to be designed for this specific type of management. In this, I saw a way to make something that works better for me.

The project is built with CakePHP 1.3, the MooTools Javascript framework, and the MochaUI interface to give users a full desktop-like experience on the web.

I am not sure yet what different versions I will offer, and whether this will be a locally-hosted product or SaaS (Software as a Service) hosted and provided by the Digital Empire. Only time will tell, and I should hopefully have some screenshots and more information posted soon.

If anyone is interested in assisting with FOMS, here are the things I most need assistance with:

• Vector graphics - preferably in .xaml format (eg. MS Expression Design), but  .ai (Adobe Illustrator format) is fine too.
• Icons - FOMS has one icon -- it needs more themed icons for its various components
• Website work - falloutmodsorter.com needs a lot of work on its theme (css and graphics), and a webmaster or maintainer who can help me keep content fresh, manage the "community" (non-existent so far), etc.
• Marketing/advertising - FOMS 2 is open-source and will always be free, but we still need to let people know it's out there--without a large user base, FOMS can never grow to the one-stop Fallout 3 mod sorting application it could be.
• C# and/or XAML (WPF) coding--I'm currently doing everything in this field, but it is taking up all of my time and not allowing me to focus on any of the other aspects of the app (see above)

On another note, plurliquid is doing a great job on the new template so far, and it will make its official debut in FOMS 2 Alpha 2. This has given me a lot more time to work on the backend and get FOMS ready for the next release.

You will be seeing the new release very soon (as usual, several weeks late)!

Regardless, I’m doing it… here are some status updates:

• DOM Level 3 Interfaces: complete
• DOM Level 3 Core Module: complete (in testing)
• DOM Level 3 Load and Save Module: in development (waiting on SAX parser)
• SAX 2 Interfaces and Core Classes: complete (in testing)
• SAX2 XMLReader Implementation: in development
• File class (with Windows function wrappers): in development
• File Stream Support: in development

As you can see, there’s a lot to be done—but just having the core DOM complete (per se) is enough of a driving factor to keep me going with everything else…

The XML parser (XMLReader implementation) is turning out to be a bit complex, however.

I’ll post links to documentation and discussion as they become available.

Now that I'm back at work again, and actually working from the office, I'm anxious for the weekend to get here. I have a lot of work to finish up.

FOMS (The Fallout 3 Mod Sorter) is being rewritten, as I've said, and as a prerequisite I'm working on completing my DOM implementation in AutoHotKey. Expect that next week, and hopefully a new FOMS version shortly thereafter.

After that, and several other currently in-development AHK classes, hopefully my heavily-neglected SteamWin and SteamLab rewrites will be underway.

Look for more news about that soon.

The problem is that many scripters don't have a good grasp of what OOP (Object-Oriented Programming) really involves, and admittedly it can seem like a daunting concept to the newcomer. This short explanation and tutorial will explain exactly what OOP means, and how to use it in everyday scripting tasks.

--

What is an object in real terms?

The short answer: anything and everything

I like objects. The world is built with objects. In fact, you could think of every single thing in the world, including the world itself, as an object. In fact, this is the basis of OOP. It is modeled around the concept of objects and their interactions with each other.

Look at it this way: The screen you're reading this on is an object; so it its Power button. So is the chair you're sitting in. You're an object, and so is your nose, and your left thumbnail. The ray of light that is (or was) shining in your window is (or was) an object. That car driving by by was a passing object. So were its wheels, and its left fender, and its passengers. Each rain-drop, snowflake, or ice-ball falling from the sky is an object.

Factories manufacture objects. But the factory itself is an object, too. So is each piece of machinery used to create the objects, and each of the workers that run the machinery. The ground the factory is built on is an object, and the whole planet itself is an object, along with each of the other planets, stars, and space debris out there. Hell, you can even think of empty space as an object.

But if they're all objects, what makes them different?

The short answer: attributes

Simply put, each object has certain properties, or attributes, which describe it. For this document, attributes and properties can be considered the same thing.

Think about a person's attributes. They might have brown hair--that's an attribute (a property that describes them). Their hair may be long--that's another attribute. They may be generally nice (a property that describes their behavior). They may prefer a certain brand of clothing, or enjoy a certain type of food. They might have high aspirations for the future, or think that we're doomed because of today's financial crisis. Those are all properties which describe a person.

Every object has properties. A car has a color, a shape, a number of cylinders, certain features are either available or unavailable in certain models... the list goes on. The planets are round. The sun is bright. The sky is blue. The winter wind is cold. The rain is wet, and transparent. Every object can by described by listing all of its properties.

Obviously, for real world objects this list of properties can be ridiculously extensive. In programming terms, it is usually manageable. But this is how objects in OOP are described.

If you have an Invoice object, it might have the following properties:

• seller
• buyer
• items
• subtotal
• tax
• shipping

Notice that most of the things you would normally see on an invoice are there. That's because they're part of the invoice--they describe it. That invoice wouldn't be that invoice if it didn't have that exact seller, or that exact buyer, or subtotal. That's what makes it a unique invoice.

But not everything on the invoice is necessarily a property. Notice there is no total property defined. That's because the total changes depending on other things--subtotal, tax, and shipping. Since you already know those three things, you can instead instruct the invoice to add the three fields together and calculate the total. We'll cover that next.

So you have all these colorful objects, how do they actually do what they do?

The short answer: methods

Your neighbor's drive to work every day is a method, or function. Their car merging into another lane in traffic is a method. Every action performed anywhere can be thought of as a method. In fact, often the term action is used instead of method, which makes the concept even easier to understand.

Every object has (or doesn't have) one or more methods (actions) it can perform which allow it to do what it does.

When you walk to the store, it could be described in programming terms by a call to a mythical walkTo("Corner grocery store") function. The sun might be performing a shineOn("Earth") function right now, just as the earth may be performing it's rotateOn("Axis") and rotateAround("Sun") functions at this very moment. NASA has been performing a goTo("Mars") method for an extraordinarily long time.

You see, a method, or function, could describe every action performed--anywhere--by anyone--ever.

This is how objects in OOP perform actions. Let's take our Invoice object example from above. It needs some actions, too:

• calculateTotal() - this will figure out the total to print on the invoice
• send() - This will send the invoice

So what the hell's a Class?

Think of it as a template for a single object. A wrapper that describes a generic object. It defines what properties an object has, and what methods an object can perform.

The class is how your program or script and make use of the object. For our Invoice object, we would have an Invoice class that defines what an invoice is.

When your program creates an invoice, it might look something like this, in pseudo-code:

myInvoice = new Invoice

We now have created an instance of the Invoice class, meaning we have created a new object that represents a single Invoice. 

Now, let's set the invoice properties:

myInvoice->seller = bob smith
myInvoice->buyer = gordon freeman 
myInvoice->subtotal = 10.00
myInvoice->tax = 0.00
myInvoice->shipping = 5.00

The invoice is no longer a generic invoice. This is now a unique object that has the properties youv'e given it.

So now you have an object sitting there. How do you use it? You access its methods. Again, in pseudo-code, you might do something like this:

myInvoice->calculate() - determine and save the total
myInvoice->validate() - make sure the invoice is proper
myInvoice->send() - send the invoice to the recipient. 

Normally there would be more, and more useful, actions than this, but hopefully you get the gist.

Is that it?

That can be it. With that concept of objects, you can start with a tutorial in your OOP language or package of choice. There are many, many more advanced topics to get into, but that is for you to discover as a new Object-Oriented programmer.

So go program with objects, you object!

Links:
FOMS on Fallout3Nexus
FOMS Wiki
FOMS Trac site (Development and bug tracking)
FOMS Source Code (SVN)

Current major beta release is 0.5.0, which support mod sorting, conflict and dependency tracking and resolution, user messages, backups, and more.

Coming soon: GUI and tray features, a Backup manager and Template manager, and more!

Unfortunately I don't have $295 available to purchase an Indie license, which is what I'd need. Maybe after the holidays, I'll be able to start saving up for a license. I just hope it doesn't take too long, dammit!

I'll report any caveats I find during the upgrade process here for others if interested; I don't anticipate many problems, however, as I am not using deprecated functions and I believe my code is clean enough to track down any inconsistencies quickly.

Here's crossing my fingers, and hoping that the upgrade to RC3 brings the promised speed improvements to my projects!