Understanding Open Source Software Licensing

Back in the 70s and even early 80s, it was common for software to be shared freely. Companies published the source code listings for their products in a readable format—engineers in computer labs tinkered with code, making it work for them, often porting it so it can run in their environment. Developers expected collaboration, and creativity and research flowed openly.

Then came commercialization and NDA. The software stopped being a tool, a utility that supports the hardware. It became a complex product in itself, and companies wanted to protect their intellectual property. Code enthusiasts were hired away from the research labs and asked to sign an NDA, preventing any part of the source code from being shared.

In 1976 Congress introduced a Copyright Act, allowing companies and creators to copyright the "expression of a program." That meant that including someone else's source code in your product could result in the copyright claim unless the code owner had granted explicit permission to use it. Such consent was unlikely to come from a commercial entity code owner.

At the same time, software patents prevented others from duplicating or expanding on ideas. The landscape was changing.

History of GNU and Copyleft Licenses

Is software meant to serve humanity as a whole, making the world better and empowering people - or is it just a vehicle for profit? Should development roadmaps be driven by society's needs or by commercial entities?

In the early 80's Richard Stallman, a software developer at MIT Lab, ran into a problem trying to fix the paper jam problem with a new Xerox printer. He wanted to write a patch, which was done many times before in the lab, but this time manufacturer chose not to provide a source code listing. The printer's software was a compiled binary, making it impossible to change.

Undeterred, Stallman attempted to get the original developers' source code, only to be denied due to a signed NDA.

For Stallman, this denial was a significant event triggering a decades-long quest for free software. Suddenly, instead of sharing and cooperating and making software better together, the code was surrounded by a secret commercial wall.

In 1983 Stallman started the GNU project. His goal was to make software that can be given to anybody who wants to use it.

In GNU Manifesto, Stallman wrote:

"I consider that the Golden Rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement.[...]

So that I can continue to use computers without dishonor, I have decided to put together a sufficient body of free software so that I will be able to get along without any software that is not free."

What makes software free? For Stallman, it came to the following freedoms:

• the freedom to use the software for any purpose,
• the freedom to change the software to suit your needs,
• the freedom to share the software with your friends and neighbors, and
• the freedom to share the changes you make.

The first version of the GNU GPL license (General Public License) was released in 1989 and applied to any project released under GNU. It ensured that free software stays free, and no entity could take the GNU project and fork it into a commercial branch.

GNU GPL (in its third version as of 2007) has two crucial postulates:

1. If you use any part of GPL licensed software in your project, you must release your project under GPL. That means that users should be able to get source code and have the freedom to alter, share, and use the software as they see fit.

2. You cannot use patents to limit user's freedom, including charging them fees.

That makes GNU GPL licensed libraries and components potentially non-compatible for commercial (i.e., closed source) projects.

Copyleft Compromise - Weak Copyleft

GNU LGPL

GNU LGPL (Lesser Public License) offers some flexibility for commercial use, permitting linking libraries for non -GPL licensed projects. The use of LGPL libraries implies additional restrictions: the new project must also be a library and link the LGPL licensed library dynamically.

The use of the LGPL licensing scheme is generally discouraged by GNU Project and Free Software Foundation. The flexibility it grants for inclusion in closed projects goes against the main principles those organizations stand behind.

MPL

Mozilla Public License was first published in 1998 when Netscape Communications released Netscape Communicator in the public domain. It allows static linking,i.e., the inclusion of the source code in the larger body of work, which can then be licensed differently. MPL grants patent protection to the original code's distribution (i.e., written by the original developer), but not to modified code. MPL grant is revoked if the user sues the original developer for copyright infringement.

Permissible Licenses - do whatever you want.

In contrast with Copyleft licenses, permissive licenses place no restrictions on how to license derived code.

BSD

In the 1970s, AT&T started licensing UNIX (initially developed for Bell Systems) for use by other parties. One of the most successful distros used widely in the academic world was Berkley Software Distribution (or BSD). However, the BSD contained a lot of proprietary AT&T code, which made sharing difficult as it required acquiring licensing from AT&T and the unpredictability of raising fees.

In 1989 with proprietary code removed, BSD was released under permissive University of California license, eventually spawning OpenBSD, FreeBSD, Darwin, and other open and commercial distributions. The current BSD license is very similar to the initial 1989 version but exists in multiple "clause" forms, placing additional restrictions on advertising and endorsement. BSD does not require the release of derived source code.

MIT

MIT (released under Massachusetts Institute of Technology in 1980) is another simple license that frees authors from liabilities, allows selling, sublicensing, or merging the software, and requires the project documentation to be licensed the same way.

Apache 2.0

Neither MIT nor BSD offer any patent protection. On the other hand, Apache 2.0 permits users to use the software regardless of patent restrictions. Similar to MPL, user license is revoked if they sue any entity for copyright infringement.

License Compatibility

It's a month to production release. You do the final license check and notice that the primary component is licensed under GPL3. The code is intended for commercial release with no plans to make source code available. If you release, your project violates the GPL3 license. You can choose to make source code available or delay the release and develop the component yourself.

When you include a package in your software, you are entering a contract agreeing to comply with the license terms. It's essential to understand what you agree to, how that can affect the final project, and whether all components have compatible licenses.

For example, before including packages A and B, answer the following questions:

1. Can A and B be combined without violating their respectful licensing agreements?
2. How including A and B in your body of work affect the project licensing?

Those answers are not always easy to determine. There are multiple Open Source software licenses, and each of them may have several released versions. They are written in legalese that is hard to understand and parse correctly. For example, it would seem logical that GPL is compatible with any other license as being the most restrictive. However, the BSD license variant with an advertising clause violates GPL's stipulation that no further restrictions can be placed on the downstream users. BSD license variant without advertising clause is compatible.

For Enterprise environments, using a license compliance tool like Black Duck removes this complexity. Smaller teams may benefit from FOSSology.

Benefit for all

Open source licenses ensure that software stays free - not free as a cost, but available to everybody. The open-source movement had shifted how we view and write software - more companies are releasing their internal tools and frameworks to the community. Understanding the reasoning behind open-source licenses is essential, and honoring the terms is being a good citizen.