Editing Open-source license (section)

==Types==

{{see also|Comparison of free and open-source software licenses}}

Open-source licenses are categorized as [[copyleft]] or [[Permissive software license|permissive]].{{sfn|Smith|2022|loc=sec.&nbsp;3.2}} Copyleft licenses require derivative works to include [[source code]] under a similar license. Permissive licenses do not, and therefore the code can be used within proprietary software. Copyleft can be further divided into strong and weak depending on whether they define derivative works broadly or narrowly.{{sfn|Sen|Subramaniam|Nelson|2008|pp=211-212}}{{sfn|Meeker|2020|loc=16:13}}

Licenses focus on copyright law, but code is also covered by other forms of IP.{{sfn|Rosen|2005|pp=22-24}} Major open-source licenses written since the late 1990s contain patent grants. These open-source patent grants cover the patents held by the developers.{{sfn|Bain|Smith|2022|loc=sec.&nbsp;10.4.3}} [[Software patents]] cover ideas and, rather than a specific implementation, cover ''any'' implementation of a [[patent claim|claim]]. Patent claims give the holder the right to exclude others from making, using, selling, or importing products based on the idea. Because patents grant the right to exclude rather than the right to create, it is possible to have a patent on an idea but still be unable to legally implement it if the [[invention]] relies on another patented idea. Thus, open-source patent grants can offer permission only from covered patents. They cannot guarantee that a third party has not patented any concepts embodied in the code.{{sfn|Rosen|2005|pp=22-24}} The older permissive licenses do not discuss patents directly and offer only implicit patent grants in their offers to use or sell covered material.{{sfn|Bain|Smith|2022|loc=sec. 10.4.2}} Newer copyleft licenses and the 2004 Apache License offer explicit patent grants and limited protection from patent litigation.{{sfn|Bain|Smith|2022|loc=sec. 10.4.4}} These [[Software patents and free software|patent retaliation]] clauses protect developers by terminating grants for any party who initiates a patent lawsuit regarding covered software.{{sfn|Bain|Smith|2022|loc=sec. 10.4.4}}

Trademarks are the only form of IP not shared by free and open-source software. Trademarks on FOSS function the same as any other trademark.{{sfn|Chestek|2022|p=30}} A trademark is a design that identifies the distinct source of a product. Because they distinguish products, the same designs can be used in different fields where there is no [[Confusing similarity|risk of confusing similar]] sources.{{sfn|Chestek|2022|pp=184-185}} To give up control of a trademark would result in the loss of that trademark. Therefore, no open-source license freely offers the use of a trademark.{{sfn|Rosen|2005|p=38}} 

Trademark restrictions can overlap copyrights and affect material otherwise freely available.{{sfn|Joy|2022|p=986}} The US Supreme Court described using trademark law to restrict public domain content as "mutant copyright".{{sfn|Joy|2022|p=989}} In ''[[Dastar Corp. v. Twentieth Century Fox Film Corp.]]'', the court "caution[ed] against misuse or over-extension of trademark" law without providing a firm decision on those mutant copyrights.<ref>{{cite court |litigants=Dastar Corp. v. Twentieth Century Fox Film Corp. |vol=539 |reporter=U.S. |opinion=23 |court= |date=2003 |pinpoint=34 |url=https://scholar.google.com/scholar_case?case=13445605668854417212#p34}}</ref>{{sfn|Joy|2022|pp=987-988}} Trademark overlap can leave open-source and free content projects vulnerable to a "hostile takeover" if outside parties file for trademarks on derivative works.{{sfn|Joy|2022|pp=1004–1006}} Notably, Andrey Duskin applied for trademarks on the [[SCP Foundation]], a collaborative writing project, when creating derivative works based on SCP stories.{{sfn|Joy|2022|pp=979, 1002}}

===Permissive===
{{main|Permissive software license}}

[[File:MIT Dome night1 Edit.jpg|alt=M I T campus at night|thumb|Permissive licenses generally originate in academic institutions like the [[Massachusetts Institute of Technology]].]]

[[Permissive software license|Permissive licenses]], also known as academic licenses,{{sfn|Rosen|2005|p=69}} allow recipients to use, modify, and distribute software with no obligation to provide source code. Institutions created these licenses to distribute their creations to the public.{{sfn|Rosen|2005|p=69}} Permissive licenses are usually short, often less than a page of text. They impose few [[wikt:condition#Noun|conditions]]. Most include disclaimers of warranty and obligations to [[Credit (creative arts)|credit]] authors. A few include explicit provisions for patents, trademarks, and other forms of intellectual property.{{sfn|Rosen|2005|pp=101-102}}

The [[University of California, Berkeley]] created the first open-source license when they began distributing their [[Berkeley Software Distribution]] (BSD) operating system. The [[BSD license]] and its later variations permit modification and distribution of the covered software. The [[BSD license]]s brought the concept of academic freedom of ideas to computing. Early academic software authors had shared code based on implied promises. Berkeley made these concepts explicit with clear disclaimers for liability and warranty along with conditions, or [[wikt:clause#Noun|clauses]], for redistribution. The original had four clauses, but subsequent versions have further reduced the restrictions. As a result, it is common to specify if the covered software uses a 2-clause or 3-clause version.{{sfn|Smith|2022|loc=sec.&nbsp;3.2.1.1}}{{sfn|OSI|2023}}

The [[Massachusetts Institute of Technology]] (MIT) created an academic license based on the BSD original. The [[MIT license]] clarified the conditions by making them more explicit.{{sfn|Rosen|2005|pp=73-90}} For example, the MIT license describes the right to [[wikt:sublicense#English|sublicense]].{{sfn|OSI|2023|loc="The MIT License"}} One of the strengths of open-source development is the continual process where developers can build on the derivative works of each other and combine their projects into collective works. Explicitly making covered code sublicensable provides a legal advantage when tracking the chain of authorship.{{sfn|Rosen|2005|pp=73-90}} The BSD and MIT are template licenses that can be adapted to any project. They are widely adapted and used by many FOSS projects.{{sfn|Smith|2022|loc=sec.&nbsp;3.2.1.1}}

The [[Apache License]] is more comprehensive and explicit. [[The Apache Software Foundation]] wrote it for their [[Apache HTTP Server]]. Version 2, published in 2004, offers legal advantages over simple licenses and provides similar grants.{{sfn|Smith|2022|loc=sec.&nbsp;3.2.1.2}} While the BSD and MIT licenses offer an implicit patent grant,{{sfn|Bain|Smith|2022|loc=sec.&nbsp;10.4.2}} the Apache License includes a section on patents with an explicit grant from contributors.{{sfn|OSI|2023|loc="Apache License, Version 2.0"}} Additionally, it is one of the few permissive licenses with a patent retaliation clause.{{sfn|Bain|Smith|2022|loc=ch.&nbsp;10}} Patent retaliation, or patent suspension, clauses take effect if a [[wikt:licensee#English|licensee]] initiates [[patent infringement]] litigation on covered code. In that situation, the patent grants are revoked. These clauses protect against [[patent trolling]].{{sfn|Bain|Smith|2022|loc=sec.&nbsp;10.4.4}}

===Copyleft===
{{main|Copyleft}}
[[File:"Copyleft (L)" sticker, from an envelope mailed from Don Hopkins to Richard Stallman in 1984..jpg|alt=A sticker reads, "Copyleft circled letter L".|thumb|The Copyleft sticker from an envelope Don Hopkins mailed to Richard Stallman in 1984]]

[[Copyleft]] licenses require [[source code]] to be distributed with software and require the source code to be made available under a similar license.{{sfn|Sen|Subramaniam|Nelson|2008|pp=211-212}}{{sfn|St. Laurent|2004|pp=38-39}} Like the permissive licenses, most copyleft licenses require attribution.{{sfn|Ballhausen|2019|p=86}} Most, including the GPL, disclaim implied warranties.{{sfn|Rosen|2005|p=135}}

Copyleft uses the restrictions of IP law&mdash;contrary to their usual purpose&mdash;to mandate that the code remain open.{{sfn|Rosen|2005|pp=103-106}} The term and its related slogan, "All rights reversed", had been previously used in a playful manner by the ''[[Principia Discordia]]'' and [[Tiny BASIC]]; the modern usage begins with Richard Stallman's efforts to create a free operating system. In 1984, programmer [[Don Hopkins]] mailed a manual to Stallman with a "Copyleft Ⓛ" sticker. Stallman, who was working on the GNU operating system, adopted the term.{{sfn|Keats|2010|p=64}} An early version of copyleft licensing was used for the 1985 release of [[GNU Emacs]].{{sfn|Williams|2002|loc=ch.&nbsp;9}}<ref>{{cite web |url=https://www.tech-insider.org/free-software/research/1985/0715-b.txt |title=Full Text of GNU Emacs Copying Permission Notice |date=1985}}</ref> The term became associated with the FSF's later reciprocal licenses, notably the [[GNU General Public License]] (GPL).{{sfn|Keats|2010|pp=63-67}}

Traditional, proprietary software licenses are written with the goal of increasing [[Software industry|profit]], but Stallman wrote the GPL to increase the body of available free software. His reciprocal licenses offer the rights to use, modify, and distribute the work on the condition that people must release derivative works under a license offering these same freedoms. Software built on a copyleft base must come with the source code, and the source code must be available under the same or a similar license. This offers protection against proprietary software consuming code without giving back.{{sfn|Rosen|2005|pp=103-109}}{{sfn|Meeker|2020|loc=6:00–7:22}} Richard Stallman stated that "the central idea of copyleft is to use copyright law, but flip it over to serve the opposite of its usual purpose: instead of a means of privatizing software, [copyright] becomes a means of keeping software free."{{sfn|Joy|2022|pp=990-992}} [[Free software licenses]] are also open-source software licenses.{{sfn|Onetti|Verma|2009|p=71}} The separate terms [[free software]] and [[open-source software]] reflect different values rather than a legal difference.{{sfn|St. Laurent|2004|pp=81-83, 114}} Both movements and their formal definitions require the covered work to be made available with source code and with permission for modification and redistribution.{{sfn|Maracke|2019|loc=sec. 2.2}} There are occasional edge cases where only one of the FSF or the OSI accept a license, but the popular free software licenses are open source, including the [[GPL]].{{sfn|Ballhausen|2019|p=82}}

[[File:Mitchell Baker (2).jpg|alt=Portrait of Mitchell Baker|thumb|[[Mitchell Baker]] drafted the Mozilla Public License while on Netscape's legal team.{{sfn|St. Laurent|2004|pp=68, 75}}]]

Practical benefits to copyleft licenses have attracted commercial developers. Corporations have used and written reciprocal licenses with a narrower scope than the GPL.{{sfn|Tsai|2008|pp=564-570}} For example, Netscape drafted their own copyleft terms after rejecting permissive licenses for the Mozilla project.{{sfn|Hammerly|Paquin|Walton|1999}}  The GPL remains the most popular license of this type, but there are other significant examples. The FSF has crafted the [[Lesser General Public License]] (LGPL) for [[Library (computing)|libraries]]. [[Mozilla]] uses the [[Mozilla Public License]] (MPL) for their releases, including [[Firefox]]. [[IBM]] drafted the [[Common Public License]] (CPL) and later adopted the [[Eclipse Public License]] (EPL). A difference between the GPL and other reciprocal licenses is how they define derivative works covered by the reciprocal provisions. The GPL, and the [[Affero License]] (AGPL) based on it, use a broad scope to describe affected works. The AGPL extends the reciprocal obligation in the GPL to cover software made available over a network.{{sfn|Tsai|2008|pp=564-570}}{{sfn|Hammerly|Paquin|Walton|1999}} They are called [[Copyleft#Strong and weak copyleft|strong copyleft]] in contrast to the [[Copyleft#Strong and weak copyleft|weaker copyleft]] licenses often used by corporations. Weak copyleft uses narrower, explicit definitions of derivative works.{{sfn|Sen|Subramaniam|Nelson|2008|pp=212-213}}{{sfn|Meeker|2020|loc=16:13}} The MPL uses a file-based definition, the CPL and EPL use a module-based definition, and the FSF's own LGPL refers to software libraries.{{sfn|Rosen|2005|loc=refer to corresponding chapters}}

===Compatibility===
{{main|License compatibility}}
[[File:Floss-license-slide-image.svg|alt=Chart of license compatibility, full details in section.|thumb|400px|Open-source software licenses and how they interact]]

[[License compatibility]] determines how code with different licenses can be distributed together. The goal of open-source licensing is to make the work freely available, but this becomes complicated when working with multiple terminologies imposing different requirements.{{sfn|Smith|2022|loc=sec.&nbsp;3.3}} There are many [[license proliferation|uncommonly used licenses]] and some projects write their own [[bespoke]] agreements. As a result, this causes more confusion than other legal aspects. When releasing a [[collective work|collection]] of applications, each license can be considered separately. However, when attempting to combine software, code from another project can only be in-licensed if the project uses compatible terms and conditions.{{sfn|Rosen|2005|pp=243-247}}

When combining code bases, the original licenses can be maintained for separate components, and the larger work released under a compatible license.{{sfn|St. Laurent|2004|pp=159-163}} This compatibility is often one-way. Public domain content can be used anywhere as there is no copyright claim, but code acquired under any almost any set of terms cannot be waved to the public domain. Permissive licenses can be used within copyleft works, but copyleft material cannot be released under a permissive license. Some weak copyleft licenses can be used under the GPL and are said to be GPL-compatible. GPL software can only be used under the GPL or AGPL.{{sfn|Smith|2022|loc=sec.&nbsp;3.3}} Permissive licenses are broadly compatible because they can cover separate parts of a project. Multiple licenses including the GPL and Apache License have been revised to enhance compatibility.<ref>See {{harvnb|Smith|2022|p=102}} for: Apache License version 2.0 in 2004, GPL version 3 in 2007, LGPL version 3 in 2007, and AGPL version 3 in 2007. See {{harvnb|Smith|2022|pp=95–101}} for: MPL version 2.0 in 2012 and EPL version 2 in 2017.</ref>

Translation issues, ambiguity in licensing terms, and incompatibility of some licenses with the law in certain jurisdictions compound the problem of license compatibility.{{sfn|Bernelin|2020|pp=100, 102}} Downloading an open-source module is straightforward, but complying with the licensing terms can be more difficult.{{sfn|Ombredanne|2020|p=105}} Because of the amount of software dependencies, engineers working on complex projects often rely on license management software to achieve compliance with the licensing terms of open-source components.{{sfn|Ombredanne|2020|p=106}} Many open-source software files do not unambiguously state the license, increasing the difficulties of compliance.{{sfn|Ombredanne|2020|p=105}}