Yes, and let's not forget this same point when we are talking about the process of adding new license to the standard list. The discussion is never whether the license can be included in an SPDX

These variant licenses would simply end up needing to be added as a “nonstandard” license, meaning the SPDX generator would not be able to use the standardized SPDX license list shortname for that

I think having some examples of text with the normalization rules applied is a good idea. However those examples should be in the spec. Having to go to the registry to see examples will make it

Hi Scott, The problem is that the today the various tools have nothing to check against to make sure that they are applying the rules correctly. The templatized version is intended as a tool

I agree. I wonder if a solution is to allow the specification of "variant" of a license. Perhaps a way to say: the closest license is this one, with a text similarity metric of X, and where the

I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English.

Ths comment is NOT about what the normalization should be or what equivalences should be permitted. Rather, I suggest a different approach to how we represent the result of the agreed upon

Thanks Daniel, Will look into adding this after we can get the guidance from the lawyers as to what varients are equivalent. ;) Kate

I think it is going in the right direction. You should look at the way Ninka normalizes test for in-file licenses (BSD, MIT, etc). For the BSD and MIT variants the problems are not only spelling,

Agenda Legal WorkStream 23-March-2011 (1) Re-Report SPDX Tools License Conclusion - Apache 2.0 (2) Revised Section 5.3 into Beta Spec. (3) SPDX Metadata StrawMan: (a) - Need for SPDX Metadata

You can disregard my last request – I found the correct template below: Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License");

I am updating the SPDX Tools source code to use the Apache 2.0 License. In addition to a NOTICE and LICENSE file, I plan on including the following text in all source files. Since we are not

minor point to whomever is current keeper of license list: identifier GFDL-1.2 appears twice in http://spdx.org/system/files/spdx_licenselist_v1.6.xls cell B70 should instead be GFDL-1.1 Bill

<tom.incorvia@...> wrote: I like the goal but i don't see how standardizing a license normalization algorithm designed to remove non-material variations advances this goal. I think

Hi Peter, Bumping this up a bit conceptually. I do agree that the timing and sophistication of tooling to support SPDX deserves additional discussion. The comments below speak a bit more to the

During the discussion this morning regarding license templatization a question came up regarding the exact purpose of templatization. This question was not answered satisfactory so hopefully the full

(Resend of 2/11/2011 email for today’s SPDX Legal call) At the recent SPDX general call, I offered to clarify Python licensing and to suggest standard names. This set of licenses is messy,

At the recent SPDX general call, I offered to clarify Python licensing and to suggest standard names. This set of licenses is messy, and a long discussion is below. There is not a single logical

While working on prototyping the spdx license registry i noticed that the full license texts in the spread sheet are not well formatted. Additionally, i some the license texts are incomplete (most of

"LicenseInfoInFile" removes the ambiguity, so going with that seems reasonable. Kate