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 your end-application has a user interface, you need to display an appropriate legal notice.
– Your end-product is automatically licenced under GPL v2.
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.