A project license or schema of licensing imposes restrictions and allowances to the application adopter and source code contributor, creator of a derivative work. For example, a company that customizes a GPL application and distributes it in the market is obliged to make the source code of the redistributed, improved public software. The license choice is a strategic decision with social and economic impacts on the project, as it can block the interests of people related to the software, that is, users, developers and other relevant stakeholders. A major decision like that is not expected to occur very often, as managers avoid status quo changes that harm expectations and turn people’s attention away from the actual work (e.g., into politics and disputes). This tendency to not change strategic matters is known in the organizational literature as structural inertia .
In conformance to this organizational inertia, out of thousands of free software projects obtained from FLOSSmole and Sourceforge.net and analyzed in this research, only 756 have decided to change their license type over the period of 44 months covered in this research, from October/2005 to June/2009, missing July/2008. Nevertheless, as it has already been shown in Table 1, these 756 projects that changed licenses have done so 1012 times, a considerable number that validates the theoretical expectation of managerial action through changes in software legal restrictions towards meeting stakeholders’ demands and expectations for project success. Previous research has stated that the license affects the probability of project success and, accordingly, FSP managers have indeed attempted changes in legal restrictions.
In terms of specific results, leaving projects exposed and legally unattended, the managerial decision of not having a license specified was detected both ways, as projects left the “none” choice 88 times and, surprisingly, changed their current state of having a license to one where they have no license 55 times (see Table 1, type of license A). In fact, it has been found that projects have had no license specified in every month covered by this research. FSP with no license, the “none” A-category created, have less average attractiveness than restrictive/relicensable and dual-licensed projects often, but have more attractiveness than GPL (F-schema). Let us now move one step further to analyze the data numerically.
Types of license interventions and variations in attractiveness (post/pre ratios)
To interpret the results in Table 5, for example, one can see that the ratio of 0.94 in the first row indicates that projects changing from type of license A to B experienced lower levels of attractiveness after the intervention, that is, moving away from a status of having no license (A) and going to a status of “public domain” license (B) is on average detrimental to attractiveness (specifically, a reduction of 6%). However, that strategic move has been detected only 22 times in the sample (see Table 1), imposing a limitation to any robust statistical analysis of such variation in attractiveness. This limitation is overcome later in the analysis, with the t-tests as described in the methods section.
Moving ahead with this exploratory results interpretation, as for the associations of the odd managerial action of moving away from having a license specified to not having one (type of change with “A” as target) with attractiveness variations, the average attractiveness ratio of projects that have undergone this type of change have been found to be always detrimental to attractiveness (column A of Table 5), demonstrating that stakeholders do not like the uncertainty associated with a project with no license. By looking at the interventions with A (the none choice) as target in Table 5, it is noteworthy that every time such change was made, the average project attractiveness decreased (a number smaller than one indicates the attractiveness ratio of after/before the change is on average pushed down). Additionally, when a project went from none to a restrictive and relicensable choice (A → E), this change was associated with an average change of 14% in attractiveness.
From a distinct perspective, interestingly, the intervention from none to non-restrictive and relicensable (e.g., MIT), and to restrictive, highly restrictive and relicensable (i.e., dual licensed) led to an attractiveness reduction (see from A → B and A → G in Table 5). At this moment, one can only wonder the actual reasons for such findings in a case-specific manner, but the general theoretical interpretation is that relevant stakeholders’ interests were harmed due to the project license change, affecting its consequent attractiveness.
Together, these findings related to the managerial decision of having no license specified can probably be interpreted in several ways, such as a sign of a not welcoming market to unregulated software, easier to suffer litigation, if you consider that a managerial change to not having a license specified is always detrimental. However, from another perspective, projects with no license can still be considered attractive, suggesting the possibility that the regular user does not take the license into account at all. Perhaps both explanations are valid and complementary, as the attractiveness measure adopted in this research groups the effects on developers and users together (downloads and membership numbers), and only future research can sort this out. Attractiveness is a cause that these variables have in common, but most likely it is not the only one (the first principal component extracted, for example, explains 64% of the variance, and so 36% is not due to this attractiveness measure). Future studies can dig into this line of inquiry, studying these indicators separately as well.
Back to the results interpretation, by focusing on the most popular choice, the GPL, or more generically, the most restrictive licensing (i.e., restrictive, highly restrictive and non-relicensable – the F-schema), it has been found beneficial to projects to abandon this scheme for source code regulation concerning attractiveness increase. Overall, a positive variation with such change in terms of attractiveness was detected, but such strategic move was detrimental to FSP attractiveness when projects went to “none” (A), or restrictive and non-relicensable (D), that is, normally, to the LGPL option (see changes involving F in Table 5). In support of these results, to become GPL was good to FSP attractiveness when the initial state was the absence of license (option A), the Academic Free License (C), or the LGPL one (D). These strategic interventions were detected 47, 7 and 67 times, respectively (Table 1). When taken together, these findings suggest that it is good to avoid the GPL, but it is better to adopt it when compared to having no license or the LGPL. The more challenging explanation for the findings of this type of change is the intervention from GPL to AFL (F → C) and the opposite (C → F), which are both positive. This means that it is good to change from GPL to Academic Free License, and it is also positive to change to GPL coming from the Academic Free License. This suggests that any change might be good to the project, depending on whether such change is aligned with FSP stakeholders’ demands. The (lack of) symmetry on the effects of interventions can be better observed by looking at the matrix shown in Table 5 (the superscript letters), a pattern of the findings dealt with in details later in this section.
Analyzing all interventions together, out of 35 types observed in the sample, 13 were positive to attractiveness, 21 were negative, and only one neutral. In total, 1012 intellectual property interventions were found (an average of more than one per project). When taking the initial state (involves F in Table 5) into account, the most common managerial intervention is F (detected 417 times), and it has a consistent positive impact on attractiveness. The least common origin is C (14), and it is associated with a negative change in attractiveness. The largest negative impact occurs for the abandonment of E (15%), which was found 49 times. The mixed results apparent in a visual inspection of Table 5’s coloring scheme suggests that interventions on types of licenses do not always come for good, and that there is always an impact, although only exploratory not statistical here, on attractiveness (the only exception is F to B). This reinforces the importance to carefully and strategically think through the decision, as its impacts do not seem to be irrelevant regarding associated changes in attractiveness.
Moreover, every intervention that targeted A, or originated from E or G, impacted attractiveness negatively. Also, although changing from C to B does not change the project type of license in terms of the restrictions analyzed in this research, it does impact attractiveness, suggesting that stakeholders prefer AFL to MIT, for instance, which makes sense as AFL was designed to improve MIT and that was the reason to include it separately in this study. However, the actual reasons for such finding should be an object of future research, as it suggests there is more to the licensing scheme as this quantitative research captures.
Finally, going from G to B led to a reduction of 15% on attractiveness. The dual-license option that G represents signals to projects’ stakeholders that the software is suitable for a wider audience as this intellectual property model can accommodate the interests of various groups, being more market flexible (a generic strategy). Moving away from this management model appears to push attractiveness down, always, as mentioned before (a focused strategy).
Short Bytes: While open sourcing a project, one needs a license so that the terms distribution, linking, modification, private use, etc., can be automatically taken care of. There are many open source licenses to choose from, some of them being MIT, GNU GPL, Apache 2.0, Creative Commons, BSD licenses. Each has its own terms of the above characteristics that even decide the ownership and credibility of the project.When I started using GitHub to store my projects’ source code, I would choose a license randomly, mostly because that project wouldn’t really be a tool for others to use and build things upon or tinker with. But when one builds such a tool or product, that can be forked by others to build their own versions by tweaking and changing its source code, one needs to decide an open source license for it. There are so many options to choose from:
- Apache License 2.0
- BSD 3-Clause “New” or “Revised” license
- BSD 2-Clause “Simplified” or “FreeBSD” license
- GNU General Public License (GPL) v3.0
- GNU Library or “Lesser” General Public License (LGPL)
- MIT license
- Mozilla Public License 2.0
- Common Development and Distribution License
- Eclipse Public License
- Creative Commons License
But first let’s see, what is licensing.
What is licensing?
There has always been a lot of confusion in what licensing really means. When one licenses something, one is not giving its rights away, as the copyrights (or the patent, if one has one) are your own to have. Licenses provide rules and guidelines for others to use your work. Open source licenses help others to contribute to your work or project without seeking special individual permission to do so.
Here are some of the licenses and what they mean by their terms and conditions of linking, distribution, modification, private use, etc.
Recommended: Difference Between Freeware and Open Source Software
Different types of open source licenses:
GNU General Public License
- Copy the Software: There’s no limit to where you can copy that code. Copy it on your own server, on your client’s server, on your local workstations, wherever and howsoever many times.
- Distribution: You can distribute it in your thumb or hard drives, you can distribute the code under this license with a download link on your website, you can print out the code on paper, whatever form of distribution you want.
- Charge a Fee: You can charge someone for the software, but remember to give them a copy of GNU GPL which would tell them that they could get the software free from elsewhere. This also gives a chance for you to tell them why you are charging for it.
- Change the Codebase Howsoever: If you want to fork the project and make changes to it, you can. Remove or add features howsoever you want. The only condition is that your project should also be released under GNU GPL.
It is important to know the distinction between source and binary distributions. There are some constraints regarding releasing applications under each other. Also, if a project uses GNU GPL license, it has to comply with some standard rules of commenting parts of license requirements inside the code itself.
GNU LESSER GENERAL PUBLIC LICENSE
It grants fewer right to work than GNU GPL. It’s generally appropriate for libraries and projects that want to allow linking from non-GPL and non-open-source software. GPL requires any other project or source that is using the project under GPL to also be licensed as GPL; GPL licensed code can’t be used for paid and proprietary software. LGPL cancels it out by not requiring other projects with parts of the code to be similarly licensed.
BSD license is a part of a family of free software licenses that have much fewer restrictions in distribution as compared to other free software licenses. Two important versions are:
- The New BSD License / The New Modified BSD License
- The Simplified BSD License / FreeBSD License
Both have been accepted as open source licenses by the Open Source Initiative.
The New BSD License (known as the “3-clause license”) allows unlimited redistribution for any purpose, so as long as the copyrights and disclaimers of warranty of the license are maintained. This license has an interesting requirement. It contains a phrase restricting the use of contributors’ names for endorsements of a derived work without specific permissions. It basically means that if someone has forked some famous person’s code and made changes to make a new project, s/he can’t use that person’s name to endorse it. The primary difference between the New and the Simplified BSD License is that simplified BSD license omits this clause.
Recommended: Why Should Every Developer Contribute To Open Source Software?
It’s the shortest and perhaps most used of all the popular open source licenses. Its terms are loose and more open than most others. The main giving of this license is:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
This basically means that you can use, copy, and modify the software however you want. No one can prevent you from using it in any other project. You can give the software under it for free, or sell it. No restrictions on distribution howsoever. Anyone can do whatever one fancies with the code licensed under MIT license, as long as it’s accompanied by the license.
Creative Commons (CC) [under which MIT Open Courseware Material is released] licenses aren’t quite open source. They are common for design projects. A wide variety of them are available each granting particular and certain rights. A CC License has four basic parts.
- Accreditation: Author must be attributed as the creator of the work. Then, work can be modified, distributed, copied, used otherwise.
- Shared with CC: The work can be modified, distributed but only under CC License.
- Non-Commercial: Work can be modified, distributed but not for commercial purposes. The word “commercial” is a bit vague in its meaning since no solid lined definition is provided.
- No Derivative Works: You can copy and distribute the licensed work, but you can’t modify it in any way or create work based on the origin [as MIT Open Courseware Material is]
Remember, these are not necessarily all the rules in all the licenses based on CC. Some CC Licenses may or may not have the above rules. They are mutually exclusive and can be combined as per the needs.
Apache License version 2.0 rights can be applied to both copyrights and patents. Some of the licenses can be applied only to copyrights and not patents. Some details of Apache License:
- Rights are Never Ending: Once the rights under Apache License have been granted, you can continue to use them forever, there’s no need of renewing it.
- Worldwide Authority of Rights: Even if rights are granted for one country, automatically, they’re granted in all countries.
- Rights for No Fee or Royalty: No charge, neither up front nor per usage or on any other basis applicable.
- Rights are Irrevocable: No can ever say to you that your derivative of the code that was licensed under this license can’t be in use anymore (A clause in the license states that if you sue someone over patent infringement on anything under this license, then your license is terminated, but that only applies to patented work, and as long as you don’t sue anyone over the work, you won’t have to worry about it).
Redistribution of the code has requirements, mainly related to proper credit to those who’ve worked on the code and maintaining the license.
Stay tuned for the tribute post for Aarzon Swartz, Internet’s Very Own Boy, where we remember what he stood for, projects he was involved in, what kind of books he read, things he wrote on his blog, which is still alive after his death, and more.
Don’t forget to share your valuable feedback and opinions. Keep reading.
Also Read: What Is Open Source Hardware And Why Should You Care?