Open Source Demystified

INTRODUCTION:

What is the first thing that comes to your mind when I say Open Source software? Could it possibly be "Free source code" or "Free Software Foundation"? The first thing that comes to your might night not be licensing schemes and protection of code. Yet just like regular copyrighted software, There are many things that govern what can and can't be done with source code from any Open Source software. Added to that the overwhelming number of recognized Open Source Licensing scheme and you have yourself a plethora of questions that come to mind. Issues to resolve, what you really want people to do with your source code is ultimately up to you. However there are guidelines and goals that you can use as the tools for evaluation a given opensource licensing scheme.

The goal of this article will be to first attempt to clarify what exactly Open Source Licenses are all about. But we will also be looking at what you can think about when defining what you want others to be able to do with the source code of your project. Once we established this, we can then take a look at how to compare your criteria with those found in the recognized Open Source licensing schemes so that you can choose the one that matches the closest your own specifications.

WHAT IS OPEN SOURCE SOFTWARE:

To best define Open Source Software is to use Richard Stallman's definition. IN essence, if a software project is to be open source it should give the users of the program 4 distinct freedoms. Here are these freedoms as stated on the Free Software Foundation website itself.

• Freedom 0: The freedom to run the program for any purpose.
• Freedom 1: The freedom to study how the program works, and adapt it to your needs.
• Freedom 2: The freedom to redistribute copies so you can help your neighbor.
• Freedom 3: The freedom to improve the program, and release your improvements to the public, so that the whole community benefits

Of course the Free Software Foundation encourages and supports free software. However, as you can see here, there is nothing that specifically states the program (or any alterations) have to be free as well. Now when you look at these 4 freedoms you need to look at them from the author of a project's point of view. If you write a program, any program or game, and you want users to be able to do all 4 of these freedoms, you can consider Open Source Licensing.

The bottom line is that Open Source doesn't "have" mean Free Source. You have every freedom to create a program (even a commercial one) and distribute the source code to it with your compiled binaries. Most closed source projects entails that if the purchaser of the closed source program needs a modification brought to the program they would typically contact the author of the program and negotiate a deal to have these alterations done to the program. Open Source in a commercial environment would mean that since they have the source code they could decide to bring the changes themselves (or contacting you if they don't have the competence to bring the changes they need to make). But at least they have the choice, the freedom if you will. Besides, well written code distributed with a project is a great side of confidence on the part of the creator and is starting to be quite noticed in both the open source community and the corporate world alike.

OPEN SOURCE LICENSING SCHEME:

Now that you know what defines an Open Source program, let's Assume that you have a project with which you want to allow the four freedoms described above. It's a pretty safe bet that all Open Source Licensing schemes will give the four freedoms above to your project by definition. This means that no matter which licensing scheme you pick the users of your program will be able to read the source code, modify it and distribute them. Thus what remains is what I like to call the aftermath or the consequences of given licenses.

Basically, the main area of discrepancies between the licensing schemes seem to revolve around the fact that open source code should be distributed with your program or not. Some specifically want you to distribute the source code of the program or library with your project that uses it even if your project is a closed source one. Others tackled the subject and seem to give you the freedom to distribute the source code or not with your project. Personally me, anything I write as open source I like to give the freedom to do anything anyone wants with them the question is, is this always the best practice for open source software? Probably not.

The main reason I say probably not is because ultimately allowing the user to put your open source code into a closed source project could cause a grey area in the future. The main reason I typically allow this is because if you are creating a professional application you might now want to send your users to different places to get this and that part of your program, you'd like to give the an installation that they run that includes all that's needed and installs as easily as possible. Some Open Source licenses make this "freedom" very difficult to achieve.

OPEN SOURCE AS A RECOGNITION TOOL:

Aside all the legal issues of licensing software, Open Source Licensing schemes are also there to recognize the authors of the work done. This includes both the original creation as well as the modifications brought to the code. It's a great tool (when used adequately) to document the history of the code based being studied. So when you see that more than one author worked on a particular code it can indicate that the code is good and very refined. There is a limit however. IF your modifications end up modifying the whole program (read a completely new design to perform the intended functionality) then claiming it as your own is allowable since it's 100% your code that merely got inspired by the other code you looked at.

It is also useful for knowing who to contact when a very specific situation (or problem) occurs. AS you know Open Source is a voluntary effort to produce code that others can see, read, learn from and use and as such, some of them can have a long list of authors who brought modifications to the code in very specific areas. It's common knowledge that the author of the code (or the specific modification) is typically the best qualified to bring changes to it or answer questions you might have about it. Hence, this practice is a tool to recognize who did what work on a given Open Source project and a great reference tool to know who to contact about a specific area of the code.

This is even a great tool for the corporate world as well. Even if a lot of businesses don't care to use open source software per se (though that seems to be changing more and more these days) imagine the following situation. You are a business owner, you are looking for a specific piece of software to be done for you, you can go see in the open source community for projects that might come close to what you need. Get in touch with it's creator to see if you can get a development contract that can benefit both of you. The developer won't mind getting paid, you get the most qualified person to develop your solution, it's the best of both worlds.

THE CATHEDRAL AND THE BAZAAR OPEN SOURCE MODELS:

You can't talk about Open Source Software without talking about these two models. Open Source is a very freestyle type of effort. It is both its strength and its weakness. Anyone can sit down and code something for the Open Source community, anyone at all. This also implies that the code you're likely to see can very a lot in quality and in organization. You can expect to see jut about all levels of organization and disciplines in the Open Source community. All in all the can be split into what is classically called the cathedral and the bazaar. Let's take a look at both of these as they are defined on the Wikipedia website.

The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples. The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the FetchMail project.

In other words, there are all types of different people creating different types of projects which means that there can be that many levels of implementation. It's all voluntary so you might find projects that took a few hours to develop or you might find projects development by groups of people (or organizations) that reflect a lot more structure and time investments on the part of the authors. People take Open Source seriously at different degrees and so do corporations. Trying to find a specific project (or category of project) can sometimes be a daunting task especially if you're looking for a quick short algorithm rather than a fully fledged application or library. But I believe that knowing the difference between the cathedral and the Bazaar will help you filter out what you don't need.

WHAT YOU CAN DO WITH OPEN SOURCE LICENSING:

Since there are so many Open Source Licensing schemes as well as the other licensing schemes such as freeware, shareware, standard corporate licenses and the likes, how do you draw the line of what can be done? After all my research on the subject I can break things down to Three distinct things you can do to make sure people that look at your code can do what you want them to do with your code. Let's review each of them so you know the difference and the possibilities. This is after doing some research and exchanging emails with people from the Open Source Initiative website (O.S.I.).

• Use the appropriate licensing scheme:
  Basically take a quick look at the available licensing schemes (See the reference links below for a comparison chart of them), if one of them happens to allow what you want to allow specifically, go ahead and use it since you're covered on all grounds. These licenses were typically created out of the face that existing ones didn't have this specific "freedom" so the license was created to accommodate for that missing freedom. Hence it's very possible that a newer license will allow more than the older licensing schemes.




• Use different licenses for different projects release types:
  Here's one I learned after my email with the OSI contact. You can actually state different licenses for different type of development done with your source code. For example, you could say "released under the G.P.L. 3.0 for Open Source projects" and add "released under the BSD license for Freeware and Shareware projects". And as a rule of thumb when users of your code are developing a closed freeware project the BSD license would apply to them and if other users create an Open Source project with. .your code (such as a GLP or any other OSI approved licensing schemes) then your GPL notice would apply and they would have to follow the G.P.L. 3.0 licensing as far as your code is concerned in their Open Source project.




• Add a detailed Exception file to your license:
  This is one I use often. Basically, in your code where you state to look at the copying.txt file for licensing details you can also specify that special exceptions exist and include an exceptions.txt file with the details of this exceptions. For this, there's nothing stating you can't do it, and nothing that states that you should use exception files if you want to allow more than what the license allows. But since it's my code, I use them knowing that they can do whatever I put in the exception file and what is allowed in the standard licensing file.

The best advice I can give at this point is that if you are making an Open Source project that might have commercial derivatives (either you sell the product itself in the long run or you sell services related to your product). For example, I've seen a music software that is open source (in it's basic edition) and you can buy a professional version of the software. IF you are creating something that might be like this project try using the first two alternative above as im not sure about the exception file (it's just something I use for the projects I dont want commercial links to). But if you are just creating something that is destined to never have any commercially related traces then you can use whatever you want as it's your code and you have the freedom to do whatever you want with it. If you are using other Open Source projects with your creation then the licenses used by those other project is what you must consider when distributing them with your work. It's pretty much as simple as that.

IN CONCLUSION:

All in all, Open Source is a very widely used entity. As you might have noticed, even some corporation today have developed some Open Source licensing scheme (IBM and Microsoft for example). Open Source is pretty much a part of every software developer out there in one way or another. It's also a very evolved entity. As you can see in the reference links below, if you go to the OSI website you'll see that there's a wide variety of Open Source licenses to choose from. Much like a lot of other things in the software development industry, the Open Source entity is evolving day by day in order to answer the needs of the current reality of Open Source. This will change as new needs and new requirements are manifested. The bottom line is that Open Source is here to stay, it's gaining a lot of acceptance (even in the corporate world) and without a doubt will continue to do so.

Needless to say that all this research I've done on the subject don't make me a copyright lawyer per se, but they did happen to give me some insight on all these discrepancies and alternate possibilities. My email is below (at the end of this article) if you have questions I can either attempt to answer them myself or contact the right people to get the right answers for you. Feel free to contact me with any concerns or questions about Open Source Licenses. Also I invite you to take a look at the reference links below as they also hold a world of details and information that might already have the answers you are looking for. Until next time, keep it real, keep it Open Source.

REFERENCE LINKS:

Here are some reference I use all the time and that I believe were very useful in my composing this article as well as useful for many other things when it comes to my open source software projects.

• The Open Source Initiative: The first place to look when choosing an open source licensing scheme for your project is on your to do list. This has, among other information, the complete details about every recognized Open Source licensing schemes.




• The Wikipedia on the Open Source Initiative: The Wikipedia has a page devoted to the Open Source Initiative. This pages talks about what the O.S.I. is, who's with this initiative as well as other O.S.I. related subjects.




• Producing Open Source Software (by Karl Fogel): An excellent (and quite detailed) reference from Karl Fogel about how to run a successful Open Source project. It's a long read that is most definitely worth ever minute spent reading it if you take Open Source seriously.




• The Free Software Foundation: One of the major site in the open source effort and community. The free Software Foundation has a whole bunch of open source and free software related material. For the sake of this article you can click on the licensing tab on the website to see how they define free software.




• Free Project Hosting Facilities Comparison Chart from the Wikipedia: The Wikipedia has a page that gives you a rundown of most popular free project hosting sites and compares them using a table like layout of available services and features from each of the mentioned free project hosting facilities. Includes links to all mentioned hosting facilities as well.