License types - levels of freedom and business impacts

Open source projects as any other are subject to the legal system and distribute their software products with some type of license agreements. In general open source licenses give software users full right to freely use the software, modify it for internal use and distribute unmodified copies. But there are huge differences when it comes to interfacing them with other software and distributing modified versions or derived works. The license choice is a crucial moment for IT developers and managers as it will have many impacts on the future projects organizational structure and the companies business model. By choosing the right licenses we not only choose on what terms will someone be able to use our softwares and its sources but also whos third party software and code will we be able to insert in to our product. Futherrmore by creating a good copyright policy we can decide if during the development with the open source community the full copyrights will remain in our hands or will they start to spread between various author.

Who says which licenses are open source

As you can read in the Whats the free and the open in free open source software ? article licenses must fallow some basic principles to be called open source. Just making the source code viewable to the public is not enough. The Open Source Initiative is one of the most accepted authority in this topic and has a very precise definition of open source. [OSD] It's based on the Debian Free Software Guidelines [1] created by the experienced maintainers of the Debian software repositories. Those repositories contain thousands of software products on dozens of license terms that must match the free software vision. Therefore if the license you choose is DFSG-compliant or OSI-approved you can be sure you are in the open source community. [POS] The Open Source Initiative maintains a list of officially approved licenses [2] which is a good starting point when it comes to choosing a license for an open source project.

Types of licenses

Generally open source licenses divide in to more or less restrictive [TES]. Restrictive licenses are those which let to use their source code only in software that is also distributed under a compatible restrictive open source license. This prevents open source code from being stripped and sold as closed software. Also it forces fixes and upgrades done to the softwares code to be made available to the open source community if the modifier wants to distribute his version or any derived work. The main idea behind this is to force third party modifications to available to the original author so they can apply it to their release. However you can modify software under a restrictive license and not make the modifications public if you only did it for internal software which is not distributed else ware. The choice to make those changes open or closed is up to you then.

Restrictive licenses are also called copyleft and one of the first and of the most commonly used today is the GNU General Public License (GPL in short). On the other end of the open source license pallet we have very non restrictive licenses. They are often called permissive licenses and are quite near to the concept of public domain. Two of the oldest and most widely used are the MIT and the BSD licenses which let you use the sources of such licensed software in any type of project.

Less restrictive permissive licenses are usually very simple. Often they do not much more then just let you use the source code as you wish with the note that the author doesn't take any responsibility for any mishaps the software can cause. The MIT license is a good example of this as it takes just about 20 lines on a A4 paper. These type of licenses are often preferred for projects that produce development tools or middleware which are to be developed and used by several IT companies. This allows you to quickly establish a very libre and community driven project which is a good environment to collaborate in and which can lower overall development costs. First of all permissive licenses seem to attract more people and companies to the project as the fruit of their work both in their open source and closed proprietary projects. Secondly there is no need to force the contributors to transfer the copyrights of their contributions to the projects founder. You can just let the copyrights to the projects software to spread among various contributors. After all contributors publish their work on the same permissive license thus allowing you to use the sources in your open and closed source activities.

Both license types are good for companies that wish to mainly focus their business models on providing related paid services or cross-selling with other products. However restrictive licenses in opposite to permissive ones prevent other companies from using the opened sources in their proprietary software. This is often the preferred way for every day end user applications like office suites, media players, etc. and other project which see the risk of a competitor profiting directly from their work. This also applies to development tools if they are your primary selling products. The rule that every software which uses sources granted on a copyleft license must be also be licensed on a compatible copyleft license prevents your competitor for including that software is their closed products. But a very important question when starting a open source project on those terms is how to construct the copyrights policy. If you don't force contributors to transfer the copyrights of their contributions to the projects founder then the copyright to the project as whole will slowly get distracted among various authors. Many project leads may have nothing against this as it makes the project more community driven and attractive to potential contributors. But if the founder company will want to use a dual-licensing business model by also selling the projects product on a commercial license then maintaining full copyright to the projects sources will be mandatory. Only the company or person with full copy rights to the project can distribute it simultaneously on the open source GPL license, a topical commercial EULA license and any other he wishes. Such copyright policy as mentioned here may also be required when you are up-selling closed source products that are based on the sources of your open source project.

License compatibility

License compatibility refers to the problem where several licenses of software packages can contain contradictory requirements. For example, if one license says:

modified versions must mention the developers in any advertising materials

and another license says:

modified versions cannot contain additional attribution requirements

then, if someone combined a software package which uses one license with a software package which uses the other, it would be impossible to distribute the combination because the two requirements cannot be simultaneously fulfilled. Thus, these two packages would be license-incompatible.

It's an easy case when it comes to open source - closed source license compatibility. As we said before open source licenses divide into copyleft and permissive licenses. Copyleft licenses are not compatible with closed source proprietary licenses in both ways. So you can't use copyleft code in closed code and closed code in copyleft code. When it comes to permissive licensed sources they can be used in closed source projects if you fulfill the special requirements that might be added to them.

The situation is a little more complex when it comes to comparability among open source licenses them selfs. The general rule is that less restrictive licenses are generally compatible with more restrictive licenses but not the other way around. For example you can use source code licensed under the permissive MIT license in GPL licensed software and release the whole work under the terms of the copyleft GPL. But you can't do it the other way around and publish every think on the MIT license. David A. Wheeler has created a very good illustration on how it works with the most popular open source licenses. The illustration is displayed below: [3]

In this figure, the shaded boxes are the names of different FLOSS licenses. An arrow from box A to box B means that you can combine software with these licenses; the combined result effectively has the license of B, possibly with additions from A. To see if software can be combined, just start at their respective licenses, and find a common box you can reach following the arrows (aka “following the slide”). For example, Apache 2.0-licensed software and GPLv2+-licensed software can both reach “GPLv3 or GPLv3+”, so they can be combined using GPLv3 or GPLv3+.

Special requirements

Besides being copyleft or permissive licenses can also add some special restrictions and instructions on how to imply them. One of the more widely seen are: [POS]

• Enforcement of crediting - in which any use of the covered code must be accompanied by a notice giving credit to the authors or copyright holders of the code. This requirement is present in the BSD license for example.
• Protection of trademark - specifies that the name of the original software (or its copyright holders, or their institution, etc.) may not be used by derivative works without prior written permission. This requirement is present in the MPL license for example.
• Protection of "artistic integrity" - that requires modification and redistribution be done in a manner that distinguishes clearly between the pristine original version of the code and any modifications.

One other interesting special restriction that is starting to gain popularity is the so called Affero requirements in the AGPL license. Those requirements are an addition to the GPL v2 license and generally says that if you give software as a service over the network and your software is based on those sources licensed under the AGPL then your sources must also be available on a compatible open source license. [4]

Difficult choices in business

One of the most visible of the disputes over licensing was the Mozilla case. [TES] This effort initially encountered severe difficulties because of the license choice. Netscape initially proposed the "Netscape Public License," which would have allowed Netscape to take pieces of the open source code and turn them back into proprietary project again. However the community interested in the project showed great doubts about this approach and questioned its "open" nature. Ultimately, the firm announced the "Mozilla Public License," under which Netscape cannot regain proprietary rights to modifications of the code. In fact, the terms of the final license turned out even stricter than those of the General Public License.

References

[1] - Debian Free Software Guidelines - Debian project, 2004

[2] - List of officially approved open source licenses - The Open Source Initiative

[3] - The Free-Libre / Open Source Software (FLOSS) License Slide - David A. Wheeler, September 27, 2007

[4] - AGPL Frequently Asked Questions - Affero Project

[OSD] - The Open Source Definition - The Open Source Initiative

[POS] - Producing Open Source Software - Karl Fogel, book, 2009

[TES] - The economics of sharing: Open source and Beyond -  Josh Lerner, Jean Tirole, NBER Working Paper No. 10956, December 2004