-
>> Which is only true at that moment of time. If/when GPLv4 is available,
>> you would miss that one. So it's important to keep the fact that the
>> author stated that it's GPLv2+ to cover this.
>> So it's not simply OR. It's OR with potential licenses that do not
>> exist.
>
>Yeah, it does have the issue that the members of the set change over
>time.  However, at any particular moment in time (i.e. any time you are
>doing anything with an SPDX file) it can be treat as a simple
>disjunctive set (all the members are known).
>
>> Making it IMHO a beast in itself.
>
>I agree.  It seems to me that this "or later version" scenario is
>something that should be handled explicitly.  Shoehorning it into the
>license model feels clumsy.

(I am restarting participation after a longer pause.)

Was the question on license attachment clauses decided in the teleconf last week? Are different attachment clauses classified as licenses for the time being or will SPDX be added with separate taxonomy for explaining different license attachments?

Looking at the spec, it is currently unclear for me how one should report a file (or package) with a license attachment clause allowing choosing between GPLv2, any later GPL version, MPL 1.1 or any later MPL version. This needs to be treated somehow, and preferably captured so that this information needs not to be rechecked (unless for quality control).

Is there a "declared license" in a package, if there is just the text of the license in a separate file, with no license attachment statements? Based on the spec, I assume yes, but the text in the spec is a little vague. 

Also, the wiki on license texts currently holds placeholders for a number of "license+exception" licenses. What is the standing on this, should these be elaborated to contain the text of the exception so that misunderstandings are less likely? 

Br,
Martin

PS. Some other comments on the standard: 

1. Licenses detected information under section 3 of the standard seems to be something that repeats parts of information from section 5 of the standard. (With the exception that non-standard licenses are introduced with the help of section 3.)

2. I'm wondering how could the "license tree" of a package be better reflected in the standard. (It can be derived form sec 5. Perhaps that's enough.) E.g. We use a conclusion that a license.txt file containing e.g. LGPL 2.1 license text is concluded to apply to all files in that folder and subfolder, if the files do not contain any license attachment statements and there is no contradicting information. I believe others need to address the same question since files with no license information is a very frequent issue. Viewing licenses as a tree helps in this analysis. Recording licenses detected under section 3 with path information would actually mean even more repeating of information, thus not good. On the other hand, sec 5 is not well suited for information analysis, but for information storage. Hmmm... 

PPS. Generic update: what is the timetable for the standard? What type of changes are anticipated or considered prior to release of version 1.0? What goes to future versions?


Martin von Willebrand, Attorney-at-law, Partner
HH Partners, Attorneys-at-law Ltd
Mannerheimintie 14 A
P.O. Box 232, 00101 Helsinki, Finland
Tel: +358 9 177 613, Fax: +358 9 653 873
GSM: +358 40 770 1818 
martin.vonwillebrand@... 
www.twitter.com/mvonwillebrand
www.hhpartners.fi 
Validos ry, Chairman, www.validos.org

Have you checked our renewed web pages, at www.hhpartners.fi?

---

Privileged and confidential information may be contained in this message. If you are not addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, kindly notify us by reply e-mail and delete this message immediately. Thank you.<ATT00001..c>