Open-source licensing isn’t as complicated as license agreements go. Some people find it confusing, and businesses must pay close attention to how the licenses work. Making a mistake in one direction can result in legal action. Erring in the other direction can keep a business from doing useful things that are entirely legal.
There’s a philosophical rift between the “free software” and “open source” movements. Much of it is rhetorical, but it results in different license terms. Free software advocates insist they mean “free as in freedom,” not “free as in free beer.” They call their claims “copyleft” rather than “copyright.” Some free software licenses are more restrictive than the usual open-source licenses. Look at what the license says, not the rhetoric surrounding it.
The term FOSS (free and open source software) sometimes covers both. This article will use “open source” to include “free software,” except where it’s necessary to point out distinctions.
Regardless of their differences, all open-source and free software licenses let you view the source code, download it, and build it into your software products. You can modify the code if you like. In many cases, you can charge for the copies, but you’re competing with free downloading if you do.
This doesn’t necessarily mean you can do anything useful with the code without paying license fees. The open-source code may depend on other software that requires a paid license. To make it into operational software, you must either pay for the license or develop additional software that makes the paid part unnecessary.
With most open-source software, you can make changes and publish them as a fork of the original code. If you do, you have to make it available under the same license and make it clear that it’s a derivative of the source code.
There’s no warranty on the software. The developer may offer support for a price, or you can go to someone else for support.
Nearly all open-source licenses require that if you distribute a copy of the source code, you must include a license notice. This keeps anyone from giving the impression that it’s their proprietary code. The requirement also applies to derivative works, such as modified versions of the code and applications that incorporate it. If you publish an application that uses open-source code, you usually have to notify the user that it does. The required form of the notice is different for each license.
Issues arise only if you distribute new source or object codes. If your business uses open source only for internal purposes, it can use the license as it wants. However, it may be subject to patent claims.
The difference between “free” and “open source” licenses comes into view if you use licensed code to build and distribute your software products. The GNU General Public License (GPL) requires that if you convey a work based on GPL-licensed software, you must release it under the GPL, and the user interface, if any, must say so.
The license defines the term “convey” as providing copies of the software to others. If you run the modified software on a server, either internally or as SaaS, that’s not conveying, and you don’t have to release your source code. However, if you distribute software that uses GPL-licensed libraries, you must license it under GPL. This leaves gray areas, such as putting applications on employees’ phones, where legal advice may be necessary.
The Free Software Foundation has taken legal action against software distributors that have failed to comply, obtaining some favorable settlements. The legal concern is real.
Software developers must ensure that their contractual obligations to customers don’t conflict with their obligations under the GPL. A business that develops an application and agrees to give the customer full and exclusive rights may not be able to use GPL-licensed libraries.
There is also the LGPL, or Lesser General Public License, which is similar to the GPL except that it doesn’t require other software to be licensed under the GPL.
The Gnu Affero General Public License, on the other hand, is stricter than the GPL. It requires software providers running on a server (SaaS) to make the source code available under the Affero GPL, even if the software isn’t conveyed in the sense the GPL defines.
There’s no guarantee that an open-source work is patent-free. If a court rules that an application performs a patented process, the patent holder is entitled to collect fees for its use. Some patent holders don’t interfere with software that is distributed for free, but others are very strict. Software users, as well as distributors, can be the target of patent lawsuits.
Before the patents on the MP3 format expired, their holders insisted on payment for all software that created or played the files. One open-source MP3 library, called LAME, was distributed only in source form, on the theory that source code constituted only an “expression” of the format’s algorithms and thus didn’t infringe on the patent. It was never challenged on this point.
The main risk for users is that software developers may withdraw their product in the face of a patent challenge. This will leave the code unsupported.
Businesses are used to keeping track of licenses on software they pay for. They need to do the same with open-source software to be sure they’re using it legally. One piece of software may have multiple licenses if it’s made up of components from different developers. Legal rights for further distributing or using it to build new code will vary from one license to another.
Companies distributing open source software need to decide on the best form of licensing. If they want to ensure their software is used only in other free products, they should issue it under the GNU GPL. If they want to give others a choice about opening up code that includes it, they should choose a license that allows what they want.
This article is not legal advice. When in doubt, consult with a lawyer.
