(EDITOR'S NOTE: This article is contributed content from a vendor and has been edited to comply with our editorial standards. It should not be assumed that IT World Canada shares or endorses any particular viewpoint expressed here.)
Open source licensing management requires an understanding of the obligations associated with a variety of licences within a software portfolio. With so many different open source licences available, understanding and complying with them can be daunting task. The Open Source Initiative has an approved list of close to
70 open source licences. Protecode has catalogued more than 3,000 license variations so far.
One licence often
in the news is the
GNU General Public Licence (GPL). GPL refers to a family of licences that, depending on the version and the type, requires some level of disclosure of any code that includes GPL-licenced software. This is an important factor when deciding whether or not to use GPL governed code in projects.
The most important aspect is that you can charge for a product that uses any open source software, including those licenced under GPL code. However, the requirement to make the source code available in certain conditions means your business model needs to be more creative.
So, when do you need to make your source code public?
GPL v2 (Version 2)
This is the most common version of GPL. The following terms apply if you use GPL v2 code in your product and you distribute your product:
- If you modify the GPL code, you need to specify this. Include the modification date, and make the modified source code available.
- If your end-application has a user interface, you need to display an appropriate legal notice.
- Your end-product is automatically licenced under GPL v2.
- These terms only apply if your code is derived from GPL code. Simply distributing some GPL package with your product on the same CD does not mean those licence terms apply. If you do not distribute the product then there are no obligations.
GPL v3 (Version 3)
GPL v3 clarifies a number of loose definitions in the v2 licence and allows certain flexibility in correcting licensing violations. GPL v3 also ensures you do not use such code in a DRM (Digital Rights Management) product – releasing the source code for such a product would defeat its purpose. It also regulates usage in cases of certain patented software.
Affero GNU Public Licence
This is an extension of GPL v3 that mostly handles cases when your product using GPL is not distributed, but rather is used in a server providing services to other users. Under this provision, the complete source code must be made available to any user of the server that has AGPL-licenced work (e.g., the Web application that uses AGPL code). Aside from the GPL licences, there are three other popular open source licences with obligations users need to be aware of.
BSD Licence
When using code governed by the modified BSD licence, you must retain copyright notices and you must not use the name of the licensor to endorse or promote products derived from the software. With the BSD there is also no obligation to disclose the source code of your modifications and no obligations with regard to using the code internally.
Mozilla Public Licence (MPL)
With MPL, you must include a copy of the licence with every copy of the source code you distribute. You must also make the source code of your modifications available. Unlike strong copyleft licences, code under the MPL may be combined with code not licenced under the MPL. There are no restrictions on internal use.
Apache Licence 2.0
With Apache 2.0 you may redistribute the original or modified code as open source or proprietary code. You may copy and distribute the software so long as you provide a copy of the licence and retain the copyright, patent, trademark and attribution notices from the originating file. There is no obligation to disclose the source code of your modifications. You may add your own copyright statement and licence terms to your modifications, but you cannot remove any of the original licence requirements. Additionally, there is no obligation to disclose source code and no obligations on internal use.
So…
If you are not distributing your software, don’t worry about GPL compliance. If your software sits in a server, then check if you have the Affero licence. If you do, make sure you understand and comply with the licence terms. If you are distributing software that incorporates GPL, then you are most likely obliged to release your product code. Read the applicable GPL licence terms to see if you have to. There are finer details in these licences that you should make yourself familiar with. No matter what open source licence you choose, having an open source software adoption process in place ensures you will have no surprises when it comes to compliance.