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 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!

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!