|
|
Proponents of open source push their licences as superior; the folk who support free software licences, such as the GPL, do likewise. And those who are selling commercial software under proprietary licences throw mud at both free and open source licences, hoping some will stick.
When the average company wants to find out details of these licences - in order to use free and, often, much better crafted code - it is unlikely to approach either the open source or free software advocates. Nor would such an entity go to the Open Source Initiative or the Free Software Foundation.
More likely, it would approach a commercial entity like Protecode, which develops a product that checks for free and open source licence compliance, for advice. The interpretation of licensing terms that such a company - or its competitors like OpenLogic, Palamida and Black Duck Software - disseminates thus assumes importance.
The chief executive of Protecode, Mahshad Koohgoli, offered to answer a few common questions about free and open source licences; his answers are below.
iTWire: How do you know which products you can charge for based on the type of license used?
Mahshad Koohgoli: None of the recognised open source licenses (recognised means that Open Source Initiative has approved them) place any limitations on commercialisation of projects that use software governed by these licences. You can charge for your products whether or not they use these open source licenses.
How do you decide whether or not to use GPL-governed code or projects?
Copyleft or restrictive licenses such as GPL 2.1 would require you to release your code to the public under the same licence. This may or may not be acceptable depending on your business model, and your competitive position, or barriers to entry to your market for others. Permissive licences such as Berkeley Software Distribution (BSD) licence would be more suitable if you do not wish to make your code available to the whole world.
There are different versions of GPL licences, though. For example LGPL will allow you to link your code to GPL open source software without opening up your own code. GPLv2.1 requires you that you release your code under GPLv2.1 even if you link to such open source software. With GPL, copyleft licences will not apply if you do not distribute your software unless you use open source code governed by an extension of GPLv3 called Affero.
When do you need to make your source code available to the public?
Generally GPL licences can force you to release your code to the public. GPLv2 (version 2) 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 (UI), you need to display an appropriate legal notice. Your end-product is automatically licensed 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 that the terms of those licences apply. If you do not distribute the product then there are no obligations.
GPLv3 (version 3) clarifies a number of loose definitions in the v2 licence and allows certain flexibility in correcting licensing violations. GPLv3 also ensures that you do not use such code in a DRM (Digital Rights Management) product - releasing the source code for such a product would defeat the purpose (of its creation). It also regulates usage in cases where software is covered by certain patents.
Affero GNU Public Licence is an extension of GPLv3 that mostly handles cases when your product using GPL is not distributed, but rather used in a server to provide services to other users. Under this provision, the complete source code must be made available to any user of the server that has AGPL-licensed work (e.g. the web application that uses AGPL code).
Is there a particular category of project that is suited to the GPL or to any other kind of licence?
The GPL licence is generally associated with community projects and those passionate about the ideals of Free and Open Source software, who have a desire to see their code is used and evolved by communities. Again, although GPL licences do not restrict the ability of a business to charge for products based on GPL-governed software, it does force the company to release their source code. This is not necessarily anti-business. Think of SugarCRM and Asterisk as successful enterprises that have built their business on open-sourced software.
What about the so-called open core licensing? What is your opinion?
Open Core licensing is a model where the core capability/function/module is open source, but then additional functionality and capabilities are built upon, or around, the core that are not open sourced and licensed. It is a very valid business model. It must be applied paying careful attention on the open source licences that govern the code (ie. to avoid any complications, do not use a GPLv3-governed open source core). The reverse of it is what is coined as 'Open Crust' licensing, where open source software is run on a proprietary core (eg. all open source applications that you can run on a Windows machine).
GPL licensing is said to be decreasing in favour of Apache-style licences. True or false? Either way, why?
We have seen an increase in the relative number of new projects that are opened to the community adopting the Apache licence, especially those projects that are released by formal (commercial or governmental) organisations. The GPL and its variants still attract a large number of new open source projects, especially those released by open source ad hoc communities. In terms of the current pool of open source projects and based on the analysis of about 500,000 projects in Protecode's Global IP Signatures (GIPS) database, we see that GPL and its variants still dominate the public domain software.
