erikbgithub
commented
11 years ago Overview
The following pages give an overview about the topic and introduce the most important licenses and further resources.
"A Short Guide To Open-Source And Similar Licenses" - (link)
by Cameron Shapman, Smashing Magazine, 2010 found with Google
- Licenses don't give away original rights of the product (in most cases)
- they grant general permission of certain use cases to all users
- this way, you neither give up your ownership of your product nor have to manage permissions manually for each user
- in general source and binary distributions are to be differentiated when thinking about licensing (without giving reasons)
- GPL should be the most famous open source license
- allows copying the software
- allows redistributing the software in any possible way
- allows selling the software
- change the software in every way
- software that contains GPL licensed code must be GPL itself, which is not handy for a framework/library that should be used in a commercial setting
- more information about GPL compliance
- LGPL grants the additional right to use the LGPL licensed software to be part of another software, which is licensed differently or not at all.
- BSD License family
- less restrictive the GPL family
- Modified BSD License and FreeBSD License are the most important ones
- Modified BSD License allows any usage desired as long as the copyright and warranty text are included
- Modified BSD License also includes that the copyright holders and creators can't be used for "endorsement", which I guess means for advertisement, which is not included in the FreeBSD License
- MIT License basically allows anything as long as copyright and MIT License notice are delivered with it
- Apache License
- every right given can't be taken back, ever
- all rights are world wide
- rights are granted for free
- rights aren't exclusive, everybody can make use of it
- license must be maintained
- contributors must be credited
- Creative Commons
- not a software license, used in art
- author must be attributed
- work can be shared but must keep the same license
- the results of distribution and changes can't be used for commercial purpose, while commercial is not clearly defined
- the work can't be changed ando ther work is not allowed to be based on this work
Keywords
- license
- "[doesn't give] away any of your rights"
- "[grants] specific permissions for others to use that work"
- "helps to prevent others from claiming your work as their own"
- "[is an] alternative to just releasing your work into the public domain or granting permissions on a case-by-case basis"
- right - undefined
- copyright - undefined
- patent - undefined
- endorsement - undefined
- copy - undefined
- use - undefined
- modify - undefined
- (re-)distribute - undefined
- commercial - undefined
- derivative (work)
- "modify it in any way or create work based on the original"
Further links
- http://creativecommons.org/about/licenses
- http://www.opensource.org/licenses/alphabetical
- http://developer.kde.org/documentation/licensing/licenses_summary.html
- http://openacs.org/about/licensing/open-source-licensing
- http://blogs.zdnet.com/Burnette/?p=130
"HOWTO: Pick an open source license" (Part 1, Part 2)
by Ed Burnett, ZDNet, 2006 (found via [Shapman2010])
This article gives a guide about making the right decisions about what you want from a license and discusses more options then the first article does.
Questions to ask, when choosing a license:
- Do you want to relinquish any control over how your code is used and distributed?
- Do you want to allow people to use your code in non open-source programs?
- If somebody uses your code in their program and sells their program for money, do you want some of that money?
- If somebody uses and distributes your code and improves it (fixes bugs or adds features) do you want to make them give you the improvements back so you can use them too?
- (only mentioned in Part 2) Do you need patent licensing?
Licenses discussed (and which questions are answered "yes", ~ means "maybe"):
- Public Domain (not a license): 2,3
- BSD/MIT: 1,2,3
- ASLv2: 1,2,3,5 (of course used by Apache projects)
- GPL: 1,2,4 (used by GNU projects)
- LGPL: 1,2~,3~,4; This license usage is discouraged by the author himself
- MPL/CDDL: 1,2,3,4,5 (used by Mozilla projects)
- CPL/EPL: 1,2,3,4,5 (used by Eclipse Project, Microsoft Opensource projects and SourceForge)
If necessary it is possible to ask a user to fulfil additional requirements before a license is granted. This leads to multi licensing of the same software, i.e. FOSS usage gets GPL license while commercial usage must pay for an individual license.
Keywords
- code - undefined
- open source - undefined
- permission - undefined
- closed source - undefined
- proprietary software - undefined
- free software - undefined
- author - undefined
- use - undefined
- distribute - undefined
- modify - undefined
- contribute - undefined
- copyright - undefined
- dual license
- "means you give permission for people to use your code under two or more licenses"
- reciprocal license
- "[means any] modifications to your code need to be made available under the same licensing terms as your original code"
- patent - undefined
Further Links
- http://en.wikipedia.org/wiki/Public_domain
- http://www.eclipsezone.com/eclipse/forums/t20922.html
- http://linux.slashdot.org/comments.pl?sid=133782&cid=11169024
- http://www.gnu.org/licenses/why-not-lgpl.html
"Understanding Open-Source Licensing" (link)
Ben Adida, OpenACS, Year unknown (found in [Shapman2010])
This article doesn't discuss how to choose an open source license, but rather how and why those licenses exist. It explains what copyright is and what might be considered a derivative work, that every developer owns the copy right on his specific small part of a project, and that licensing is done for the whole project. That means earlier or later a lot of people need to be involved, if changes to the licensing of a project should be done. Therefore and because some licenses state it explicitely, a license shoulde be considered static, once a project decided for it.
It also talks about the GPL, which is often called *copyleft because it trys to use copyright laws to deactivate copyright itself.
Keywords
- open-source software - undefined
- copyright
- "[...] various governments grant authors a temporary monopoly on handling the distribution of their work. This is called copyright." (text formatting omitted)
- "[...] little control over how the content is used." (text formatting omitted)
- "whether or not [the authors] register this copyright, it's automatic"
- derivative work
- explained with a book (the original), which gets a new chapter by another author, which in turn is called derivative work
- it is noted that there doesn't seem to be a broadly accepted definition
- assumes that the GPLv2 implies "a derivative work is one that is linked, statically or dynamically, with the original work" (but without quoting the GPL)
- author - undefined
- redistribute - undefined
- use - undefined
- collaborative software development - undefined
Further Links
Debian Free Software Guidelines & FAQ (Social Contract with DFSG, FAQ)
- DFSG is one example to formulate one's requirements for open source licensing
- Debian cares a lot about free software, because it only wants to include free software in it's repositories
- free is meant as freedom of the user, not free of charge
- the three freedom tests:
- the desert island test: "Imagine a castaway on a desert island with a solar-powered computer. This would make it impossible to fulfill any requirement to make changes publicly available or to send patches to some particular place. This holds even if such requirements are only upon request, as the castaway might be able to receive messages but be unable to send them. To be free, software must be modifiable by this unfortunate castaway, who must also be able to legally share modifications with friends on the island."
- the dissident test: "Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. Any requirement for sending source modifications to anyone other than the recipient of the modified binary---in fact any forced distribution at all, beyond giving source to those who receive a copy of the binary---would put the dissident in danger. For Debian to consider software free it must not require any such "excess" distribution."
- the Tentacles of Evil test: "Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. The license cannot allow even the author to take away the required freedoms!"
Keywords
- free software
- "software freedom is a set of rights (free as in speech) rather than a price (free as in beer)"
- dual-license
- commercial vs **proprietary
Further Links
"What is free software?" (link)
Free Software Foundation, Year unknown
- describes what the Free Software Foundation (FSF) considers as free software and why
- the FSF believes a user has 4 fundamental rights about the software he acquired:
- "The freedom to run the program, for any purpose (freedom 0)"
- "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. "
- "The freedom to redistribute copies so you can help your neighbor (freedom 2). "
- "The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this. "
Keywords
- free software
- "means software that respects users' freedom and community. Roughly, the users have the freedom to run, copy, distribute, study, change and improve the software. With these freedoms, the users (both individually and collectively) control the program and what it does for them. "
"Make Your Open Source Software GPL-Compatible. Or Else." (link)
David A. Wheeler, 2002-2013 (found via [DFSG-FAQ])
- projects should only choose GPL compatible licenses
- reasons:
- GPL mostly used (many sources sighted, often more then 50% of projects checked)
- such a decision is not just about your code, but also about the code from other's you want to use
- GPL has strong legal base
- community pushes projects towards GPL compatibility or abandons them
- license proliferation considered harmful
- a lot of big projects like Python, Vim, Qt or Mozilla spend a lot of money to become GPL compatible
- in general the following licenses are considered GPL compatible:If you've read up on Unix history, you know that Unix was a freak product of AT&T's Bell Labs division, around 1969. I'll omit most of the long story, but the most important fact to know is that AT&T was then operating under a January 24, 1956 Department of Justice anti-trust judgement [7](which expired around 1980) prohibiting it from entering the computer/software business, and required it to reveal what patents it held and license them when asked. So, it could not legally sell Unix, but instead sold source-code licences (and occasionally also the right to use the trademarked name "Unix") to (1) universities, such as U.C. Berkeley, and (2) companies such as IBM, Apple, DEC, Data General, SGI, SCO, HP, etc.
- GPL
- LGPL
- MIT/X
- BSD-new
- options to be GPL compatible:
- choose the GPL
- use one of the other listed licenses
- dual licensing
- non-sourcecode data should be under Creative Commons CC-BY-SA, like Wikipedia and so on
Keywords
- free-libre open source software (FLOSS, FOSS, OSS/FS) - undefined
- GPL compatible - undefined
Further Links
- http://linuxmafia.com/faq/Licensing_and_Law/forking.html
- http://producingoss.com/en/index.html
- http://www.gnu.org/licenses/gpl-faq.html
- http://www.dwheeler.com/essays/floss-license-slide.html
- http://creativecommons.org/licenses/by-sa/3.0/
- http://home.ccil.org/~cowan/floss/ (License Finder)
- http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/
- http://tuxdeluxe.org/node/99
- http://www.econ-pol.unisi.it/dipartimento/it/node/753
- http://oreilly.com/catalog/opensources/book/perens.html
"Fear of Forking" (link)
Rick Moen, EMail, 1999
- everybody has the right to fork from an open source project. why would people not do that?
- Happened a lot to Unix because of Proprietary Source Code and marketing needs
- BSD derived from AT&T Unix and was up to about 1991 totally rewritten, thus able to license differently from the AT&T Unix
- gives more examples of forks that went more or less successful
- basic idea is: if the maintainer does nothing or stupid things then you can fork and make it better, IF it is a forkable license.
- the original is decided by users through usage
"Freedom Fighters" (link)
Jeremy Allison, tuxdeluxe.org, 2007
- software shouldn't be just open to use, it should be free from people's exploitation
- this freedom must be faught for
- people at FSF and projects using GPL are doing that
Copyright vs. Copyleft Licencing and Software Development (download)
Massimo D'Antoni, Maria Alessandra Rossi, Department of Economics and Statistics, University of Siena
- theoretical comparison of copyleft and non-copyleft licenses with GPL and BSD as examples
- follows that GPL contains measures to increase cooperation by itself that BSD doesn't have
- concludes that GPL might be advantageous were cooperation is not regulated by social norms, i.e. in big groups unknown people, because the GPL states that cooperation is required
- concludes that BSD might be advantageous when social norms regulate cooperation, because the smaller number of restrictions allows easier commitment to future investments by licensees
- reasons for open sourcing:
- "reputational and signaling benefits"
- "satisfaction of specific user needs"
- "intrinsic motivations, including the enjoyment of programming per se"
- "ideological commitment"
- "the very idea that source code should be open"
- "maximizing the value of the software", instead of maximizing it's sale value (own addition, others are from other papers)
- software development has two important characteristics: cumulativeness and investment specificity
- cumulativeness implies that open components result in more efficient cooperation
- investment specificity implies indirect profit from further usages of previously invested into software
- in connection investors want to be able to reap benefits from future improvements to their investment, being denied access to improved versions may decrease the return on their investment drastically
- (own opinion about this document) contains false assumptions about conveying derivative work, e.g. that derivative work and improvements by the original author must be publicly available which is both not correct. The original copyright holder can of course license his code differently later on and derivative works don't have to be conveyed if they are just used privately
- investment decisions in an OSS include the amount of investment as well as it's co-specifity in regard ot other developments
- "Proposition 1. Under the GPL, each developers will choose to be specific to all other develpers (N -specific), i.e. the highest possible degree of co-specificity. Under a BSD license, a lower degree of co-specificity will be chosen." (--> GPL advocates cooperation between different developers more)
- "Proposition 2. Taking into account incentives to invest, the BSD li- cense can be expected to induce a higher level of yi . However, the more important is the e ̧ect of co-speci ̨city on X or on ̋, the lower is the chance that yi will be higher under the BSD." (--> BSD advocates a higher investment by each developer)
Keywords
- copyleft license
- "the obligation to license future developments under the same terms"
- "[does not grant] developers the possibility to exclude other users and developers from access to an improved version of the software or from a software using the original one as a component"
- innovation
- source code
- "the human-readable instructions expressing the di ̧erent tasks that have to be performed by the computer"
- OSS - Open Source Software
- "a) the free availability of its source code"
- "b) the nature of the license under which it is distributed, which grants licensees a number of rights, namely the right to use (run) the program, to study how it works, to modify and improve it, to redistribute it with or without modifications" - interpretation of FSF Freedoms
- co-specifity
- (no quote) a quantifiable abstraction of how much a derivative work relies not just on the original but also on other derivative works of that original
"Why you should use a BSD style license for your Open Source Project" (link)
- permissive licenses are good for science, because results can be commercialised in every way
- permissively licensed products are more flexible in changing markets
- it also has the problem of other people make money from your work
"'The BSD License Problem" (link)
- problem: advertise every contributor, when advertising derivated work
- newer BSD licenses don't have that problem
- alternatives like MIT and Apache also don't have that problem
- advice to use Apache in case of preferring permissive licenses
Wikipedia
There are different articles on Wikipedia, which are handled in short in this chapter.
- Open source license
- Open Source Initiative
- Debian Free Software Guidelines (summary and history of some philisophical part of software licensing)
- License Proliferation
- License Compatibility
- TODO
Other links
- http://www.oss-watch.ac.uk/apps/licdiff/ (license chooser)
- http://www.tldrlegal.com/license (license comparator)
- http://www.dwheeler.com/oss_fs_why.html
- annotated list of licenses by FSF
Problem
MONK has no real open source license yet.
Solution
Find out, what the keywords in licensing are, which are the most important open source licenses and on which basis they can be compared. Detail the information about the resources used for the research as well as the differences between those licenses, so that based on this issue a decision can be made, which license is to be applied to MONK.
Notes
This issue contains only the texts linked here and a presentation in the Google Driver folders of DResearch Fahrzeugelektronik GmbH. A review of the presentation should be sufficient to close this Issue.