A Guide to Open Source Licensing

[article] [edit page] [discussion] [history]

From Humanitarian-FOSS Project Development Site

Contents

A Overview and Guide to Open Source Licensing

What is Open Source Licensing

Open Source Licensing refers to a relatively new class of licenses that have been created to aid in the production and proliferation of open source software. All open source licenses must go through the license review process and conform to the open source definition before their acceptance by the Open Source Initiative as “approved” licenses. This process is not only to review the license to make sure that it conforms to OSI standards, but is also to help categorize the license, prevent redundancy in the creation of licenses, and to make sure that the license will actually work legally.

License Review Process

Submission

The process of submission to the OSI begins with the identification of exactly what kid of submission is being made. The person submitting this license for approval must (with a few exceptions) be the License Steward (i.e. the person with the copyright and ability to change the license). The license holder must then subscribe to the “license-review” public list that the OSI puts out. This is to ensure transparency of debate over the legitimacy of licenses. Once subscribed, the application must be submitted to the “license-review” along with its submission type, license name, and a plaintext copy of the license. To ensure the fairness of the process, the OSI utilizes “Trackers” or neutral people whose job it is to track the application process of a given license and make sure that the process is conducted fairly and effectively.

Types of Submissions

For Update

a for update submission must be made by the License Steward and must include a copy of the old and new licenses along with a new version “redlined” (in which the modifications are highlighted). An explanation of the reason for which the change(s) are being submitted must also be turned in with the new version of the license. If the new version is approved, it will replace the old license.

For New Category

a for new category application is a request to have a license re-categorized by the OSI. The OSI uses categories (such as “Popular and Widely Used”, “Special Purpose”, “Redundant”, “Non-reusable”, etc.) to divide their licenses into more manageable chunks. In the event that a redundant license is updated, becomes non-redundant and more widely used, one might apply for a new category, such as “Popular and Widely Used”. This application can be made by the License Steward, but may also be made by interested licensees. The application must include a rationale for the re-categorization of the license, and the inclusion of supporting public discussions is advisable.

For Retirement

for retirement submissions may only be made by the License Steward, and are requests to retire a given license. If the License Steward wishes, they may name a successor license.

For Legacy Approval

for legacy approval submissions are for existing licenses. These licenses are widely used (or have been in use for an extended period of time), but have never been previously approved by the OSI as “open source licenses”. Applications should include a recommendation of which category the license should be placed in. Because this license already exists and is in circulation (has been proved effective) it doesn't require the same justification as in the approval of a new license.

For Approval

for approval submissions are for the submission of completely new (or extremely limited use) licenses. The application process for new licenses is much more rigorous as it involves a public and transparent revision process. New licenses must also demonstrate a rationale behind the creation of their new license, and redundancy will be examined. Legal analysis of the license is also helpful in the submission of the license as it demonstrates the efficacy/strength of the license in legal settings.

Vetting Process

the OSI is in charge of the review process for submissions. They will discuss the license in the open community through the License Review mailing list. Trackers will file tickets on the application process and will moderate the submission process. The License Review Chair will read the suggestions/opinions of the License Review mailing list and present a summary of the opinions to the OSI board, who will make the final decision. If a license is approved, it will be added to the list of appropriate licenses on the OSI website.

Open Source Definition

There are 10 different criteria for open source, and open source licenses must protect/reinforce these criteria. The Open Source Definition used by the OSI is derived from the Debian Free Software Guidelines.

1.Free Redistribution: The license cannot place restrictions on what the next person does with the code. i.e. If one were to write a code, then license it as open source, someone else may take that code and use it in their product, and then sell it. However, most licenses also require that the derivative works also be open source, so this product may be modified by anyone who buys it.

2.Source Code: Any program licensed under open source licensing must have easily accessible source code. It is expressly forbidden for people to “obfuscate” source code. If not included with the software, the source code must be easily accessible to the public should they decide that they want it. This ensures that programs can continue to evolve, because programmers need the source code to create a new program.

3.Derived Works: All open source software must allow derived works. This furthers the aforementioned “source code”. Online, you can look at a page's source code, but the ability to make changes to that source code and distribute newer versions is what actually makes software evolve and improve.

4.Integrity of the Author's Source Code: If the original author feels that his/her source code is being changed drastically enough, he/she may request that it be distributed under a different name/version. The only time in which the changing of source code can actually be restricted is if the newer version comes along with patches. This is in order to protect the original author. For example, if the SAHANA VMOSS software was adopted by a neo-nazi organization and they wanted to change the program to say “White Power” across the top of the page (along with other hateful changes in the cosmetics), the SAHANA people could demand that their software be left pristine, and the neo-nazi changes be included as an unofficial patch. This would show a clear divide in intent for the software and protect the integrity of the author's source code.

5.No Discrimination Against People or Groups: The license cannot discriminate against any person or type of persons. This ensures that the maximum number of people can work on improving the software. In some countries (including the US), exporting certain kinds of software is forbidden, but that cannot be included in the license. Those restrictions are placed afterwards and separately.

6.No Discrimination Against Fields of Endeavour: The license cannot discriminate about the use of the software in a specific setting. A license cannot stipulate “this software cannot be used in a commercial setting” or “this software cannot be used in the field of genetic research”.

7.Distribution of License: License must be redistributed with the modified source code. This is to prevent inadvertent closing of the source code.

8.License Must Not be Specific to Product: The license cannot limit the licensing of the source code to one software distributor. For example, if Ubuntu releases its code as open source, it cannot stipulate that all of the changes made to their source code must be distributed under their auspices/name.

9.License Must Not Restrict Other Software: The license cannot “rub off” onto separate programs released in the same package. For example, if Trishan got permission from Microsoft and Adobe to release a works suite cd with Microsoft Word (closed) and Adobe Photoshop (closed) and he also packaged Pidgin (open, GPL) with it, the Gnu GPL license would not be forced onto Microsoft Word and Adobe Photoshop. The license can only restrict derivative software or software that uses parts of the licensed source code.

10.License Must be Technology Neutral: The license cannot stipulate which medium the source code is distributed in. If someone wants to release the program on a CD, as a download, or as an online application, then they may (as long as they include the source code or make it readily available).

History of Open Source Licensing

  • Free Software Foundation (FSF) is founded by Richard Stallman in 1985.
  • In 1997/1998 members of the hacker community decide to move away from the stigma of the “free software” movement because of its confrontational history[1]. In its stead they decide to form the open source movement. Linus Torvalds is also on board.
  • Open Source Initiative (OSI) is founded by Eric Raymond and Bruce Perens in late February of 1998.
  • First open source licenses come into existence in the BSD licenses of 1982. However, these licenses are all specific to certain fields and are therefore not truly open source or widely usable.
  • Gnu GPL is the first cohesive and multi-purpose license, and is created by Richard Stallman in 1983.
  • Stallman has historically rejected the term “open source” in favor of “free software”.

Picking a License

Sun Microsystems License Classifications

The Sun Microsystems website includes one of the easiest categorizations of licenses to understand.

Class A: No requirement on derivative works to use the same license. Unrestricted scope of license use (you can use any part and relicense under another license, even a closed one.). With this kind of license you grant “a licensee the discretion to take the licensee’s modifications to the open source code base and turn that modification into a closed source/proprietary piece of software. ”(Lee, 32)

  • BSD, Apache, MIT, Eclipse

Class B: Copyleft licenses that require that the derivative work use the same license as before. Can be licensed under a different license (even closed source) if the work is not derivative and only uses source samples (“indexing”).

  • Common Development and Distribution License, Mozilla Public License

Class C: Strong copyleft licenses that require derivative (and most non-derivative) works to use the same license.

  • Gnu GPL, Gnu LGPL, CPL

Most Used Licenses/Uses

Gnu GPL

Requires users to redistribute modified and derivative software under the GPL again. This is an example of strong copyleft that ensures viral proliferation of the Open Source movement. People might choose the Gnu GPL for its wide use and for the strong focus that it puts on giving back to the Open Source community. “You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the [copylefted] Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.” [2]

BSD

Does not require the user to relicense under BSD, and, in fact, allows the user to redistribute derivative software under a closed license. Good if you don't mind your code being incorporated into proprietary software. Originally the BSD license included an advertising clause which said that anyone could take and redistribute BSD code, so long as they included the contributors in their advertising (I.e. “the shuffle feature used in our iPod was written by Ralph Morelli”).

Apache

Also allows relicensing under a new (and potentially closed) license, but also places a few more restrictions on the user than BSD. Requires attribution to the Apache group in any redistribution of the source code and also includes an open suggestion that people join the open source movement by requiring that redistributed code include the quote “This software consists of voluntary contributions made by many individuals on behalf of the Apache Group” [3].

MIT License

Actually almost indistinguishable from the BSD license, but lacking the requirement that previous contributors remain anonymous without their permission.

Mozilla Public License

More copyleft than permissive, it still falls short of the GPL by allowing some incorporation into proprietary works without considering that work a “derivative”.

Common Public License

Similar to the GPL, but slightly more permissive. Allows for contributors to “link” CPL licensed code to another code and distribute the combined code under a different license. Somewhat hard to understand with some fine print, the CPL also includes a “choice of law” clause (meaning it defines which laws the license is subject to). Because of the ambiguities around it, one might want to consider a different license.

Eclipse Public License

Sort of like GPL, a derivative of the CPL, the Eclipse Public License also allows for contributor “linking” under a different license. However, the Eclipse Public License differs from the CPL in that the EPL removes the “choice of law” clause.[4]

Gnu 'Lesser' GPL

A little more permissive than GPL, but still strong copyleft. Encourages sharing more than GPL by allowing linking of code from a .

Common Development & Distribution License

More permissive than GPL, allows relicensing.

Pro's and Con's

Pro's of OSL

In all cases, these licenses promote the sharing of knowledge and provide for the distribution of code. In the case of copyleft licenses they ensure viral proliferation of the open source movement. Open source licenses also provide for commercial sale of licensed property, which preserves the economic benefits of taking the time to write good code. Also, insofar as Open Source licensing helps to perpetuate the Open Source movement, OSL helps to promote a virtuous society where people can continually give back to the community and further humanity (Benkler and Nissenbaum).

Con's of OSL

Cannot, in most cases, be mixed with proprietary software as there is a conflict of interest meaning you'll have to infringe either the open or closed license in distribution. Also, because of the requirement that Open Source licenses not discriminate on who uses the program/code, one might find oneself in a position where one's code is being used for a purpose that disagrees with them. For example, if a skinhead organization appropriated the VMOSS program to organize hateful marches and activities, the people at Sahana cannot prevent them from using the VMOSS software.

Cases Dealing with OSL

SCO vs. IBM

In the case of SCO vs. IBM, the SCO group decided to sue IBM over the use of some code that SCO claimed belonged to the SCO group. As the trial proceeded and SCO continued to heap more and more allegations of wrongdoing on IBM, it began to become evident that some of the SCO group's software was inherited from their previous takeover of UNIX. Even though SCO had ownership of the Unix code (which, even that was debatable) the had also incorporated Linux code (licensed under the Gnu GPL) into their Unix code, which would consequently have made the Unix fall under the Gnu GPL and would have opened up the Unix code to the public. With the case turned on them (for allegedly stealing the GPL licensed code by not releasing the new code under the Gnu GPL) the SCO group decided to try and prove in court that the Gnu GPL was unconstitutional, which they failed to do. Again in 2003, SCO attempted to publicize IBM's “theft” by releasing the “stolen” source code; this proved unwise, as it was later shown that the “stolen” source code had actually been previously licensed under the BSD license. Furthermore, it appears that the SCO group violated the BSD license as well by removing the original license text from the source code.

Resources

License

Because I have excepted from "Open Source Software Licensing" by Stephen Lee I would like to also include a copy of his license: The Open Literature License, Draft Version 1.0, April 28, 1999 Created by Steve H. Lee. Copyright © Steve H. Lee, 1999. This license is licensed recursively (i.e., the terms of this license applies to the license itself). Everyone is permitted to copy and distribute verbatim copies of this license, see infra Clause 2, so long as the integrity of the author’ work is respected, see infra Clause 3. If anyone has suggestions for improving this license, you can contact the creator of this license at <grokopen@email.com>. 1. Preamble Authors of literary, dramatic, and other creative works, may feel that unfettered accessibility to their works may be beneficial for both themselves and for society at large. Authors may also feel that a collaborative, community-based process of development may be in the best interest of everyone concerned. Some possible examples of these sorts of scenarios are scholarly settings (e.g., peer review), interactive art or theater, and papers that attempt to influence policy and democratic discourse (which may require feedback from the public as well as the ability to make modifications to such a work in order to reflect that feedback). An author in these types of situations could place his/her work in the public domain or simply not enforce his/her intellectual property rights. However, while this may provide the intended benefits to well-intentioned members of the public, this may allow less scrupulous individuals to obtain control over the author’ works in a way that violates the spirit behind the author’ actions. The best way to strike a balance between allowing open access to – and free expression using – the author’ works, and the need to maintain some level of control over the use of the work in order to ensure that the original goals are being met, is by utilizing an open source license. The only problem with using an open source license is that most open source licenses were created with computer software in mind, rather than the more traditional copyrighted works like literature, dramatic works, etc. While open source software licenses have been used to achieve the results described above with non-technological creative works, it may be more suitable to use an open source license specifically designed for literary, dramatic, and other ‘ traditional’works that may or may not be expressed or distributed utilizing information technology.

                                                                                                 111

Open Source Software Licensing Steve H. Lee The Open Literature License is a license designed for creative works that are not automatically associated with information technology. It is suitable for works – such as some types of academic writings, novels, poems, plays, music, etc. – that may be significantly different in character than computer software (of course, computer software can be licensed under any one of the existing open source licenses). Traditional creative works, like literature, drama, etc., may have some issues associated with them that a license covering software does not directly deal with, see infra Clause 7. Some of the other advantages of the Open Literature License is that: (1) It is compatible and consistent with all open source licenses; (2) Allows an author to license his/her works under both the Open Literature License and another open source license; and (3) Does not preclude the author from selling his/her work (Note: This is also true with other open source licenses, see ‘ The Open Source Definition,’Para. 1). The Open Literature License may not be right for everyone. However, if your goals are consistent with allowing open access to your creative works, the Open Literature License may work for you. 2. Consistency and Compatibility with Existing Open Source Licenses The licensee may reproduce, redistribute, and modify this work in accordance with the standards for open source licensing as laid out in ‘ The Open Source Definition,’‘ The Debian Free Software Guidelines,’and/or the standards for ‘ free software’as formulated by the Free Software Foundation, Inc [hereinafter ‘ generally accepted definitions of open source licenses’ The Open Literature License is completely and totally consistent with any and all open source licenses. If any term of this license may be interpreted as being inconsistent with the generally accepted definitions of open source licenses, then such a term can either be interpreted as being consistent with the generally accepted definitions, or it can be excised completely – allowing the remaining consistent and compatible terms of the license to survive. 3. Giving Credit Where Credit Is Due and the Integrity of the Author’s Work In accordance with the generally accepted definitions of open source licenses, the licensee must give credit to the author of the licensed work and must honor the integrity of the author’s work by clearly and expressly identifying those distributions of modified works as being modifications to the original work, unless the author expressly permits the licensee to redistribute these modifications without giving such credit [this can be done by adding a subclause to this section or through another method that is acceptable to the licensor]. However, this clause does NOT prohibit the distribution or redistribution of modified works; this clause is simply designed to give credit where credit is due and to ensure that licensees do not impinge on the integrity of an author’s creation. 4. Derivative Works This license allows licensees to create modifications and derivative works, and allows modified and derived works to be distributed under this license.

                                                                                                 112

Open Source Software Licensing Steve H. Lee

       4.1. Default Term: Derivative Works Must Be Kept Open Unless ....
       The default term – which means that the licensor can opt out of this term if he/she wants
       to – is that derivative works (which includes modifications) must be kept ‘    open’and freely
       (in terms of being free of barriers rather than ‘zero price’ available to the public.)
       However, the licensor can opt out of this term [by adding a subclause or by some other
       means acceptable to the licensor] and, thereby, allow the licensee to ‘   close-off’access to
       derivative works. One way in which the licensee can opt out is by ‘    double licensing’
       his/her work with this license plus a license that does not prohibit the proprietization of
       derivative works (such as the BSD License), see infra Clause 6 (‘    Multiple Licenses’   ).

5. Aggregation (Mandatory Term) and Integration (Default Term) This license allows licensees to aggregate – e.g., placing several works on the same medium of distribution – or integrate – e.g., combining several works at a fundamental level to form a unitary whole – works under this license with works not under this license, whether ‘ open source’or ‘closed source.’Note, however, that the ‘ aggregation’part of this clause is mandatory – it cannot be opted out of by the licensor; the ‘ integration’part is default.

       5.1. Multiple License Exception
       The Clause 5, Integration term is a default term, and, therefore, can be opted out of, see
       description supra Clause 4.1. If the licensor ‘ double licenses’his/her work with this
       license and another license that prohibits the integration of open and closed source works
       (e.g., the GNU GPL), the prohibition trumps the default term of this license permitting
       such integration.

6. Multiple Licenses This license permits the author/licensor to cover his/her works under this license (the Open Literature License) and another open source license, simultaneously. However, closed source licenses cannot take advantage of this multiple licensing clause.

       6.1. A Recommendation: ‘      Double Licensing’
       While the licensor is free to use as many open source licenses as he/she wants in order to
       cover the same works, it is highly recommended that any multiple licensing scheme be
       limited to just two licenses: this license and one other open source license. This may be
       practically and legally necessary since the specific terms of specific open source licenses
       often conflict with each other (e.g., GNU GPL versus BSD Licenses).

7. Analogy to Open Source Code: Intellectual Property Rights Must Not Be Used to Block Access To Licensed Works (But The Licensor Can Sell His/Her Works) Since this license is designed to deal specifically with works that are significantly different, from a technical perspective, from computer software – such as literary, dramatic, and artistic works – an open source software license’ provisions to make computer source code available is of little

                               s
                                                                                                    113

Open Source Software Licensing Steve H. Lee direct consequence. However, we can analogize to the idea of source code availability by making it a condition of this license that any work licensed under the Open Literature License cannot be made inaccessible via the use of intellectual property rights the licensor may have. For example, if William Shakespeare had licensed ‘ Hamlet’under this license, neither Shakespeare nor his descendants can utilize their exclusive rights as copyright holders to prevent access to ‘ Hamlet.’ This should not be interpreted, however, as meaning that Shakespeare – or any other author who uses this license – cannot sell his works. Under the generally accepted definitions of open source licenses, open source licenses cannot prohibit someone from selling the licensed ‘ software,’or, in this case, literary/dramatic work, see, e.g., The Open Source Definition, Para. 1.

        7.1. Regardless of Statutory Extensions of Time Limitations
        This ‘ open accessibility to works’clause applies regardless of whatever the current time
        limitations are under intellectual property statutes. Therefore, in our Shakespeare example,
        Shakespeare and his kin are prevented from using their intellectual property rights to block
        access to ‘Hamlet’– regardless of whether the limits on their copyright runs out at 70, 90,
        100, or a 1000 years. Clause 7, in other words, is in effect indefinitely.

8. This License is ‘ Viral’ This license applies to each recipient and each distributor along the chain of distribution and/or redistribution – including, but not limited to, the original licensor and the original licensee. 9. In Case of Preemption If any of the clauses or subclauses of this license are preempted by federal copyright (or other intellectual property) law or voided as being against public policy (public policy, in this sort of scenario, might be federal copyright law), then all of the other clauses and subclauses that are not legally negated will continue to be in effect. 10. Disclaimer of Warranty [adapted from the Mozilla PL, Version 1.1] THE LICENSED WORK IS PROVIDED UNDER THIS LICENSE ON AN “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE LICENSED WORK IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON- INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LICENSED WORK IS WITH YOU. SHOULD ANY LICENSED WORK PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL AUTHOR/DEVELOPER/ETC. OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY LICENSED WORK IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER. 11. Limitation of Liability [adapted from the Mozilla PL, Version 1.1] UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT

                                                                                                   114

Open Source Software Licensing Steve H. Lee (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF THE LICENSED WORK, OR ANY SUPPLIER OF ANY SUCH PARTIES, BE LIABLE TO ANY PERSON FOR ANY INDIRECT, SPECIAL, GENERAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. 12. The Licensed Work Does NOT Constitute Legal Advice ANY WORK, WHETHER IN WHOLE OR IN PART, UNDER THIS LICENSE DOES NOT CONSTITUTE LEGAL ADVICE OF ANY KIND. EVEN IF A WORK UNDER THIS LICENSE DEALS WITH LEGAL MATTERS – INCLUDING, BUT NOT LIMITED TO, THIS LICENSE ITSELF – IT DOES NOT CONSTITUTE, IMPLIEDLY OR EXPRESSLY, LEGAL ADVICE.

Personal tools