License Obligations of Open Source Software
Since there are several hundred thousand free, widely used, and well maintained open source packages on the internet, it makes perfect sense to leverage open source whenever possible. If you are a commercial software developer that depends on selling your own software in the marketplace, however, it is important to understand the legal obligations and the legal restrictions that come with your open source license.
The courts have ruled that violating the license obligations that come with open source is the same as copyright infringement, and this menas you do have to respect the license obligations when you use open source.
With most open source licenses, the license obligations only apply if you deploy the open source, i.e., you incorporate the binaries associated with the open source inside the binaries that you ship to your customers. If you use the open source software only as a development tool, the obligations posed by the open source do not apply.
With most Open Source licenses, the typical obligations center on attribution, re-distribution as well as various restrictions.
Attribution refers to giving credit to the authors and contributors of the open source software.
The requirements can include all, some, or none of the following:
* do not remove copyrights present in the source code
* provide credit in the end user documentation
* do not use the open source authors names to endorse the commercial product without permission
* clearly mark if you make any changes to the open source
* clearly show in the documentation where to get the open source code
* in any advertising you do for the commercial product, make sure you acknowledge the open source component provider.
Re-distribution refers to making the open source and related components free of charge and available to the public. This is typically done under the same license as the original open source and/or with a compatible license.
This can include the original open source, as well as any changes you make, and sometimes, any software "based on" the open source code. "Based on" is interpreted differently depending on the license.
Some licenses are viral, and can essentially force you to make all of your own commercial software that is linked to the open source software to also be given away free. These licenses are called "copy-left" licenses, and pose the greatest threat to a commercial software company's revenues.
Restrictions depend on the license, but common restrictions include:
* do not make any additions or changes to the open source
* do not distribute this open source software without adding your own with additional software
* do not remove copyrights or license text in the open source
* do not initiate patent claims against any of the contributors to the open source.
Violating these restrictions can cause the license to be terminated.
While there are over 100 unique licenses, the following discusses some of the common types:
The least restrictive licenses are public domain licenses. Source code provided in the Public Domain are free to use without restriction, i.e., you can use the source code without any attribution or redistribution and you can make modifications and derivative works; and you can distribute any or all of the open source software as you see fit.
These are followed by MIT style licenses, so named, because these licenses follow a template created by MIT. In these licenses, the rights are similar to public domain. The only obligation is attribution, whcih satisfied by leaving the original copyrights that came with the open source software in place and also providing credit to the open source authors in the end user documentation.
The next common style is BSD style licenses, originally created by the University of Berkeley, with both an original and a "modified" version of the license available. These licenses contain the same obligations as the MIT license, with the additional attribution requirement that the commercial software provider cannot use the names of the open source provider as a product endorsement without explicit permission.
The first version of the BSD license also required that in any advertising done for the commercial product, there was an acknowledgement of the open source provider, however the 2nd version is far more commonly used today.
The next common license style is from Apache, which is a large cooperative of open source contributors, with an extensive library of open source software. The Apache 1.1 licenses requirements are very similar to the BSD 2.0 license requirements.
The Apache 2.0 license adds that any modifications to the open source code must be clearly marked with a change log. The Apache 2.0 license also adds an important restriction, the patent non-assert clause, which essentially states that if you initiate patent litigation against any of the authors or contributors who helped create this open source, you can no longer use the open source.
The next common set of licenses is the Common Public License and its derivatives such as Eclipse Public License, IBM Public License, and the Mozilla Public License. These licenses all have similar obligations to the MIT license, but they also have additional obligations in attribution and redistribution.
The CPL 1.0 license requires that if the open source is modified, the commercial software developer has to make the original open source code and the modifications available for free. In addition, the commercial software developer has to state in the end user documentation how the user can obtain this open source code along with the changes. Finally, the source code changes made by the commercial developer should be clearly marked. It is important to understand, that the CPL is not viral, ie, it does not contaminate the commercial software developer's proprietary software.
The final common set of licenses are the LGPL v2.1 and the GPL 2.0 licenses, which together make up the majority of all of the open source code available on the internet.
The GPL 2.0 license has all the same attribution and redistribution requirements as the CPL license above. However, the GPL also require any works based on those packages to be offered (redistributed) under the same "free to the public" terms. Most commercial software companies consider this an unacceptable license for commercial software, as it threatens their revenues.
The LGPL v2.1 license carries a similar obligation to the GPL 2.0 license but more narrowly interprets when the redistribution obligation applies, which makes it friendlier to commercial companies than the GPL license. Basically, any commercial software which is not statically linked to the LGPL licensed package does not require redistribution.
However, the LGPL license also carries other obligations such as requiring the distributor of any package which includes the LGPL libraries to allow the end user to replace those libraries. This may cause support or packaging issues for the commercial software company.
There are also several dozen unique licenses for individual open source packages. While they can generally be classified as similar to one of the common licenses described above, they often have some unique requirement or feature that needs to be taken into account.
To summarize, open source licenses center on attribution and re-distribution, although they can have other requirements as well. Understanding these license obligations, and abiding by them, is the true cost of free open source, and it is important to understand and manage these license obligations to avoid legal issues and to safely leverage open source.
The courts have ruled that violating the license obligations that come with open source is the same as copyright infringement, and this menas you do have to respect the license obligations when you use open source.
With most open source licenses, the license obligations only apply if you deploy the open source, i.e., you incorporate the binaries associated with the open source inside the binaries that you ship to your customers. If you use the open source software only as a development tool, the obligations posed by the open source do not apply.
With most Open Source licenses, the typical obligations center on attribution, re-distribution as well as various restrictions.
Attribution refers to giving credit to the authors and contributors of the open source software.
The requirements can include all, some, or none of the following:
* do not remove copyrights present in the source code
* provide credit in the end user documentation
* do not use the open source authors names to endorse the commercial product without permission
* clearly mark if you make any changes to the open source
* clearly show in the documentation where to get the open source code
* in any advertising you do for the commercial product, make sure you acknowledge the open source component provider.
Re-distribution refers to making the open source and related components free of charge and available to the public. This is typically done under the same license as the original open source and/or with a compatible license.
This can include the original open source, as well as any changes you make, and sometimes, any software "based on" the open source code. "Based on" is interpreted differently depending on the license.
Some licenses are viral, and can essentially force you to make all of your own commercial software that is linked to the open source software to also be given away free. These licenses are called "copy-left" licenses, and pose the greatest threat to a commercial software company's revenues.
Restrictions depend on the license, but common restrictions include:
* do not make any additions or changes to the open source
* do not distribute this open source software without adding your own with additional software
* do not remove copyrights or license text in the open source
* do not initiate patent claims against any of the contributors to the open source.
Violating these restrictions can cause the license to be terminated.
While there are over 100 unique licenses, the following discusses some of the common types:
The least restrictive licenses are public domain licenses. Source code provided in the Public Domain are free to use without restriction, i.e., you can use the source code without any attribution or redistribution and you can make modifications and derivative works; and you can distribute any or all of the open source software as you see fit.
These are followed by MIT style licenses, so named, because these licenses follow a template created by MIT. In these licenses, the rights are similar to public domain. The only obligation is attribution, whcih satisfied by leaving the original copyrights that came with the open source software in place and also providing credit to the open source authors in the end user documentation.
The next common style is BSD style licenses, originally created by the University of Berkeley, with both an original and a "modified" version of the license available. These licenses contain the same obligations as the MIT license, with the additional attribution requirement that the commercial software provider cannot use the names of the open source provider as a product endorsement without explicit permission.
The first version of the BSD license also required that in any advertising done for the commercial product, there was an acknowledgement of the open source provider, however the 2nd version is far more commonly used today.
The next common license style is from Apache, which is a large cooperative of open source contributors, with an extensive library of open source software. The Apache 1.1 licenses requirements are very similar to the BSD 2.0 license requirements.
The Apache 2.0 license adds that any modifications to the open source code must be clearly marked with a change log. The Apache 2.0 license also adds an important restriction, the patent non-assert clause, which essentially states that if you initiate patent litigation against any of the authors or contributors who helped create this open source, you can no longer use the open source.
The next common set of licenses is the Common Public License and its derivatives such as Eclipse Public License, IBM Public License, and the Mozilla Public License. These licenses all have similar obligations to the MIT license, but they also have additional obligations in attribution and redistribution.
The CPL 1.0 license requires that if the open source is modified, the commercial software developer has to make the original open source code and the modifications available for free. In addition, the commercial software developer has to state in the end user documentation how the user can obtain this open source code along with the changes. Finally, the source code changes made by the commercial developer should be clearly marked. It is important to understand, that the CPL is not viral, ie, it does not contaminate the commercial software developer's proprietary software.
The final common set of licenses are the LGPL v2.1 and the GPL 2.0 licenses, which together make up the majority of all of the open source code available on the internet.
The GPL 2.0 license has all the same attribution and redistribution requirements as the CPL license above. However, the GPL also require any works based on those packages to be offered (redistributed) under the same "free to the public" terms. Most commercial software companies consider this an unacceptable license for commercial software, as it threatens their revenues.
The LGPL v2.1 license carries a similar obligation to the GPL 2.0 license but more narrowly interprets when the redistribution obligation applies, which makes it friendlier to commercial companies than the GPL license. Basically, any commercial software which is not statically linked to the LGPL licensed package does not require redistribution.
However, the LGPL license also carries other obligations such as requiring the distributor of any package which includes the LGPL libraries to allow the end user to replace those libraries. This may cause support or packaging issues for the commercial software company.
There are also several dozen unique licenses for individual open source packages. While they can generally be classified as similar to one of the common licenses described above, they often have some unique requirement or feature that needs to be taken into account.
To summarize, open source licenses center on attribution and re-distribution, although they can have other requirements as well. Understanding these license obligations, and abiding by them, is the true cost of free open source, and it is important to understand and manage these license obligations to avoid legal issues and to safely leverage open source.
About the Author:
For more actionable insights into the legal disadvantages of open source and how to avoid them, come visit our blog at Source Auditor.
<< Home