Re: [spdx-tech] "Or later" operator is not well defined

[David A. Wheeler]

Philippe Ombredanne :
> This "+" aka. "or later" operator is indeed in need for a fix. The fix we 
> need is retirement, not expansion. It has served its purpose and is no longer 
> needed IMHO.

I think that's a bad decision.  That means that the next time someone fixes a 
license version number, then SPDX will have to add yet another arbitrary fixed 
license id.


> It has now been replaced mostly by concrete licenses with their own ids.

No, a few cases have been sort-of handled by special casing license ids.


> If there is anything we could fix that would be to check if there are **any** 
> license that would need such a variation. I do not known of any that is in 
> any kind of usage, even rare usage. MPLs, CPLs and EPLs do not have such 
> variation (they always allow any other version AFAIK). All the FSF licenses 
> have been taken care of. So I do not think there is anything left.

It's hard to predict the future.  Even in the present, I don't know of anyone 
who's seriously studied this issue to make such a confident claim.

"The always allow any other version" is merely a statement about the text of 
the license itself.  That does not guarantee that the USERS of such licenses 
actually permit this.


> This + seems to be now only a source of bloat and rightful confusion.

It's not confusing, and the "+" long predates the SPDX specification.  It's not 
*specified* in the current spec, but that's not the same thing.

What's more, the SPDX specification still doesn't deal with the OTHER problem 
I've mentioned before: "I don't know if 'or later' applies".  Trying to use 
fixed license names, when you DO NOT and CANNOT have this information, is 
misleading.  We still need 3 cases:
1. Only this version
2. This version or later
3. This version at least, and maybe other versions (but we don't know).

Having fixed names for licenses means that you cannot clearly express much of 
that.  The result is a muddle.

--- David A. Wheeler


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3741): https://lists.spdx.org/g/Spdx-tech/message/3741
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

Hi David:

On Mon, Jul 1, 2019 at 9:00 PM Wheeler, David A  wrote:
> Philippe Ombredanne  wrote:
>> What looks as a version number in an SPDX license identifier is NOT
>> like a software version number. This is purely indicative and is not
>> something that is specified to have any meaning. Actually nothing in
>> an identifier has any specified meaning at all.
>
> I know, that's the defect we're trying to fix.  There's an "or later"
> operator in the SPDX license expressions that has no defined meaning.
> It *implies* a use of the version number field in the SPDX license id,
> but fails to actually state this, so it needs to be stated.

This "+" aka. "or later" operator is indeed in need for a fix. The fix
we need is retirement, not expansion. It has served its purpose and is
no longer needed IMHO.

It has now been replaced mostly by concrete licenses with their own ids.
If there is anything we could fix that would be to check if there are
**any** license that would need such a variation. I do not known of any
that is in any kind of usage, even rare usage. MPLs, CPLs and EPLs do
not have such variation (they always allow any other version AFAIK). All
the FSF licenses have been taken care of. So I do not think there is
anything left.

This + seems to be now only a source of bloat and rightful confusion.

>> It just happens that as a convenience, folks like to put version
>> numbers in licenses and these have been carried on in the license
>> identifiers.  You could have a license id of 234dssds-23.3475 and
>> that would be OK. So  please do not start to try to infer versions,
>> relations and other things based on identifier strings, that's a
>> dangerous slope.
>> Instead, you may want and could track relations between licenses, as
>> attributes of a license. For instance you could track that EPL-1.0
>> next version is EPL-2.0 and so on. But this becomes an explicitly
>> stored relationship and not something vaguely inferred from opaque
>> ids.
>
> Requiring humans to ignore the version numbers embedded in license ids
> is the MUCH MORE dangerous slope.
>
> By that theory it would be okay to have LICENSE-1.0, followed by
> LICENSE-3.0, followed by LICENSE-2.0.  Then "LICENSE-3.0+" would
> include "LICENSE-2.0".  That would be horrifically awful for
> usability, and basically guarantee mistakes.

I am not saying you should ignore anything from an id string... I am
just saying that no id part has any special meaning. Actually there are
no parts in an id at all and there is no version part. The meaning is in
the text referenced by the id and not in the id.

Furthermore, the legal team assigns ids sensibly and they would never
come with something that does not make sense. So your theoretical case
would not happen in practice.

Instead, the proper way to track relationships between versions (and more
generally between licenses) would be to do that with attributes, not
with ids.

--
Cordially
Philippe Ombredanne

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3740): https://lists.spdx.org/g/Spdx-tech/message/3740
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

Dear Vladimir:

On Mon, Jul 1, 2019 at 7:58 PM Vladimir Sitnikov
 wrote:
>
> Philippe>And in the same way,  the -only and -or-later suffixes applied to 
> some
> Philippe>ids have no meaning whatsoever of their own
>
> Even though currently "-or-later" is an opaque string, it looks like it might 
> make sense to add "only this version" modifier to "spdx expressions".
> What do you think?
>
> How could it look like?
> EPL-1.0 ONLY
> EPL-1.0-only
>
> The second option is not that bad in my opinion.

I do not see the purpose of changing the expression syntax for
something which is at best rare and arcane beyond a few of the common
FSF licenses and this has been addressed alright.
As for your second option "EPL-1.0-only" that's a new license id
alright which is fine for the rare cases when and if you would want to
track these kind of options in a more sophisticated way than with a
"+". It does not require any changes to the spec as again, identifiers
have no meaning at all. They are just made so that they are easy to
read and remember for us poor humans... But we could just as well have
assigned 2342342sSDSFE423 as an id to the MIT license: that would be
silly but that's just to highlight my point. That's actually a good
thing that they have no meaning because that way they do not have to
be parsed: they were never designed for that, hence you cannot easily
infer a syntax to break them in parts: they have no parts, no part
separator, no prefix, no suffix and no version (even though it may
look like it).

--
Cordially
Philippe Ombredanne

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3739): https://lists.spdx.org/g/Spdx-tech/message/3739
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[David A. Wheeler]

Philippe Ombredanne  
> What looks as a version number in an SPDX license identifier is NOT like a 
> software version number. This is purely indicative and is 
not something that is specified to have any meaning. Actually nothing in an 
identifier has any specified meaning at all.

I know, that's the defect we're trying to fix.  There's an "or later" operator 
in the SPDX license expressions that has no defined meaning.  It *implies* a 
use of the version number field in the SPDX license id, but fails to actually 
state this, so it needs to be stated.

> It just happens that as a convenience, folks like to put version numbers in 
> licenses and these have been carried on in the license identifiers.   You 
> could have a license id of 234dssds-23.3475 and that would be OK. So please 
> do not start to try to infer versions, relations and other things based on 
> identifier strings, that's a dangerous slope.
> Instead, you may want and could track relations between licenses, as 
> attributes of a license. For instance you could track that EPL-1.0 next 
> version is EPL-2.0 and so on. But this becomes an explicitly stored 
> relationship and not something vaguely inferred from opaque ids.

Requiring humans to ignore the version numbers embedded in license ids is the 
MUCH MORE dangerous slope.

By that theory it would be okay to have LICENSE-1.0, followed by LICENSE-3.0, 
followed by LICENSE-2.0.  Then "LICENSE-3.0+" would include "LICENSE-2.0".  
That would be horrifically awful for usability, and basically guarantee 
mistakes.

Vladimir:
> Could you please provide an example for CC-BY-SA-2.0? (or later version of 
> that license)

I can't, because CC-BY-SA is usually not used for software, and I've been 
focused on software licenses.  Maybe someone who focuses more on media can do 
that.  But no matter what, clearly requiring specific versions of licenses for 
*software* is a thing. The spec should include, as much as reasonable, a few 
operators that "just work in all cases".  It's fair to include special cases 
for important circumstances or backwards compatibility, but simple 
generalization is generally best.

--- David A. Wheeler

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3738): https://lists.spdx.org/g/Spdx-tech/message/3738
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[Vladimir Sitnikov]

Vladimir> I'm sure one should not specify "Bundle-License: CC-BY-SA-2.0"
and overrule it for "just 2.0" at the same time.
David>That is *EXACTLY* what the Linux kernel and Busybox do - they take
the GPL 2.0 license and say

David, I'm afraid your example does not work here.
I asked an example for CC-BY-SA-2.0 license, and you provide example with
GPL. That is a completely different story. Really.
Could you please provide an example for CC-BY-SA-2.0? (or later version of
that license)

Some context:
There's a page https://wiki.spdx.org/view/Legal_Team/later-version-clauses
It has "allows only"=="n" for CC-BY-SA. Which means one cannot use
CC-BY-SA-2.0 and overrule it for "just 2.0" at the same time.

Your move.

Vladimir

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3737): https://lists.spdx.org/g/Spdx-tech/message/3737
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[Vladimir Sitnikov]

Philippe>So please
Philippe>do not start to try to infer versions, relations and other things
Philippe>based on identifier strings

+1

Philippe>For instance you could track that ...
Philippe>next version is ... and so on. But this becomes an explicitly
Philippe>stored relationship and not something vaguely inferred from opaque
Philippe>ids.

+1

I guess we might want include at least some relationships into the standard.

Philippe>And in the same way,  the -only and -or-later suffixes applied to
some
Philippe>ids have no meaning whatsoever of their own

Even though currently "-or-later" is an opaque string, it looks like it
might make sense to add "only this version" modifier to "spdx expressions".
What do you think?

How could it look like?
EPL-1.0 ONLY
EPL-1.0-only

The second option is not that bad in my opinion.

Vladimir

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3736): https://lists.spdx.org/g/Spdx-tech/message/3736
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[Philippe Ombredanne]

David, Vladimir:

On Mon, Jul 1, 2019 at 6:34 PM David A. Wheeler  wrote:
> > From: Vladimir Sitnikov 
> > It looks like you are inclined that "SDPX should have some definition of 
> > or-later". That is good to know.
> I think standards should be as clear and precise as possible, so sure.
> David>Maybe we should claim that a version number is the first match
>
> > How about Spencer-86, Spencer-94, Spencer-99?
> > How about Unicode-DFS-2015, Unicode-DFS-2016?
> > W3C-19980720, W3C-20150513, W3C?
>
> None of those match the proposed pattern, so by my proposal none of them have 
> a version number.  I'm fine with that.  The Spencer-86 can be reworked that 
> as Spencer-86.0.  If someone wants something different propose that instead.
>
> > David>Maybe we should claim that a version number is the first match after 
> > a "-" to some pattern like this regex:
> > How that classifies 1.3a vs 1.3c? Is "c" a part of the license name?
>
> Yes, as defined by the proposed regex, and I did that on purpose.
> This is all just a discussion right now, of course.  Perhaps people think a 
> different pattern would be better.  But "1.3c" is a plausible version number.


What looks as a version number in an SPDX license identifier is NOT
like a software version number. This is purely indicative and is not
something that is specified to have any meaning. Actually nothing in
an identifier has any specified meaning at all. It just happens that
as a convenience, folks like to put version numbers in licenses and
these have been carried on in the license identifiers.   You could
have a license id of 234dssds-23.3475 and that would be OK. So please
do not start to try to infer versions, relations and other things
based on identifier strings, that's a dangerous slope These are opaque
strings used as "natural keys" nothing more than that.

Instead, you may want and could track relations between licenses, as
attributes of a license. For instance you could track that EPL-1.0
next version is EPL-2.0 and so on. But this becomes an explicitly
stored relationship and not something vaguely inferred from opaque
ids.

And in the same way,  the -only and -or-later suffixes applied to some
ids have no meaning whatsoever of their own. They just happen to be
handy IDs for licenses. They do not need to be specified either: again
identifier are opaque ids.

-- 
Cordially
Philippe Ombredanne

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3735): https://lists.spdx.org/g/Spdx-tech/message/3735
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] "Or later" operator is not well defined

[David A. Wheeler]

> From: Vladimir Sitnikov  

> It looks like you are inclined that "SDPX should have some definition of 
> or-later". That is good to know.

I think standards should be as clear and precise as possible, so sure.

David>Maybe we should claim that a version number is the first match

> How about Spencer-86, Spencer-94, Spencer-99?
> How about Unicode-DFS-2015, Unicode-DFS-2016?
> W3C-19980720, W3C-20150513, W3C?

None of those match the proposed pattern, so by my proposal none of them have a 
version number.  I'm fine with that.  The Spencer-86 can be reworked that as 
Spencer-86.0.  If someone wants something different propose that instead.

> David>Maybe we should claim that a version number is the first match after a 
> "-" to some pattern like this regex:
> How that classifies 1.3a vs 1.3c? Is "c" a part of the license name?

Yes, as defined by the proposed regex, and I did that on purpose.

This is all just a discussion right now, of course.  Perhaps people think a 
different pattern would be better.  But "1.3c" is a plausible version number.

David> regardless of what the license text says

> I'm sure one should not specify "Bundle-License: CC-BY-SA-2.0" and overrule 
> it for "just 2.0" at the same time.

That is *EXACTLY* what the Linux kernel and Busybox do - they take the GPL 2.0 
license and say, "exactly and only this license".   Overruling a license text 
to fix the version number is not at all unusual.  Some lawyers require it, 
because they can't see all possible future versions, and thus will only approve 
releases under licenses they can review.


> Either the author uses "the canonical SPDX variation of CC-BB-SA-2.0" or the 
> license is different (== its SPDX expression must be different from 
> CC-BB-SA-2.0). 

No, because it is *NOT* a different license.  Let's look at the world as it 
*is*.   All a tool can typically analyze with any confidence is that the 
license text in the LICENSE file matches some license text (e.g., the 
CC-BY-SA-2.0 license). But that is true in either the "or later" or "not or 
later" case.  To do better, a tool would have to reliably read natural language 
prose & provide good justification for that decision.

This is a tension that I've documented a number of times before:
1. Some people want to record using SPDX what the license of the software 
actually *is*, as that is important for determining rights.  It's completely 
reasonable to want this.
2. In reality we must often use automated tools, which CANNOT do this in 
general.  Tools can generally only report "a license text I've found" or "A 
SPDX license expression I've found", and that is not the same thing as the 
actual licensing.  Yes, they can (and are) programmed to detect specific cases, 
but it's not reliable enough to guarantee anything.  I think it's reasonable to 
depend on an expressly stated SPDX license expression, but not all software has 
one (yet :-) ).

We need a better way for SPDX to report "I found this license, I don't know if 
'or later' applies".  Just because the *default* of the license is that "or 
later" applies doesn't mean that it actually applies in the case of a 
particular piece of software, and there's no way to indicate this.

It's already hard enough to determine if a license actually matches at all.  
The most widely-used license analysis tool (in terms of users) is licensee, 
because that's how GitHub determines what license is used for its display.  
That uses a probabilistic analysis of the LICENSE file (or similar) and that is 
*all* it does - it does NOT attempt to examine the README and so on.  SPDX 
maintains a more complex pattern system for matching licenses, but again it 
CANNOT tell if the README adds "only this version".


> It might be SPDX standard should allow "-only" optional modifier for all 
> license ids (e.g. CC-BY-SA-2.0-only), however that is a bit different story.

There are three cases for any given license:
1. This license, this version only
2. This license, this version or any later version
3. This license, and I *DO NOT KNOW* if "or later" applies.
SPDX is incapable of reporting case 3, and that's a problem because that is the 
*ONLY* kind of information available from tools in many cases.  So if you want 
to strongly define "or later", you also should tackle of reliably reporting "or 
later status unknown".

--- David A. Wheeler


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3734): https://lists.spdx.org/g/Spdx-tech/message/3734
Mute This Topic: https://lists.spdx.org/mt/32049933/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[spdx-tech] Project: Registry and repository of License List Namespaces

[Smith Tanjong Agbor]

Hello all,

*I beg your indulgence in reading this email. It is long, but the purpose
is worth it*

I am Tanjong Agbor Smith; contributor of SPDX for the project: Registry and
repository of License List Namespaces.

Given that the legal team will be the main people to use the application I
am building, my mentors thought it wise to involve you more into this.

So, I will start by describing the project, then the approach I am using to
develop this, the work done so far, and I will conclude by indicating the
future work to be done.

*1. Project description*: Can be found in details on this link.


SPDX provides a license list for commonly used open source license - the
SPDX License List. SPDX also supports defining licenses within the SPDX
document using a LicenseRef syntax defined in section 6 of the SPDX
specification. In the next release of SPDX, we plan to introduce a
mechanism for other organizations or individuals to maintain lists of
licenses outside of the SPDX license list, but allow those licenses to be
valid without requiring the text to be in the SPDX document itself. This
enhancement has been documented in the SPDX specification issues list. This
project automates the registration and management of the namespaces.

*2. Approach:*
Given that the spdx legal team are already at ease in using SPDX Online
tools to submit license requests, we thought it wise to include the
functionalities of this project in SPDX online tools too.
This shall provide a single application to perform the tasks of submitting
license requests, submitting license namespace requests, etc.

*3. Work done so far:*
So far, (though you all might not see these in your instance of spdx online
tools), I have added the necessary models for namespace submission, and
pull requests of license namespaces are done automatically on this
repository: repo .
You can see examples of license namespace issues submitted with our
tool on this
link .
Below is an image of the form that has to be filled on spdx online tools to
be able to create the necessary requests(issue) on the repository:

[image: license namespace request form.png]
*NB: you can share your views on this form and request changes. ☺*

*4. Features to implement:*
- namespace validation
- single place to store organisations names(possibly a json file?)
- URL validation (as mentioned by one of my Mentors; Tushar)
- pop-up display after successful submission of a namespace
- prefill submitter's email(if logged in)
- A committer to the namespace repository accepts the pull request
- When accepted, the namespace is published to a known website
- REST based API's are available to query the namespace repository
- See if the license text for a license matches license text for other
licenses within other repositories
- Maintain a list of license aliases, preferably as a file in a github
repositories.The aliases would include all license ID's for licenses with
the same text.
- Provide a service that allows for text to be compared against all
existing licenses.
- Promote a license to the license list - this would call the REST API's
for the online tool to add a license to the SPDX license list.a.If the
verification of whether the license is already present prior to adding it, I
shall write an API that will perform this check to avoid duplicates.
- Remove a license repository. This would also update the license aliases.a.I
will write a django REST API that will expose a function which will remove
a license reference and update the aliases.
- Provide metrics on use for licenses to help the SPDX legal team
propose licenses
which should be on the SPDX license list

Thank you for your patience.

Please feel free to provide suggestions to this email, as your ideas could
be valuable.

Best regards,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3733): https://lists.spdx.org/g/Spdx-tech/message/3733
Mute This Topic: https://lists.spdx.org/mt/32271307/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-