What's legally sufficient to constitute a grant of an open source software license? #4
Comments
benbalter
changed the title
|
Another edge case to note, what if I just put |
|
If I'd see such example data then I'd likely send an email (or open a bug request) asking the author to clarify which type of GPL is mentioned (version 1, 2, 3, and/or above?) because each version of the GPL comes with different requirements. For e.g., GPL version 3.0 is explicit about the need for end-developers to provide documentation teaching others to compile the code, while version 1.0 (and ~2.0) was very flexible on this point. Also, strict GPL v2 doesn't mix with GPL v3 by design so it would really help in the long term to know exactly which version the license field was the author referring to. Could be useful if the SPDX license acronym list is used as common ground. For example, the more recent GPL license (version 3.0 with the "or above" clause) becomes "license": "GPL-3.0+". The list of licenses (some 300 by now) can be found at http://spdx.org/licenses/ |
From my perspective a tangible evidence that the code author assigns a given license to his code is sufficient. Unfortunately the patterns are not repetitive enough. Usually the person evaluating if a license is "granted" will provide a justification for each item.
When analyzing a new library. The precedence for me is looking at the headers of the source code to extract the mix of licenses and copyrights applicable from both original and third-party code included. The second step in precedence is looking at which license the author mentions on his website (or README) as applicable to his project as a whole (and how he understands the license to be enforced, this is often needed for GPL clarification). The last step is looking at the LICENSE file to verify that what it mentions is accurate with what was found in the previous steps. There are per-times cases of mismatch because the author might be updating this information manually and miss some details when changing his code to a different license. In summary, I tend to understand the LICENSE as what is shown to end-users when clicking on the "I accept" boxes but not really having much weight in terms of granting a license. |
|
@nunobrito I'd buy that for most licenses. If I say the license is Apache, you should ask which version. The GPL family of licenses though specifically say that you can say 'GPL' and it means the user can choose their version. @benbalter Your answer to not putting source headers on files is pretty weak :) Seems to be "It's silly (cf: unrelated example) & it's a lot of work". Rather than trying to argue that one, you could be pointing out that licensee's job is to identify the general licensing of the package as a whole, not every license that applies to each individual file (which will often vary across the software). |
|
Hi @hyandell, can you provide a link to:
Mostly for my own reference when documenting licenses in the future. Thanks. |
|
See the 2nd paragraph in section 14 of the GPL 3.0 (section 9 in GPL 2.0): "Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. " |
|
👍 Thanks Henri, this was right in front of my eyes and couldn't see it. Will start documenting it that way when applicable. |
Some packaging systems allow you to make these distinctions. For example, Python supports "or later" Trove classifiers [1] and npm allows SPDX license expression syntax v2.0 [2] (and SPDX expressions support '+', e.g. 'GPL-2.0+' [3]). The point of this paragraph is that such an entry is metadata which may not be sufficiently binding [4], while including the full license text is much more likely to be legally binding. By removing the FUD about "cannot distinguish between GPL-2.0 and GPL-2.0+", we can focus on the point that actually matters. [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers > License :: OSI Approved :: GNU General Public License v2 (GPLv2) > License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+) [2]: https://docs.npmjs.com/files/package.json#license > If your package is licensed under multiple common licenses, use > an SPDX license expression syntax version 2.0 string... [3]: https://spdx.org/sites/cpstandard/files/pages/files/spdx-2.0.pdf#page=82 > An SPDX License List Short Form Identifier with a unary "+" > operator suffix to represent the current version of the license > or any later version. For example: GPL-2.0+ [4]: licensee#4 What's legally sufficient to constitute a grant of an open source software license?
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
From the readme:
The question
There's a continuum, with the full text of the license being checked into version control on one end, and a non-linked license abbreviation (e.g., "license: MIT") on the other. Which is sufficient to grant a license? Is there any precedence?
LICENSEfile with the license name or abbreviationREADMEwhich references the license name or abbreviationREADMEwhich links to the full license textThe text was updated successfully, but these errors were encountered: