When developing commercial software products that incorporate any type of open source software (“OSS”), it’s important to understand the basic difference between Restrictive and Permissive OSS licenses. OSS licenses can have dramatic implications for the value of your final product.
To understand the different types of OSS licenses, it is first important to understand the difference between source code and object code. Source code is the text written in programming language by software programers. For your computer to understand the instructions,however, the source code must be converted into object code (also called binary code) that the computer can read. To change or modify the software, software programmers must have access to the source code.
Most computer programs that you buy are distributed in object code. Commercial software companies usually strictly restrict access to the source code for their key products and protect it with trade secret and copyright law.
In an academic tradition, however, there are many software developers who work collaboratively, freely share source code, and distribute the resulting software under open source licenses without charge. Hence, this type of software is referred to as open source software. Open source software is an amazing resource and can greatly reduce product development time. Open source software, however, is only as “free” as its attached license that legally limits what you can do with it.
Restrictive OSS Licenses
Proponents of restrictive licenses want to keep source code freely available to all. Restrictive licenses, like the GPL or Affero licenses, limit the terms of distribution of software that incorporates pieces of OSS licensed under its terms. Restrictive licenses require that works based on the OSS relicense the resulting works to others on the same terms of the initial license and require the final source code be openly available for free or a nominal value.
Restrictive relicensing terms can dramatically lower or nullify the value of your final software product.
The rub is that when you incorporate different pieces of OSS into a larger product, the licenses may not be compatible with each other or with the license that you want to use with your final product. Essentially, restrictive licenses can contaminate your larger product and create an intellectual property mess for those who want to change the licensing terms and limit access to the product’s full source code. Basically, if you incorporate OSS with a restrictive license into your product’s software family, the father or grandfather license will dictate what you do with the software children.
Permissive OSS Licenses
In contrast, permissive open source licenses allow you to license second generation software children without requiring access to the final source code. With permissive licenses like the MIT, BSD and Apache OSS licenses, free is more free.
You can incorporate pieces of OSS into your product and restrict the access to the source code for the final product. It is much easier to make all licenses compatible and comply with the terms of the original licenses, some of which simply require attribution, a copyright notice, disclaimer of warranties and limits on liability.
In short, it is important to read the licensing terms of any open source software that you want to use in a software product (or website) that you want to sell or sublicense.
The fine print can be very important.
Jill Hubbard Bowman is an intellectual property attorney who helps software developers create valuable products.
The information provided in this legal blog is not intended as legal advice and does not create an attorney-client relationship. Please do not submit questions or comments seeking legal advice or submit confidential information through this blog. By communicating through this blog, you understand and agree that the information will not be treated as confidential and the publisher has no duty to keep it confidential.
Comments on this entry are closed.