Dear Karsten,

Sorry; I can't read your email - it appears to be encrypted. The online
mailing list archives are also unable to show your email's content.

Now I'm even more curious to know what 'effective license' is :)

Best wishes,

Sebastian

Hi Karsten,

• I thought we discussed this or something very similar during the early licensing-profile discussions regarding a “distributed license” concept and it was put to rest? :)

The reason I bring the concept up (again) is that we stumbled over the interpretation of concluded licenses in the docfest (particularly on package level). I basically summarized the way I see it and how we have been doing things for years.

well, I suppose that is not surprising it came up again, as I think we talked about some documentation during the last conversation, but, um, that never got done. Probably a good time to revisit what is needed, and get something going!

• In any case, I think this is over-complicating things and sort of missing the original intent of the Declared License (package level) / License Info in File (file level and Concluded License (package and file) fields. 

I was intentionally not bringing in the level.

Yeah, I was trying to be general too, but in reality, which level you are talking about does make a difference. I tend to think that when at the file level, it's a bit easier in the sense that some license info is either in the specific file (a matter of detecting what it is) or there is no license info (NONE).
I think your example chart seems more like a package-level situation, do you agree?

Along these lines, any documentation or examples should probably be specific as to what level and use those fields. Otherwise, generalizing could just add more confusion?

I agree that this needs to be further discussed (if anticipating this approach in any form). My point is – and this is often the case; but I may be alone with that standpoint – that we should argue from a use-case-driven and semantically clean perspective. Concluded license in the current form simply irritates me with my background of license compliance and my daily routine with real-life software assets.

What is often the case? Do you mean the scenario that you mapped out?
Even if that's so, I am not seeing the benefit of capturing all this info for the recipients of your SPDX document.
What is the irritating bit about the current form of Concluded license??  Is there a point for additional text in the spec description and purpose, perhaps (which we may have already done, but I haven't looked at the draft licensing profile in awhile!)


Cheers,
Jilayne

 

For me it is valuable to have written up the proposal and to have shared it to the lists. My action item for the docfest is resolved. No further agenda; no bad feelings.

If someone has questions or wants to understand the details, I’m happy to stand in any time.

 

I welcome your proposal to create/inspect further examples. Perhaps this gives the option to revisit things from the one or the other perspective.

 

Thank you and regards,

Karsten

 

 

From: J Lovejoy <opensource@...>
Date: Friday, 17. September 2021 at 00:12
To: Karsten Klein <karsten.klein@...>
Cc: SPDX-legal <Spdx-legal@...>, <Spdx-tech@...>, Thomas Schulte <thomas.schulte@...>, Kate Stewart <kstewart@...>
Subject: Re: Take on concluded license; introducing effective license

 

HI Karsten,

 

I thought we discussed this or something very similar during the early licensing-profile discussions regarding a “distributed license” concept and it was put to rest? :)

 

In any case, I think this is over-complicating things and sort of missing the original intent of the Declared License (package level) / License Info in File (file level and Concluded License (package and file) fields. 

 

The original intent of the Declared License (package level) / License Info in File (file level) files is a place to capture what would be found in an automated way (e.g. a license scanner). Of course, sometimes that is not the complete picture and thus, there needed to be another field related to license - Concluded License. By way of example:

- at package level, LICENSE file is MIT, but at file level, you find other licenses. Thus Declared License = MIT, but Concluded License for package = MIT AND [other license found]. File level is then reflective of license for files.

- package has a choice of license picked up in README as Declared License.  You chose one license, which is the Concluded License. Your downstream recipient knows this b/c they can see the difference b/w Declared and Concluded AND you have made a comment as per the recommendation to do so in the spec.

- same as above, but there can be cases - which I have seen when I used to do audits - where you get a package with a license choice further downstream and that choice was already made ahead of you, and so you end up getting only one license. In which case, your Declared License would not reflect the choice and be the same as Concluded License. Of course, if that license was problematic, you might go further upstream to  identify and “get” the choice again. 

 

I can assure everyone here that all of this and all the various examples were discussed at length in the early days and when theses fields of the spec were being drafted. I think the problem we identified on this licensing-profile calls was that we ought to have some better documentation with examples :)

 

What you have diagramed below adds more fields along the lines of “declared”, “detected”, “concluded” and “effective” - that is a lot of complexity. Your “detected" is essentially SPDX Declared / License Info in File fields. I don’t see why one would need another field for “declared” as you’ve explained it here. Likewise, your “effective” essentially covers the Concluded field. 

 

More practically - if I am consuming an SPDX doc from you, what I really care most about is the Concluded License - that’s what I need to comply with, depending on my own use-case (i.e., am I redistributing the s/w you have given me). I might be interested in the Declared / License Info in File fields, probably just to see how good of a job I think you did (if I haven’t already determined that), but having more fields feels like clutter.

 

Also consider, SPDX has a core objective of being human and machine readable. As to the latter, people who make scanning tools have been involved since day one and that was also contemplated as to the reality of how audits are done. (I’ve been thinking a lot about SPDX history, so this may be a tangent, but also perhaps some people don’t really know the history and so it may be worth mentioning). This has not changed to today. 

 

Sorry if that is all a bit blunt, but you asked!  :)

 

A few direct comments to your list below

 

Thanks,

Jilayne

 

 

On Sep 16, 2021, at 12:30 PM, Karsten Klein <karsten.klein@...> wrote:

 

Hi all,

 

in today’s SPDX-Docfest I took the action item to raise a question regarding the interpretation of concluded license.

 

My point is the concluded license is semantically overloaded:

1. Used as the result of curation process
2. Used as the result of automatic process applying best efforts
3. Used to determine the license under which the item is further distributed (in particular when there is a licensing option)

JL: it was always intended to be used for this scenario also

3.  

 

While 1) and 2) appear ok to me I took the argument that we need to differentiate case 3) from the other two. I argued along

• There is a license conclusion under which we consume the license (from upstream)

Declared License

•  
• There is a license decision (to not use the term conclusion here) to specify how we pass on the item (downstream)

Concluded License

•  
• That we need to convey the upstream and downstream licenses

see above

•  
• That the license decision is policy-driven and use-case (or rather business-case) specific and determined in the context of my distribution or application and that this does not yet apply to the concluded license
• That this must be tracible by the recipient of my SPDX document (downstream)

Perhaps the level of traceability is the issue - you want it to be very granular? Why?

•  

 

I sketched a picture that shows where I would like SPDX to go introducing an effective license separated from concluded license:

 

<image001.png>

 

The illustration separates this overloaded semantics of concluded license by adding effective license, which then is also the reference/commitment towards the binding terms and conditions, the obligations and restrictions that apply for my distribution/application.

 

Some examples to illustrate this:

 

A:

• Detected one more license than the authors declared
• Remove “or-later” on effective license to determine explicit license conditions

<image002.png>

 

B:

• Author declared license correct and complete, but with option
• Policy-based decision towards more permissive license with less obligations in the use case

<image003.png>

 

Please let us know what you think.

 

Kind regards,

Karsten

 

 

metaeffekt GmbH

Firmensitz: Renettenweg 6/1, 69124 Heidelberg

Registergericht: Amtsgericht Mannheim, HRB 725313

Geschäftsführer: Karsten Klein

USt.-IdNr.: DE307084554

 

Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie diese E-Mail und alle Kopien umgehend. Eine unbefugte Weitergabe der E-Mail oder deren Inhalte und Anhänge ist nicht gestattet.

 

Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen Sie sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle Selbstbestimmung und übermittelt Informationen ausschließlich auf der Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). Weitere Informationen zu den Datenverarbeitungsvorgängen und insbesondere Ihrer Rechte entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH.