Re: VS: GPL vX or later issue

Philip Odence

Martin, regarding your PPS
We are aiming for an end of the year version with more or less frozen features. It won't be released until it's been through some more extensive testing, but we don't expect adding a lot of features after that point.
There is a wiki page on that houses beyond 1.0 ideas:


L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502

On Nov 15, 2010, at 6:39 AM, Martin von Willebrand wrote:

>> 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? 


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 
Validos ry, Chairman,
Have you checked our renewed web pages, at
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.

Join { to automatically receive all group messages.