Difference between revisions of "Licensing"
|(One intermediate revision by one other user not shown)|
|Line 125:||Line 125:|
Sometimes developers choose not to release the entire source code for their projects, and instead only allow public access to ''some'' of the source code while keeping ''other'' parts closed-source. Usually, the core functionality of the program is what becomes source-available while certain bells and whistles remain proprietary, hence the term "open core".
Sometimes developers choose not to release the entire source code for their projects, and instead only allow public access to ''some'' of the source code while keeping ''other'' parts closed-source. Usually, the core functionality of the program is what becomes source-available while certain bells and whistles remain proprietary, hence the term "open core". notable example is seen with [https://about.gitlab.com/ the GitLab project], where the GitLab developers offer a paid Enterprise Edition with features compared to the freely available core code in the Community Edition.
While there's some debate as to whether the stripped-down, fully source-available versions of these programs could count as FLOSS, the model as a whole is undoubtedly not fully in keeping with the ideals of the open-source movement, and it's
While there's some debate as to whether the stripped-down, fully source-available versions of these programs could count as FLOSS, the model as a whole is undoubtedly not fully in keeping with the ideals of the open-source movement, and it's considered a compromise outside and/or code reuse .
==CLA (Contributor License Agreement)==
==CLA (Contributor License Agreement)==
Latest revision as of 18:49, 29 June 2022
Source code is copyrightable, which means a programmer owns the code they write. How they aim to publish it is up to them, and many licenses assist in this process.
- 1 Intellectual property law
- 2 Legality of emulation
- 3 Free and open-source software
- 4 Source-available software
- 5 CLA (Contributor License Agreement)
Intellectual property law
Intellectual property is a mouthful, but it refers to the ownership of things (thoughts, ideas, etc.) by nature of originality. Three big fields of intellectual property law include; copyright, patents, and trademarks, which all encompass different types of works.
- Creative works.
An author creates a work (sometimes called a work of art but that's misleading because it assumes everything that can be copyrighted is art), and then licenses this work to others for reproduction. Is designed to be granted as soon as the work is created, unlike the other two.
- System design and inventions.
An author designs a system (an invention), and then describes it in detail for others to implement. This is usually something you register at an agency (such as the United States Patent and Trademark Office if you live in the United States).
- Names and brands.
An author comes up with a name that identifies their products, and ensures that nobody else in the same industry can use it. This is usually something you register at an agency (such as the United States Patent and Trademark Office if you live in the United States).
The owner of intellectual property doesn't have to be a person; if an employee does any kind of IP-related work for a company, then the company may retain control of it depending on the terms they've set up with said employee through contracts. That contract may also contain clauses preventing the employee from speaking publicly about the work that goes on inside, since trade secrets are considered valuable. This is often called a non-disclosure agreement (NDA).
When copyright was originally implemented in law in the commonwealth, it was only supposed to protect a given work for fourteen years. After that term, the copyright would expire and the work would enter the public domain (to incentivize further creation of works). In the United States however, the copyright term has been extended numerous times to keep works under the control of the rights holders, which are usually not the original creators since the term is now so long (95 years) they would have died. Entertainment companies have a love-hate relationship with the public domain, willfully using works that are under it while preventing their own creative works from being "misused".
Legality of emulation
In the United States, the Ninth District Court ruled in favor of emulation several times. They originally established the legality of competing software products in Sega v. Accolade, which was about console-compatible cartridges having to make use of a trademark they were not licensed to use. In that case, they found Sega at fault for misusing their trademark to limit competition. The code to use it was considered functional in nature and could not be considered copyrighted if it granted Accolade's cartridges access and thus interoperability. Reproducing the functionality of a system is a matter of patent law, not copyright.
"If disassembly of copyrighted object code is per se an unfair use, the owner of the copyright gains a de facto monopoly over the functional aspects of his work--aspects that were expressly denied copyright protection by Congress. In order to enjoy a lawful monopoly over the idea or functional principle underlying a work, the creator of the work must satisfy the more stringent standards imposed by the patent laws. Sega does not hold a patent on the Genesis console."
A key distinction about competition as a matter of copyright law said:
"[An] attempt to monopolize the market by making it impossible for others to compete runs counter to the statutory purpose of promoting creative expression and cannot constitute a strong equitable basis for resisting the invocation of the fair use doctrine."
These two factors were similarly upheld in Sony v. Connectix, which was about the researching of the PlayStation's BIOS to create an emulator that didn't need one.
"[Because] the Virtual Game Station is transformative, and does not merely supplant the PlayStation console, the Virtual Game Station is a legitimate competitor in the market for platforms on which Sony and Sony-licensed games can be played. [...] Sony understandably seeks control over the market for devices that play games Sony produces or licenses. The copyright law, however, does not confer such a monopoly."
"If Sony wishes to obtain a lawful monopoly on the functional concepts in its software, it must satisfy the more stringent standards of the patent laws. This Sony has not done."
Shortly after this decision, the Sony v. Bleem case evaluated whether using video game screenshots to market the emulator was considered copyright infringement. Bleem's use was considered fair, as the screenshots were beneficial in helping users understand the emulator being compatible with the games themselves.
"Although Bleem is most certainly copying Sony's copyrighted material for the commercial purposes of increasing its own sales, such comparative advertising redounds greatly to the purchasing public's benefit with very little corresponding loss to the integrity of Sony's copyrighted material."
Additionally, the perceived market impact that using the screenshots would have on Sony was considered a non-issue.
"Bleem's use of a handful of screen shots in its advertising will have no noticeable effect on Sony's ability to do with its screen shots what it chooses. If sales of Sony consoles drop, it will be due to the Bleem emulator's technical superiority over the PlayStation console, not because Bleem used screen shots to illustrate that comparison."
The caveat was that, had it been possible to avoid it, Bleem should've done so.
"We are persuaded by the need for Bleem to impose minimally upon Sony's copyright with respect to these screen shots because there is no other way to create a truly accurate comparison for the user."
Free and open-source software
The fundamental concept of free and open source software is an inversion of the regular practice of software developers selling binary code to consumers and businesses. The source code that goes into developing commercial software isn't open to the public because releasing it would give others a competitive advantage and allow unauthorized ports. This is what is known as proprietary software, named such because it often has a proprietor (i.e. an owner). With free and open source software however, the source is open (hence the term open source) and available to others to use, study, modify, and share, to ensure that a user always has access to these tools. The Linux kernel is at the forefront of the movement, as it is the most active open-source project. (It's not the most widely-recognized, however; that would probably be Android and VLC Media Player.)
The benefit of software being open is that they're easier to port to other platforms by virtue of being open (though that says nothing about the effort required to get it working without bugs). Many of the best emulators use an open source license, though not all of them do.
The meaning of open-source is usually lost on those who aren't familiar with it, but institutes and organizations have defined what it means for clarity's sake. Essentially, a program is considered open-source (or if you're a GNU advocate, free software) when it grants the four freedoms, that it can be:
- run at any time.
- studied and modified for any purpose.
- distributed to anyone, and
- improved by anyone.
There's also copyleft, which is a play on copyright that inverts its goal of consolidating ownership to one entity and preventing others from having it, by ensuring that the ownership is largely in the public and no one can't have it. The copyleft strength of a license depends on how strict it is about keeping things open; weaker copyleft licenses require attribution but not much else, while stronger ones require the source to be available by any means necessary. The GPL is an example of a strong copyleft license; the BSD and MIT licenses are examples of a weak one, which makes it a frequent point of contention in the community which is better. Essentially, it's the difference between Creative Commons' Attribution and Attribution-ShareAlike license. One is the all familiar royalty-free license used by renowned composer Kevin MacLeod, the other is one of two licenses used by Wikipedia (they dual-license it under the GFDL too).
The GNU General Public License (GNU GPL or just GPL) is one of the most popular open-source licenses in the free software community, and for good reason; it has remained one of the strongest copyleft licenses, requiring users to share their contributions (some might say to an insane degree).
To use GPL code, the safest and easiest way to avoid a license violation is to keep the repository for it out in the open. The lack of any release demonstrates ill will among the many business users of open source software who usually have "playing fair with the community" on the lower end of their priorities. The benefit of having just the repo in the open is that software itself usually has a mechanism to display the software version, and even slight knowledge of repository traversal and compiler tools should allow users to reproduce their own version.
As it is the chief representative of the strong copyleft licenses, the GPL carries misconceptions about the expectations around its use.
- The license says nothing about having to make the process of compiling builds easy, only that it has to be possible.
- The license also says nothing against commercial distribution of any kind (as is explained later for non-commercial licenses). If you had to make the source code available, you could charge some arbitrary amount for it. Doing that would still be leaps above having nothing to show, which is usually what happens.
The GPL has two widespread versions; version 2 (written in 1991) and version 3 (written in 2007). The GPL3 was only written to reconcile issues that had come up with the GPL2 in the years after it was written, as the Free Software Foundation had a considerable amount of foresight, but not enough to imagine what would happen if a company used GPL software in a product where users could not flash their own firmware. This has become the central point of contention with Emulation Boxes, where hardware designers are constantly at odds with hobbyists who want to increase the functionality of their systems.
The GPL2 was an adequate license for software projects that compiled all of their code into a single binary. However, if the license is used for a code library that requires some intermediary application, said app becomes bound to the terms of the GPL. This is a consequence of its broad reach.
The FSF's original response was to create a "linking exception" in GNU Classpath's GPL2 license that allowed it to be used in proprietary software without having to share the whole program's source (the lack of said exception would've made it unfeasible to use in Java software). Later on, they created a much clearer variation of this exception as a separate license called the Lesser GPL (LGPL). This means code that bundles and uses an LGPL library only needs to keep the library itself open, not the code that interfaces with it.
The history of Unix is comprehensive but, to make a long story short, the Berkeley Software Distribution (BSD) was basically one of the many flavors of Unix that was very simple and permissive in how it was licensed. Ever since then, descendants like FreeBSD, OpenBSD, NetBSD, and DragonflyBSD have been licensed under a variation of it. The ISC and MIT licenses are based on its philosophy which makes them very compatible.
The original license had four conditions:
- Redistributions of the source code must retain the copyright notice.
- Redistributions of the binary code must be able to show the copyright notice.
- Advertisements surrounding the use of the code must have this line: "This product includes software developed by (organization)."
- Do not claim the original developers endorse the use of the software without permission.
The third clause (about advertising) ended up being controversial and was left out of newer licenses, resulting in the familiar three-clause BSD license. FreeBSD and NetBSD removed the fourth clause as basically no one violated that clause, and OpenBSD used a version of the license that details the first two clauses in one paragraph instead of listing them in asterisked bullets. The fact that the licenses are so permissive allowed Sony and Nintendo to use FreeBSD in the PS3, the PS4, and the Switch without having to share the source code.
The conditions in the BSD license are easy to modify, which makes it an attractive target for those wanting to include the prohibition of commercial use (see #Non-commercial software below). The old MAME license (and by extension FinalBurn Alpha and FinalBurn Neo) is based off of (or was heavily influenced by) this license, which ended up causing a ton of problems in recent times, notably when a libretro port of MAME tried to backport GPL code into old-licensed code, and when the Capcom Home Arcade emulation box was said to use FinalBurn Alpha ahead of its release (despite its creators not getting permission from all of FBA's developers).
The Apache 2.0 license differs from both the BSD and GPL licenses in that:
- It's not as permissive as the BSD because it still requires companies to state any changes they made.
- It's not as strict as the GPL because it doesn't grant trademark use.
This is a term typically used to refer to software which doesn't strictly count as FLOSS, even though the source code is readily available to the public. Two of the most common subcategories are:
Some ostensibly "free and open-source" software licenses include, or can be modified to include, an extra provision designed to prevent the software from being used for commercial purposes of a specific nature or of any kind, e.g. the sale of software and/or hardware to turn a profit. Since this is a fairly explicit example of restricting who can use a piece of software and for what purpose, it disqualifies the software in question from being considered FLOSS:
“"Free software" does not mean "noncommercial". On the contrary, a free program must be available for commercial use, commercial development, and commercial distribution. This policy is of fundamental importance—without this, free software could not achieve its aims. [...] We must conclude that a program licensed with such restrictions does not qualify as free software.”
“The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.”
–Open Source Initiative
Despite this, non-commercial licenses have long been seen as a desirable or even essential option by some emulator developers, either to specifically pre-empt others from bundling their code into a payware package (even though this would also be a flagrant violation of the GPL3) or using it in a pre-built emulation box without their explicit permission, or because they simply haven't considered the possibility of any more legitimate commercial use cases for their projects. Or sometimes they do it out of caution that the original hardware manufacturer could take them to court, despite the fact that the manufacturer's only grounds to stand on is whether the underlying technology behind a console is patented.
Whatever reason the dev gives for a non-commercial clause in the software license, it should be of no consequence to the average end user who's just running a free emulator on their PC for their own use. Some specific circumstances, such as a developer who's making a brand new commercial game for an old system and using an emulator to test it in lieu of real hardware, might be exceptions to this, but that's where it gets pretty murky from a legal standpoint.
However, developers of emulators must take extra precaution when working with code from a non-commercial emulator. As it is by definition not free software, the code is incompatible with the GPL, and the developer must take care not to mix GPL and non-commercial code. One example where this becomes relevant is with forks of old versions of MAME prior to its re-licensing to open-source. These forks can incorporate BSD code from the newest MAME versions, but are forbidden from including GPL MAME code. It has also been argued by some that RetroArch's ability to auto-download non-commercial cores is a license violation, as RetroArch is GPL-licensed and makes profit via Patreon.
Sometimes developers choose not to release the entire source code for their projects, and instead only allow public access to some of the source code while keeping other parts closed-source. Usually, the core functionality of the program is what becomes source-available while certain bells and whistles remain proprietary, hence the term "open core". This model is pretty rare for emulation software; one notable example in the broader software world is seen with the GitLab project, where the GitLab developers offer a paid Enterprise Edition with some additional business-focused features compared to the freely available core code in the Community Edition.
While there's some debate as to whether the stripped-down, fully source-available versions of these programs could count as FLOSS, the model as a whole is undoubtedly not fully in keeping with the ideals of the open-source movement, and it's often considered a compromise model that allows outside contributions and/or code reuse while still making it viable to sell the software for profit.
CLA (Contributor License Agreement)
Some projects use a Contributor License Agreement, which contributors have to sign before getting their work merged upstream. The sole intention of a CLA is to consolidate control of a project to one entity (which, as stated earlier, can be a person or a company). This can be useful if one wants to relicense the project retroactively when there are potential conflicts, but it's also a very easy way to prevent future versions of the code from being available (two projects in the Dreamcast scene encountered controversy with this approach).
CLAs allows emulators (and pretty much any work, even things that aren't source code) to be licensed under multiple licenses. Most often, the point of doing this is to allow a revenue stream that funds development of software and allows the primary developer to sell the software (or monetize it in some other way) without having to share the code (provided they pay a fee). At least, that's the most common use; one other is to allow the software developer to use the code in their own commercial projects.