license name synonyms
|
J Lovejoy
I’m not sure I understand why we need this. For the licenses that have been deprecated but can be otherwise represented using the new License Expression Syntax, I can see this being helpful, but I’m not sure what the use case is going forward.
toggle quoted message
Show quoted text
As it stands right now, we have a note re: deprecation for each license. There are essentially three variations as to why a license was deprecated, examples: - (or later example) http://spdx.org/licenses/preview/GPL-2.0+ - (exceptions example) http://spdx.org/licenses/preview/GPL-2.0-with-autoconf-exception - (duplicate license mess-up example, which we should hopefully not need ever again!)) http://spdx.org/licenses/preview/StandardML-NJ I’m happy to add further text provide an example for these deprecated licenses as to how to use the new License Expression Syntax to create the same license but keep in mind, it really can only be a suggestion as there is not necessarily a one-to-one relationship between the old and new (hence the addition of the License Expression Syntax!!) For example: On the current SPDX License List, v1.20 and previous versions - you could indicate the following license: - GPL-2.0-with-bison-exception ( http://spdx.org/licenses/preview/GPL-2.0-with-bison-exception ) but this representation means GPL2.0 (only) with Bison Exception. We have/had no way, to indicate: - GPLv2 (or later) with Bison Exception - GPLv1.0 (only) with Bison Exception - GPLv1.0 (or later) with Bison Exception - GPLv3.0 (only) with Bison Exception - GPLv3.0 (or later) with Bison Exception As of version 2.0, you can represent all of these by using any of the version of GPL from the SPDX License List (for “only”), add the + operator (for “or later”) and add the WITH Bison-exception-2.2 (see http://spdx.org/licenses/preview/exceptions-index.html - side note: we realized for this license it downloads the text instead of displaying the HTML page, working on fixing that…) Thus, as to my above comment about adding comments as to the equivalent license - is the idea to add all of these options? AT this point, I feel like we might be then starting to explain how to use the License Expression Syntax, which will be included in the spec with that section (and probably some other collateral). In which case, we want to think carefully about how much extra information we include in the SPDX License List itself - if such information begins to be more along the lines of best practices or instruction, this may not be the appropriate place to provide such info and then we also may end up with a situation where we have similar info in multiple places, which is always harder to maintain. Jilayne SPDX Legal Team co-lead opensource@... On Jan 8, 2015, at 12:28 PM, Gary O'Neall <gary@...> wrote: |
|
|