The open source software’s is still not considered accessible as a part of proprietary software. I as a software developer try to summaries the licensing issues which are faced by a developer s with the use of open source software’s a in the development of a proprietary software trend. Open Source software tends to lack the complete and accessible documentation that retains users. The licensing mechanism of the open source software is ambiguous and Licensing is more critical for developers.
Developers generally feel that the software doesn't quite meet their needs, it lacks a given capability. To resolve the problem, the developers decide to build new functionality. The new, modified solution can be redistributed under the original license and is depending on the license selection. The result of this development is that new software is available for the software developer and organization. The bad news is that some of this software may run the risk of infringing upon patents of which the software authors were perhaps not aware. The numbers of open source licenses create a conundrum in the product development. The process for choosing a license, reviewing code and launching a product without liability concerns becomes more complex as the open source atmosphere expanding day by day.
The open Source Initiative (OSI) maintains a list of software licenses definitions and it certifies the licenses types. Currently it has 50 types of licenses used by open source development. We can divide these as four broader classes of licenses.
1) Academic/University licenses: It is truly open source having no constraints and conditions. Developer can use and redistribute them. Such licenses provide absolute freedom; only constraint here is needed to declare the original licensor's name as an endorsement in marketing efforts. BSD, MIT and Apache foundations of licenses fall in this category
2) Non-Permissive licenses: General public licenses version 2 licenses are restrictive a with respect to proprietary software. Because of its prominence, every project should at least consider a version of the GPL. Any derivatives of the software be released under the same license, and that the source code must be released. The resulting new software must also be free. The indent of such license is to ensure that the free software always remain free in any form. Mozilla public license also is an example of Non Permissive license
3) Permissive GPL license: The Lesser General public licenses (LGPL) much like the GPL, but it allows distribution of works forming certain types of combinations with proprietary, closed-source software. One constraint with such license is the condition with the linking of the open source libraries, these licenses ensure that the open source should dynamically linked to the proprietary software and the changes inside the open source code should be available.
4) Copyright/adaptive licenses: These are the list of open source licenses where the power is in the Initiator and all the contributors. Initial Contributor grants each Recipient a world-wide, royalty-free, non-exclusive copyright license
How to use OSI licenses:
It’s important to understand the effects of selecting the OSI licenses. Each license category has its own particular purpose, whether it's to ensure end-user freedom, prevent commercial use, or preserve a standard code base. One should aware of the fact that the copyrights are not the licenses, for software to reuse or redistribute one need license not the copyright information. In case of open source the copyright is use to keep the license and hence owner has less importance than that of the license. Here is the list of checklist need to perform in case of the OSI license selection
1) Check for permissibility of the open source software and which form developer is going to use the software. If the software falls under first category, the developer is king and having less concern about the legal issues.
2) How: How the software code is being used play a major role of Open software use. The scenario could be different types
->new software may require the Re- license?
->The software is using code base directly or linked?
->Check for the derivative software, some software may include other dependent software as a part.
3) Who: The recognition of the license type is the essence of open source software development. The type may be Apache, BSD, MIT, GPL, LGPL and many more. Each License has own rules and constraints. The agreement statement itself clear the cloud if carefully analyzed
4) Middle ground policy: Use restrictive like GPL for standalone programs, but permissive licenses like BSD for code that will be linked from other code.
5) Combination or derivation: GPL doesn't use the word "combination." It uses the phrase "contains, is derived from or based on “. Sometime it does mean a lot in the legal issues of software development.
6) Binary: The GPL license follow binary mechanism and hence whatever software will developed with GPL for commercial distribution it will fall under GPL, while anything derived from MIT/Academic software remain developer and organization specific.
7) Static Vs Dynamic linking in LGPL: LGPL allow using the open source library either (modified or original) at runtime. The modified open software code needs not to distribute. It is less restrictive in use and hence preferred by the closed software group.
Conclusion: Software License in open source world is a mechanism to communicate the owners and developer about what the software meant for and how it should be developed further. It associate some risks like releasing partially or even fully code along with software. It is recommended that developer should have a clear understating of licensing mechanism to use the open source software, which is one of the most ambiguous and cumbersome tasks.
Open source licenses never meant to restrict the development of software, the need of hour is to understand the importance of open source and follow the correct way to expand the horizons of software.
Refrenses :
http://www.softwarefreedom.org/resources/2008/foss-primer.html
http://www.opensource.org/licenses/apl1.0.php
http://www.catb.org/~esr/Licensing-HOWTO.html#AFL