I suggest that everyone use the term “deprecated license identifier”; don’t use “deprecated license” or “deprecated.”
The obvious interpretation for the term “deprecated license” is that the license itself is forbidden going forward, and that’s not the intent here. --- David A. Wheeler From: [email protected] [mailto:[email protected]] On Behalf Of Manbeck, Jack Sent: Friday, January 15, 2016 9:47 AM To: Henri Yandell; Gary O'Neall Cc: [email protected] Subject: RE: Machine representation of deprecated licenses Hen, It’s possible we need to better define it somewhere. The idea behind deprecation was simple. It meant that identifier should not be used going forward, if possible, but it still exists, is valid and points to a license page. The idea was that license identifiers will remain immutable and exist basically forever. That said, sometimes change is necessary thus the term deprecation. It doesn’t mean you can’t use that license it just means there is a newer identifier for it. I do think some best practices or explanation around it would be useful. Here is what the license list currently says which is okay as an explanation of why we did these particular ones but not how these things could/should be handled . Jack Deprecated Licenses Release 2.0 of the SPDX Specification introduces License Expression Syntax<http://spdx.org/SPDX-specifications/spdx-version-2.0> that supports the ability to identify common variations of SPDX-identified licenses without the need to define each potential variation as a distinct license on the SPDX License List. This new syntax supports the ability to use a simple “+” operator after a license short identifier to indicate “or later version” (e.g. GPL-2.0+). It also supports the ability to declare an SPDX-identified license exception<http://spdx.org/licenses/exceptions-index.html> using the “WITH” operator (e.g. GPL-2.0+ WITH Autoconf-exception-2.0). SPDX has defined a list of license exceptions to use after the “WITH” operator. As a result, a number of licenses formerly included in the SPDX License List have been deprecated as licenses, and correct usage employs the License Expression Syntax as of v2.0. The URL to each deprecated license still exists and those license pages have been updated to note the deprecation. Other licenses may have been deprecated for reasons noted. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Henri Yandell Sent: Thursday, January 14, 2016 10:07 PM To: Gary O'Neall Cc: [email protected]<mailto:[email protected]> Subject: Re: Machine representation of deprecated licenses Few ponderings: * Is there any leeway for confusion as to what deprecated means with a license? I take it to mean 'we, license authors, don't believe it should be used for new works'. * Is there a more general notion of guidance here? <guidance>deprecated</guidance> or <guidance>draft</guidance> etc - not sure if there are other possibilities. * Sometimes a best practice when deprecating is to point to what folk should use. deprecated: Apache 1.1, use-instead: Apache 2.0; might be worth supporting if the data supports it. The first set of deprecated licenses I can think of all have successors, but I imagine there will be ones which don't have a specific successor. Hen On Thu, Jan 14, 2016 at 12:14 PM, Gary O'Neall <[email protected]<mailto:[email protected]>> wrote: Greetings all - I would like to add a mechanism for representing listed licenses that have been marked as deprecated in the JSON and RDFa formats for licenses on the spdx.org/licenses<http://spdx.org/licenses> website. My proposal is to add a property "spdx:deprecated" in the RDFa and just "deprecated" in the JSON with a boolean value of true or false. It would be treated as optional with a default value of false. This should be backwards compatible since it is an addition of an optional field. Two questions - any objections to this proposal? - where should we document this? We could add it in the Other License Information section (currently number 5), although, I think it would only logically apply to the listed license. We do not have a separate section for Other Licensing information". Let me know what you think and if you would like to add it to one of the future tech calls to discuss. Thanks, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586<tel:408.805.0586> Email: [email protected]<mailto:[email protected]> _______________________________________________ Spdx-tech mailing list [email protected]<mailto:[email protected]> https://lists.spdx.org/mailman/listinfo/spdx-tech
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
