Open Source Software 101 & Checklist
Open source software (“OSS”) is increasingly adopted by technology startups, in light of the many benefits of its use. This piece highlights important factors to note when your startup is incorporating OSS in its products.
What is Open Source Software?
Open source software entails collaborative development and exchange of intellectual property in the design and development of software. It is typically characterized by its free nature, in other words, users can freely access and modify the original source code and adapt it for their purposes. A useful analogy to OSS is Wikipedia which is made of input and contributions of information by millions of users for the benefit of all users. Anyone can contribute to Wikipedia and anyone can gain access to the information available on Wikipedia. However, with OSS the underlying contributions is source code. Examples of OSS include — GNU/Linux, GNU GPL, GIMP, Apache web server, VLC, Mozilla Firefox, etc.
Key Features of OSS
The Open Source Initiative (OSI) is a software industry group which provides an information repository of and comprehensive framework for licensing OSS, among other useful resources for OSS communities. The OSI has outlined certain criteria for software to qualify as OSS, which are important for tech startups to note. In summary, these include that –
(A) the OSS license should not have redistribution restrictions i.e. any party can sell or give away the software and no fee or royalty is required;
(B) the program should include access to the compiled source code and allow for distribution of the source code in compiled and uncompiled form, including to downstream users in certain licenses;
(C) OSS license must permit modifications and derivative works as well a distribution of same;
(D) OSS license may restrict distribution of modified source code by including a requirement for inclusion of patch files in the distribution or giving the modified version a different name or version number to preserve the integrity of the original contributor’s source code;
(E) OSS licenses should not discriminate against persons, groups or fields of endeavor and ought to be technology neutral.
(F) OSS licenses should provide attribution to the original creator;
Types of OSS Licenses
Notwithstanding their free access nature, OSS licenses typically vary in terms of the restrictiveness of their requirements for later redistribution of the source codes and modifications. Author, Van Lindberg, identifies 5 categories of licenses and it is important for tech startups to note the specific terms of the OSS license which they utilize and ensure they abide by such terms. For the purpose of analogy let’s think about the underlying source code for open source as the design specifications for a sports car.
· Academic licenses — These OSS licenses are named as such due to their origin with universities. They are the least restrictive and typically only require downstream users to disclose the copyright notice is redistributions and not much more. An example is MIT’s OSS License which states that — “the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software” referring to the copy right notice in the license. Under our analogy above, the academic license would require you to share the original design specifications along with the car, but there would be no further requirement to share your modifications or improvements of the design specifications which make the sports car more fuel efficient.
· Permissive licenses — Permissive OSS licenses contain slightly more restrictions than academic licenses, particularly as relates to patents or trademark provisions. However, permissive licenses do not require the same license to be applied to the user’s modifications when distributed. An example of this is the Apache 2.0 license. This license states that “you may provide additional or different license terms and conditions for use, reproduction or distribution of your modifications”. Using the analogy, the permissive license would permit you to provide different license terms for your modifications, such prohibiting further distribution of your modified design specifications.
· Limited (Weak) reciprocal licenses — These allow the creation of closed source software using OSS on one hand and mandates code sharing on the other. The code which must be shared would be the original source code and modifications to same (improvements or derivative works). However, such licenses allow the contributors to exclude larger packages which combine the OSS with non-OSS code, from the licenses and code which has been deleted by a contributor. See Mozilla OSS license 1.1. In essence the IP rights to the non-OSS codes are not distributed to the downstream user. In terms of the design specification analogy, this license would require you to disclose your modified design specifications along with the original specifications. However, if you have combined the original design specifications with your own independently developed design, then you may exclude your independently developed design from the open source license when you distribute.
· Strong reciprocal licenses — Strong reciprocal licenses (“copyleft licenses”) require each distribution of a program to include licenses to all the source codes, and allow modification and further distribution by other users under the same reciprocal license. It applies to the original source code and any derivative works of the original source code. The only situation in which larger works may be excluded from the license is if the larger work is for personal use or for use only within an organization or if the non-OSS component of the larger work is distributed as a separate work. Otherwise, once there is a distribution of the whole work including the OSS and non-OSS source code, then the same OSS license is required to be granted to all users of the distributed work. See GNU GPL. Under this license, you would be required to share the original design specifications, modifications and improvements as well as independently developed designs which are combined with the original design. In essence, the original licensor is saying, if I share my code with you, you have to share yours with others.
· Network reciprocal licenses — These licenses require the source code to be provided to persons who interact with the software over a network. Some network reciprocal licenses limit the license to just modified versions of the software, while others require that the entire source code be provided to all users.
Enforceability of OSS Licenses
OSS licenses encompass copyright protection generally and in some cases patent and trademark protections under IP law. In essence, the OSS licensor(s) have the right to enforce its terms against non-compliant licensees under IP law. US courts have upheld these rights in a number of cases, finding that where an OSS license has set conditions which restrict the use of the source code/software, a violation of such conditions constitutes copyright infringement. Although there has been no firm guidance by US courts on certain other IP issues that may arise in the use of OSS, for example in the context of application of the GPL to “collective works” vis-à-vis “derivative works”, the broad legal rule as stated above provides a good starting point for startups to contemplate in opting to use OSS.
How to Decide on the Right License
Tech startups have to consider the terms of the different types of OSS licenses vis-a-vis their business objectives in deciding which license is the best fit. This is especially so, considering the varying degrees of complexity and restrictions associated with the different types of licenses. Whether you are developing outbound OSS to be shared with a community or you’re considering incorporating OSS into your products, you should ask yourself, to what extent you would be willing to distribute your source code to your customers as may be required by the more restrictive licenses?
Tips for optimizing your startup’s use of OSS
With the potential complexities surrounding the use of OSS, it may be helpful for tech startups using OSS, to develop policies and strategies, including administrative mechanisms, that ensure compliance and/or protection in their use of OSS. The guiding principles which you may adopt include — (i) applying software procurement guidelines to OSS, similar to the guidelines for proprietary software with adjustment where necessary; (ii) maintaining an OSS review board, consisting of management, engineers and lawyers who will holistically scrutinize the use of OSS and make decisions; (iii) tracking the use of OSS in a license database and also creating an internal open source repository which could delineate allowed uses and products and those that are not permitted; (iv) applying different levels of review to different OSS uses and/or different license types (the most detailed review applying where there are modifications of the OSS components and distributions to customers or in the case of strong reciprocal licenses); (v) allow for flexibility in decision making on the use of OSS e.g. denial of use, approval for internal use only (with or without conditions) or approval for customer distribution (with or without conditions); (vi) for OSS which you create and then open up to an external community, be sure to put in place licensing agreement to govern contributors and use standardized OSS licenses approved by OSI.
In conclusion, given the intricacies of the use of OSS particularly its IP implications, it is important to seek the advice of experts in technical and legal aspects in OSS when deciding to create, use or distribute OSS or derivative works from same.
Below is a sample OSS checklist which you can use to determine whether you are using or creating OSS and/or the type of OSS license you are using.
