V. Open Source Software

 

V.A. Historical Analysis of Open Source Movement

The open source movement began in 1955 when IBM created a study group named IBM USER GROUP SHARE. The group was created in order to exchange coding materials and to have a deeper understanding of the IBM’s OS System. The story of code sharing is also familiar with the UNIX operating system. The UNIX system developed by the Bell Labs helped put the programming community in-touch through UseNet. UNIX was free for universities and scientific institution. Those institution and research center improved this system and open the source codes of this system. By the early 1990s, UNIX dominated the infantine internet and sharing source code improved development of technology to a new height.

In the early 1984, the free software political idea was popularized by Richard Stallman when he formed the Free Software Foundation and its GNU project. Stallman believed that people should have more freedom and should appreciate their freedom. So, he designed a set of rights that he felt all users should have and codified them in the GNU (General Public License or GPL). He later named the license as “copyleft” because it leaves the right to copy in place. Stallman himself developed important works of free software as the GNU C Compiler and the GNU Emacs. The Open Source Definition started a life as a policy document of the Debian GNU/Linux Distribution. Debian, an early Linux System and one still popular today, was built entirely of free software. However, since there were other licenses, other than the copyleft, that purported to be free, Debian had some problem defining what was free, and they have never made their free software policy clear to the rest of the world.^[1]

 

V.B. The Open Source Definition

Open source in itself is not a software license. It’s a specification that grants customers access to the software’s source code. It also permits modification of the software and redistribution of both the original and the new, modified version. 

Open source is not necessarily free.

Open source is often confused with “free.” Open source isn’t necessarily free. Licensor’s can charge for software and still be considered open source providers, so long as they don’t charge any additional fee or royalty for source code or for the right to modify or redistribute. But because each recipient can redistribute the software at any price or at no price at all, market keeps licensor from charging a lot. As a result, most open source software actually is free or very inexpensive.^[2]Most of the licensors do not care about getting money from the software. They generate revenue from the professional services directly related to the software.

Open source is not public domain.

Open source is often confused with Public Domain and which is not the case. A public domain software is entirely free of copyright and other intellectual property restrictions. There is no need to license or to copy, modify, or distribute new versions of a public domain software. Open source, on the other hand, is licensed by definition. The only difference is that the license grants freedom that is not common in commercial or proprietary licenses.^[3]

Advantages of open source.

Evolution is the key advantage of open source software. When it circulates widely and developers can fix bugs, add new modules and otherwise revise, the software improves. If the various improvement circulate, recipients will choose the best ones and use and distribute those. So as a result, software quality increases through natural selection.^[4] On the other hand, programmers feel comfortable contributing to open source because they are assure of the following rights:

• make copies of the program, and distribute those copies;
• to have access to the software’s source code, a necessary preliminary before you can change it; and
• to make improvements to the program.

These rights are important to software contributor because they keep all contributors at the same level relative to each other. Anyone who wants to is allowed to sell an open source program, so prices will be low and development to reach new markets will be rapid. Anyone who invests time to build knowledge in an open source program can support it, and this provides users with the option of providing their own support, or the economy of a number of competing providers. Any programmer can tailor an open source to specific markets in order to reach new customer. People who do these things are not compelled to pay royalties or license fees.^[5]

Disadvantage of open source.

Open source software comes with a few disadvantages for commercial software vendors. Recipients of open source can distribute the software and compete with the original licensor, limiting license revenues. Also, open source often includes sensitive techniques, and revealing it shares those techniques with competitors. Finally, open source licenses include additional restrictions that cause problems for commercial developers, example is the “copyleft.”

Open Source Initiative (OSI).

The Open Source Initiative (OSI) was established by Eric Raymond and Bruce Parens in 1998. It is a non-profit organization whose mission is to promote the use of open source software most particularly in proprietary applications. The organization was formed because of the perceived opportunity represented by Netscape’s opening it browser code. The FSF, founded in 1985 before the internet revolution had represented a more activist or ideological position that advocated the eventual complete disappearance of proprietary software, an attitude that arguably fostered suspicion in the business community. The OSI was founded to counter commercial concerns about what free and open software mean. The very term “open source’ that is now universally recognized originated much later than the “free software” promoted by FSF. The term came about as a result of meeting occasioned by the Netscape’s opening of its Navigator code in 1998. It was coined by Chris Peterson and was motivated by both the ambiguity of the word “free,” which at least sounded like it meant “free of charge,” and the impression that the free software movement could be perceived as being anti-commercial, even though this was not the intent of the FSF. But the new description was also a “proxy” for a wider spectrum of issues in the open source community about the community’s relation to the business world.^[6]

The open source definition is a specification of what is permissible in a software license for that software to be referred to as open source. Open source does not simply mean access to the source code. The OSI Foundation maintains a list of approved licenses which it recognizes as consistent with the basic principles of open source development. Software distributed under any of these licenses can be labeled as OSI-certifiedOpen Source Software. There are ten certification criteria that OSI-certified license must satisfy.^[7] These descriptions are paraphrased from the official statement on the OSI Website.

1. Free Redistribution
   

   This means that the license shall not restrict any party from selling or giving away the software as component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. The recipient can make any number of copies of the software, and sell or give them away and don’t have to pay for the privileges.

2. Source Code
   

   The program must include source code, and must allow distribution in source code as well as compiled form. If the program is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge.

   Source code is a necessary preliminary for the repair of modifications of program. The intent here is for source code to be distributed with the initial work, as well as derived works.

3. Derived Work
   

   The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

   Modifications must be allowed. However, it is not required that any producer of a derived work must use the same license terms, only that the option to do so be open to them.

4. Integrity of the Author’s Source Code
   

   The license may restrict source code from being distributed in modified form only if it allows the distribution of ‘patch files’ with the source code for the purpose of modifying the program at build time.

   Some authors were afraid that others would distribute source code with modifications that would be perceived as the work of the original author, and would reflect poorly on the author. This gives them a way to enforce a separation between modifications and their own work without prohibiting modifications.

5. No Discrimination Against Persons or Groups
   

   The license must not discriminate against any person or group of persons.

6. No Discrimination Against Field of Endeavor
   

   It must not restrict anyone from making use of the program in a specific field of endeavor. It may not restrict the program from being used in a business, or from being used for generic research.

7. Distribution of License
   

   The rights attached to the program must apply to all to whom the program is redistributed, without the need for execution of an additional license by those parties. The license must be automatic with no signature required.

8. License Must Not be Specific to a Product
   

   The rights attached to the program must not depend on the program being part of a particular software distribution, if the program is extracted from the distribution and used or distributed within the terms of the program’s license. All parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software
   

   License must not insist that all other programs distributed on the same medium must be open source software.

10. License Must be Technology – Neutral
    

    There should be no provision of the license may be predicated on any individual technology or style or interface.

 

V.C. Two Types of Open Source: Copyleft & Permissive (or Less Restrictive)

Copyleft

The GPL incorporates a novel licensing concept introduced by the free software movement called copyleft. Copyleft is intended to avoid some of the downside associated with putting a product in the public domain, particularly the consequence that public domain software can be embedded in proprietary products. While the copyright law limits the right of others to copy and redistribute a work, copyleft has complementary intent, whence it oddly reversed the name. Copyleft requires that anyone who receives a copy of a work, such as the source code for a program, receives the right to copy, modify, and redistribute the original work and derived modifications of the work, but only if they agree to the obligation that if they distribute such modifications, they do so under the same liberal conditions under which they received the work.^[8] As described by gnu.org, “Copyleft says that anyone who redistribute the software, with or without changes, must pass along the freedom to further copy and change it.” The copyleft intent is asserted in the license that accompanies the original work that requires that all redistributed copies of the work and its derivatives must be distributed under the same license, which results to a recursive propagation of the original copyleft-restricted license. The owner of the original work preserves his own copyright ownership.

Copyleft has been coined in the IT industry “viral.” Since the recipient of the software is required to use the open source model if they redistribute, e.g. “if developer distributes one of these derivatives works, it has to use the open source model.” As a copyleft hater might put it, if copyleft software gets into another program, it “infects” that program, turning it into an open source software.^[9]

Copyleft creates a nightmare to software developers. A developer who is working on a small amount of copy-left licensed software in a massive system without telling anyone – could ‘infect’ the whole system. It now becomes an all-open source. Even worse, the developer’s customers and distributors face the same problem. If they create derivative work by combining the “infected” software with any of their own systems, they will also catch the copyleft virus. The result would be a tremendous loss of revenue invested in commercial software that wasn’t intended, in the first place, to be open source.^[10]

Permissive (Less Restrictive)

Most open source licenses do not have the copyleft provision. They let recipient include open source software in a larger program and then distribute the program under just about any terms it wants, with or without the open source model. Permissive licenses do not restrict the licenses under which acts can be done. Recipient can add their own copyright statement to their modifications and may provide additional or different license terms and conditions.

Advocates of permissive license take a position similar to that of social libertarians. To them, licensing restrictions means that it is not a free license at all. While the name copyleft is meant to suggest an alternative to conventional copyright, supporters of permissive license argue that copyleft licensee simply replace one set of restrictions with another, even though the copyleft restrictions are far milder than those of copyright.^[11] In addition, supporters of permissive license argue that the alternative encourages the use of free software

 

V.D. Consequences of Not Complying the Terms & Conditions of Open Source License

There has been more litigation surrounding Open Source Software (OSS) in the recent years. The consequences of breaking an open source license can be dreadful. Care must be taken both when using OSS, when distributing modifications of OSS, and when basing new software on OSS.

BusyBox Litigation (2007)

The BusyBox litigation claimed to be the first lawsuit over a GPL violation. The case was filed before the USDC in the Southern District of New York on September 20, 2007 by the Software Freedom Law Center (SFLC) on behalf of Anderson and Landley against Monsoon Multimedia, Inc. after BusyBox code was discovered in a firmware upgrade and attempts to contact the company has failed. The case was later settled with release of the Moonsoon’s version of the source code and payment of an undisclosed amount to Anderson and Landley. The following years, a series of lawsuits were filed against companies in relation to the same software. Multiple companies, including Verizon, BestBuy, JVC, Samsung and among others, were accused of using the BusyBox software without complying the GPL requirements. Every case was settled in court. It is important to note that none of the lawsuits filed has something to do with modifications of the code.All lawsuits brought was simply for violating the requirements of the GPL such as the requirement to include the source code and the requirement to include attribution. So even if you do not modify the code, you still get in trouble if you do not abide with the requirements stipulated in the license.

Jacobsen v. Katzer (2008)

Jacobsen v. Katzer is the most important case to date on OSS. Robert Jacobsen (plaintiff), through an open-source software group called Java Model Railroad Interface (JMRI), created a computer program called DecoderPro. DecoderPro was an open-source program that allowed enthusiasts to program model-train decoder chips. It was available on a site known for open-source software collaboration called SourceForge. The DecoderPro was free to download, but its use, distribution, and modifications to the code were subject to the terms of the artistic license (the license). If a user did not want to meet one of the specified terms for allowing modification of the code, such as making the modifications freely available to others, the user could negotiate other arrangements with Jacobsen. Matthew Katzen (defendant), through his company Kamind Associates, Inc., downloaded the DecoderPro source code and modified a portion for use in another computer program, Decoder Commander. Katzen’s program did not meet any of the listed terms stated in the license to allow modification, and Katzen did not negotiate alternate terms with Jacobsen. Jacobsen sued Katzen for copyright infringement. Katzen argued that he had a license to use DecoderPro, because it was open-source software, and that Katzen therefore could not be liable for copyright infringement.^[12]The court ruled in favor of the plaintiff stating that failure to adhere to the requirements of open source license revoked the defendant’s license to use the software causing the defendant to be liable for copyright infringement. Generally, a copyright owner who grants non-exclusive license to use his copyrighted material waives his right to sue the licensee for copyright infringement and can only sue for breach of contract. However, if the license is limited in scope and the licensee acted outside of what is stipulated, the licensor can bring an action for copyright infringement. The test is “whether breach of license is actionable as copyright infringement or breach of contract turns on whether provision breached is condition of the license, or a mere covenant.” The court used factors such as the express language of the license and the traditional language used (provided that) in the analysis. The artistic license attached to Jacobson’s software used traditional language of conditions by noting that the rights to copy, modify, and distribute are granted provided that the conditions are met. The conditions referred is “that the user insert a prominent notice of each changed filed stating how and when the user changed that file,” in conjunction with one of four other listed requirements. The court found that the restrictions were both clear and necessary to accomplish the objectives of the open source licensing collaboration, including economic benefit, and were vital to enable the copyright holder to retain the ability to benefit from the work of downstream users. The right of a copyright owner to benefit economically from her work is a basic right, which the law is designed to protect. Notably, the court found that Jacobson’s economic right was violated even though he did not directly profit from the licensing of the works in question. The court explained that the “attribution and modification [notice] requirement directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder that the law will enforce.^[13]

The Versata Case (2015)

“Testing the GPL; Carelessness can be costly.” The Versata Case consists of five independent litigation proceedings involving the incorporation of XimpleWare’s open source software by Versata Software into its proprietary Distribution Channel Management (DCM) software. XimpleWare’s software was made available to Versata under a GPLV2 license. The DCM software was in turn licensed by Versata to various enterprise customers. Versata had used the XimpleWare software in its product, but failed to comply with the terms of the GPLV2 license. The GPLV2 license required Versata, when providing its software to its licensees, to display the text of the license, attribute ownership, and provide a copy of the source code of the XimpleWare software. Versata failed to carry out any of these actions.

Ironically, the proceedings began with Versata suing one of its customers for copyright infringement, leading to the discovery of Versata’s skeletons in the closet. XimpleWare promptly filed suit. All of the proceedings are before the trial courts, except one which has settled. The four issues arising out these cases are regarding: ^[14]

1. What are the remedies for breach of the GPLv2;
2. What “distribution” is under the GPLv2 (a “distribution” triggers the license obligations);
3. Whether the GPLv2 includes a patent license; and,
4. What type of integration between proprietary software and GPLv2-licensed software results in the creation of a “derivative work”, subjecting the proprietary software to the terms of the GPLv2.

The court applied the Fifth Circuit’s two-pronged test to determine if the contract claims were pre-empted by copyright law.^[15] The first prong requires a simple determination as to “whether [the claim] falls within the subject matter of copyright.” The second prong, “the ‘extra element’ test, . . . asks whether the asserted cause of action requires proof of ‘one or more qualitatively different elements’ than a copyright infringement claim.”^[16] If the claim is within the subject matter of copyright and there are no “extra elements,” then the state contract claim is pre-empted. Even where the first prong is satisfied, any additional right or “extra element” identified by the court may sustain the state court contract claim. The court found that the GPLv2 contained an extra element, the “viral component.” The court held that Ameriprise claim that Versata failed to disclose the source code of its product was the breach of a contract term:

By virtue of this holding, the court found it unnecessary to rule on whether Ameriprise should be considered a third-party beneficiary of the GPLv2 between XimpleWare and Versata. “Having found no basis for federal jurisdiction over this claim, the Court need not determine whether Ameriprise has standing to enforce the GPL as a third-party beneficiary.” The Versata court held that the obligation to release code to downstream customers was an “extra element,” squarely placing enforcement within the realm of state contract law. This leaves open the possibility that a customer may be able to compel disclosure of source code directly against the software company on a theory that it is a third-party beneficiary of the agreement between the developer and software company.

The case settled before the state court had a chance to rule on whether disclosure could be compelled on this theory. However, the mere fact that the federal court did not find copyright preemption opens software company users of GPL-licensed code to a greater risk of litigation and compelled disclosure.^[18]

In Jacobsen, the court found that affirmative obligations to affix copyright notice and attribution were conditions to a license. In Versata, the court found that an affirmative obligation to distribute source code along with a program is an “extra element” enforceable under contract law. These rulings, while not exactly contradictory, blur the line between contract enforcement and copyright enforcement.

Caveat: Not all Open Source Licenses are Licenses; Some are Agreements.

While the Free Software Foundation licenses —GPL, GNU Lesser General Public License, and GNU Affero General Public License — have always been couched as licenses and only enforceable through copyright law, some open source “licenses” are intended as true agreements. A primary example of a license of this nature is the Common Public License and its progeny, the Eclipse Public License (“EPL”).^[19]

The preamble to the EPL states: “The accompanying program is provided under the terms of this Eclipse Public License (“Agreement”). Any use, reproduction, or distribution of the program constitutes recipient’s acceptance of this Agreement. “While the term “license” is used to title the body of text, it is clear that the author intended it at least be thought of and referred to as an agreement. The EPL contains further evidence that it is intended to be construed under the law of contracts. The EPL contains “boilerplate” language typically found in contracts. Perhaps most tellingly, the EPL contains a choice of state law clause. Not all open source licenses are licenses; careful examination of the license is required to determine how it might be enforced. ^[20]

Caveat: The open source definition was not intended to be a legal document. However, to be open source, all of the terms and conditions provided by the Open Source Initiative must be complied

An Overview of the Various Licenses

	BSD	Apache	GPLv2	LGPL
Copyleft?	No	No	Strong	Weak
Distribute Object Code without providing source code?	Yes	Yes	No	No
Distribute Derivatives Under a different License?	Yes	No	No	No
Copyright Notice Required?	Yes	Yes	Yes	Yes
Copy of License Required?	No	Yes	Yes	Yes
Notice of Changes Required?	No	Yes	Yes	Yes
Legal Information Required	No	No	No	No

 

V.E. GNU General Public License

 

General Public License

GNU General Public License, version 3 (GPLv3)

GPLv3 is one of the most restrictive licenses. It offers high protection for the author of the software.^[21]

• The source code must be made public whenever a distribution of the software is made.
• Modifications of the software must be released under the same license.
• Changes made to the source code must be documented.
• If patented material was used in the creation of the software, it grants the right for users to use it. If the user sues anyone over the use of the patented material, they lose the right to use the software.

 

GNU General Public License, version 2 (GPLv2)

GPLv2 is also very popular. The main difference from GPLv3 is the clause on patent grants. That clause was added in version 3 to prevent companies from charging users for the use of their patents.

Popular projects using GPLv3 are Bash and GIMP. Linux uses GPLv2.

 

GNU Lesser General Public License (LGPL)

The LGPL was developed as a compromise between the strong copyleft of the GNU General Public License (GPL) and more permissive licenses such as the BSD licenses and the MIT License. The word “Lesser” in the title shows that the LGPL does not guarantee the end user’s complete freedom in the use of software; it only guarantees the freedom of modification for components licensed under the LGPL, but not for any proprietary components.

The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, “used by”) a non-(L)GPLed program, regardless of whether it is free software or proprietary software. The non-(L)GPLed program can then be distributed under any terms if it is not a derivative work. If it is a derivative work, then the program’s terms must allow for “modification for the customer’s own use and reverse engineering for debugging such modifications.” Whether a work that uses an LGPL program is a derivative work or not is a legal issue. A standalone executable that dynamically links to a library through a .so, .dll, or similar medium is generally accepted as not being a derivative work as defined by the LGPL. It would fall under the definition of a “work that uses the Library”. Paragraph 5 of the LGPL version 2.1 states: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. Essentially, if it is a “work that uses the library”, then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use “a suitable shared library mechanism for linking”. Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.^[22]

The GPL license grew out of the GNU project which began in 1983 by Richard Stallman. The purpose of the GNU project was to provide nonproprietary, UNIX-compatible operating system built openly available source code that could be copied, modified, and redistributed under terms compatible with the free software movement and none of which was subject to the original AT&T proprietary software license for UNIX. Shortly after the GNU project started, Stallman founded the FSF in 1985 to financially support the GNU project and advocate the principles of free software. The FSF defined the GNU GPL which would become the most widely used license of the free and open software movement.^[23]

FORM 1 - GNU General Public License Version 3

FORM 2 - Library or “Lesser” General Public License (LGPL) Version 3

FORM 3 - General Public License, version 2

 

V.F. Apache License

 

Apache License

Apache License 2.0 offers more flexibility to the users.^[24]

• The source code doesn’t need to be public when distribution of the software is made.
• Modifications to the software can be release under any license.
• Changes made to the source must be documented.
• It offers the same patent usage protection as of GPLv3.
• It explicitly prohibits the use of trademark names found on the project.

Popular projects using Apache License 2.0 are Android, Apache, and Swift.

The Apache License is an open source software license released by the Apache Software Foundation (ASF). It is popular and widely deployed license backed by a strong community. The Apache License allows you to freely use, modify, and distribute any Apache licensed product. However, while doing so, you’re required to follow the terms of the Apache License. The Apache Group (later named the Apache Software Foundation) released the first version of its license in 1995, but it’s rare that you’ll come across components that still carry this license.^[25]

In 2000, when Berkeley accepted the argument put to it by the Free Software Foundation and retired their advertising clause from the BSD license and formed the modified BSD license, Apache did likewise and created the Apache License version 1.1. Removing the advertising clause meant that the advertising materials of the derivative works of any Apache licensed product were no longer required to include the Apache License attribution. It became okay to include the attribution in the documentation alone.

In 2004, the ASF decided to depart from the BSD model a little more radically and produced the Apache License version 2.0 by granting patents rights and defining solid definitions of the concepts it uses to make it more coherent.

FORM 1 - Apache License Version 2.0

 

V.G. Berkeley Software Distribution (BSD)

 

Berkeley Software Distribution (BSD)

BSD has two main versions: 2-clause and 3-clause. They both offer more flexibility to the users than the Apache License 2.0.^[26]

• The source code doesn’t need to be public when a distribution of the software is made.
• Modifications to the software can be release under any license.
• Changes made to the source code may not be documented.
• It offers no explicit position on patent usage.
• The license and copyright notice must be included in the documentation of the compiled version of the source code (as opposed to only in the source code).
• The BSD 3-clause states that the names of the author and contributors can’t be used to promote products derived from the software without permission.

Popular projects using BSD license are Go (3-clause), Pure.css (3-clause), and Sentry (3-clause).

BSD Licenses or the original BSD License and its two variants - the Modified BSD License (3-clause), and the Simplified BSD License/FreeBSD License (2-clause) are a family of permissive free software licenses. BSD licenses are a family of permissive free software licenses, imposing minimal restrictions on the use and distribution of covered software. The original BST was used for its namesake, the Berkeley Software Distribution (BSD).^[27] The BSD License lets you freely modify and distribute your software’s code in the source or binary format as long as you retain a copy of the copyright notice, list of conditions, and the disclaimer.^[28]

The original BSD License or the 4-clause BSD License also contains an advertising clause and a non-endorsement clause (detailed explanation about these clauses are offered in the following questions). The modified BSD License or the 3-clause BSD License was formed by removing the advertising clause from the original BSD License. Further, the FreeBSD version or the 2-clause BSD License was formed by removing the non-endorsement clause from the modified BSD License or the 3-clause BSD License.

FORM 1 - Two-Clause BSD

FORM 2 - Three-Clause BSD

FORM 3 - Zero-Clause BSD

 

V.H. MIT License

 

MIT License

MIT is one of the most permissive licenses and the most popular one. It offers very low protection for the author of the software.^[29]

• The source code doesn’t need to be public when a distribution of the software is made.
• Modifications to the software can be release under any license.
• Changes made to the source code may not be documented.
• It offers no explicit position on patent usage.

Popular projects using MIT are Angular.js, jQuery, Rails, Bootstrap, and many more.

You can basically do whatever you want under the MIT software license – ONLY IF you add a copy of the original MIT license and copyright notice to it. Its simplicity is the reason behind its high adoption rate among developers.

The MIT License originated at the Massachusetts Institute of Technology (MIT). As a permissive license it puts very limited restrictions on reuse and because of that it developed an excellent license compatibility. MIT License permits reuse within proprietary software provided that all copies of the licensed software include a copy of the MIT License terms and the copyright notice. It is compatible with many copyleft licenses such as the GNU. It can also be integrated into GPL software, but not the other way around.^[30]

FORM 1 - MIT License

 

V.I. Mozilla Public License 2.0

 

Mozilla Public License 2.0

MPL is a copyleft license that is easy to comply with. Like its predecessor, the Mozilla Public License v 1.1, it seeks to impose a moderate level of ‘copyleft’ restriction on adaptations of code that it covers. It is considered a ‘week’ copyleft, meaning that it covers a subset of works that are ‘based upon’ its covered code. Like its predecessor, the rule which governs whether a specific adaptation must bear the MPL v2 or not is based upon the divisions within the software. Adapted files must remain MPL v2, but entirely new files may bear a license of the adaptor’s choice.^[31] You must make the source code for any of your changes available under MPL, but you can combine the MPL software with proprietary code, as long as you keep the MPL code in separate files.^[32]

Can	Cannot	Must
Commercial or Proprietary	Use Trademark	Include Copyright
Modify	Hold Liable	Include License
Distribute		Disclose Source
Place Warranty		Include Original
Use Patent Claims

The MPL v2 also allows its covered code to be incorporated into projects under a specific set of other ‘secondary’ FOSS licenses (GNU GPLv2, GNU LGPL v2.1, GNU Affero GPL v3 and all subsequent versions of those licenses), thereby expanding compatibility of software it covers.^[33]

FORM 1 - Mozilla Public License Version 2.0

 

V.J. Common Development and Distribution License

 

Common Development and Distribution License (CDDL)

The Common Development and Distribution License (CDDL) is another free and open-source software license produced by Sun Microsystem that was based on the Mozilla Public License or MPL. Files licensed under CDDL can be combined with files licensed under another license whether open source or proprietary. Like the MPL, the CDDL is a weak copyleft license in-between GPL and BSD/MIT permissive license, requiring only source code files under CDDL to remain under CDDL.

• Free to reproduce and distribute any original or derivative works of any software licensed under the CDDL.
• However, removing or making any changes to copyright, patent or trademark notices contained in the software is not allowed.
• Notices of licensing or any descriptive text giving attribution to any contributor or initial developer must be retained.
• If the software is distributed in an executable form (any form other than source code), it is required to make the source code available as well under the CDDL. The executable form may be released under the CDDL or any CDDL compatible licenses.
• The source code that is made available under the CDDL must include contribution as long as they are addition to, deletion from or modification of the contents of a file containing the original software – or new files that contains part of the original program. Which means that addition is made in separate and independent files that do not contain the original code, may not be released under the CDDL. The contributor has the choice, but is not obliged.
• It is required to include a copy of the CDDL with any source code that is distributed. For reach modifications, the modifier must be identified by including notice in the modified files.

CDDL is considered as a weak copyleft license, like the GNU GPL, the MPL or the Eclipse License, requires that you give down-the-stream users of the program the same rights that you yourself received. For that purpose, users are required to distribute the program, including any modified and extended versions of it under the same license. Using this copyleft license component in your code, you will be required to release your entire program as an open source. It essentially means to distribute the original or modified software under the same license that it originally carried. CDDL requires you to release the source code of only the CDDL licensed components that you use or modify in your code under the CDDL. If you distribute your software in its executable form, you are bound to include the source code form but the executable can be distributed either under the CDDL or under a compatible license.^[34] 

CDDL can be combined and used in a commercial product. Sell and resell of software with CDDL components is also allowed. However, if done so – it is required that you release any original or modified CDDL licensed components contained in the modified software under the CDDL only and meet the other terms and conditions of the license mentioned above.^[35]

CDDL licensed components can also be mixed with components licensed under other licenses, whether open source or proprietary. If compiled with other open source licensed components, then these licenses must be compatible with the CDDL. It is always recommended to take special care and – if necessary – consult an attorney when you combine free software with proprietary code or even with other open source licenses.^[36]

FORM 1 - Common Development and Distribution License

 

V.K. Eclipse Public License

Eclipse Public License Version 1.0

The Eclipse Public License (EPL) is another copyleft license. Modifying an EPL’ed component and distribute it in the source code form as part of the program requires disclosure of the modified code. If the program is distributed in its object form, it is required that the source code is made available upon request. It is also requires to share the method for requesting the source code.

The Eclipse Foundation makes clear that, in their opinion, ‘merely interfacing or interoperating’ with an Eclipse plugin does not make your code a derivative work of the plugin. If you redistribute a program with an EPL component, you are obligated to include the full license text and the copyrights.^[37] 

The EPL protects the author from possible lawsuits or damages caused if a company used his/her component in a commercial product. It also offers patent grant.^[38]

It is considered as a weak copyleft license because it only requires the user to disclose source on source code, but not binaries. Hence, the user can therefore compile covered sources with others and distribute the resulting (merged) binaries under the license of his choice. With strong copyleft license, like the GPL family, user is obligated to reuse the same license in case of re-distribution of copies or derivatives on both source and binaries.

Eclipse Public License Version 2.0

In terms of GPL compatibility, the EPL version 2.0 is essentially equivalent to version 1.0. The only change is that it explicitly offers the option of designating the GNU GPL version 2 or later as “secondary license’ for certain piece of code. If an initial contributor releases a specific piece of code and designates GNU GPL version 2 or later as secondary license, that provides explicit compatibility with those GPL versions for that code. However, like the EPL 1.0, the EPL 2.0 without designation remains incompatible with the GPL.

FORM 1 - Eclipse Public License Version 1.0

FORM 2 - Eclipse Public License Version 2.0

 

References:

[1] Bond, “Software Contract Agreements: Drafting and Negotiating Techniques and Precedents,” page 80.

[2] Tollen, “Tech Contracts Academy,” page 247.

[3] Ibid. page 248.

[4] Ibid.

[5] Bond, “Software Contract Agreements: Drafting and Negotiating Techniques and Precedents,” page 79.

[6] Deek, Fadi P., “Open Source: Technology and Policy,”(Cambridge, Cambridge University Press, 2008), page 244.

[7] Open Source Initiative, “Open Source Definition,”https://opensource.org/osd, (Accessed on 6/13/19).

[8] Deek,”Open Source: Technology and Policy,”, page 253.

[9] Tollen, “Tech Contracts Academy,” page 249.

[10] Ibid.

[11] Bayfield, Bruce, Datamation, “Open Source Debate: Copyleft v. Permissive Licenses,” https://www.datamation.com/open-source/open-source-debate-copyleft-vs.-permissive-licenses.html, Accessed on (6/11/19)

[12] Quimbee, “Jacobsen v. Katzer,”https://www.quimbee.com/cases/jacobsen-v-katzer, (Accessed on 6/13/19).

[13] Casetext, “Jacobsen v. Katzer,” https://casetext.com/case/jacobsen-v-katzer, (Accessed on 6/13/19).

[14] Reddy, Jaideep, “The Consequences of Violating Open Source Licenses,”http://btlj.org/2015/11/consequences-violating-open-source-licenses/, (Accessed on 6/13/19).

[15] Versata, 2014 WL 950065.

[16] Ibid.

[17] Ibid.

[18] Arne, Paul H. and Martin, John W IV, “Are Licensing Under the GPL Third Party Beneficiaries?”https://www.mmmlaw.com/files/documents/publications/PLI-Open-Source-2017-Versata-v.-Ameriprise.pdf, (Accessed on 6/13/19).

[19] Ibid.

[20] Ibid.

[21] Free Code Camp, “How open source licenses work and how to add them to your projects,” https://www.freecodecamp.org/news/how-open-source-licenses-work-and-how-to-add-them-to-your-projects-34310c3cf94/, (Accessed on 6/13/19).

[22] Wikipedia, “GNU Lesser General Public License,” https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License, (Accessed on 6/13/19).

[23] Deek,”Open Source: Technology and Policy,”, page 253.

 [24] Free Code Camp, “How open source licenses work and how to add them to your projects,” https://www.freecodecamp.org/news/how-open-source-licenses-work-and-how-to-add-them-to-your-projects-34310c3cf94/, (Accessed on 6/12/19).

[25] White Source, “Open Source Licenses Explained,”https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-explained, (Accessed on 6/12/19).

[26] Free Code Camp, “How open source licenses work and how to add them to your projects,” https://www.freecodecamp.org/news/how-open-source-licenses-work-and-how-to-add-them-to-your-projects-34310c3cf94/, (Accessed on 6/12/19).

[27] Wikipedia, “BST licenses,”https://en.wikipedia.org/wiki/BSD_licenses, (Accessed on 6/12/19).

[28] White Source, “Open Source Licenses Explained,”https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-explained, (Accessed on 6/12/19).

[29] Free Code Camp, “How open source licenses work and how to add them to your projects,” https://www.freecodecamp.org/news/how-open-source-licenses-work-and-how-to-add-them-to-your-projects-34310c3cf94/, (Accessed on 6/12/19).

[30] Wikipedia, “MIT License,” https://en.wikipedia.org/wiki/MIT_License, (Accessed on 6/12/19).

[31] OSS Watch, “The Mozilla Public License version 2 - An Overview,”http://oss-watch.ac.uk/resources/mpl2, (Accessed on 6/19/19).

[32] TLDR Legal, “Mozilla Public License 2.0 (MPL-2.0),”https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2) , (Accessed on 6/19/19).

[33] Ibid.

[34] Sass, Rami, “White Source:Top 10 Common Development and Distribution License (CDDL) Questions Answered,”https://resources.whitesourcesoftware.com/blog-whitesource/top-10-common-development-and-distribution-license-cddl-questions-answered, (Accessed on 6/19/19).

[35] Ibid.

[36] Ibid.

[37] Sass, Rami, “WhiteSource: Top 10 Eclipse Public License Questions Answered,”https://resources.whitesourcesoftware.com/blog-whitesource/top-10-eclipse-public-license-questions-answered, (Accessed on 6/20/19).

[38] Ibid.