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 <[email protected]> > 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: > Used as the result of curation process > Used as the result of automatic process applying best efforts > 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 > > 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 > <http://www.metaeffekt.com/files/metaeffekt-data-privacy_v2018-05-29.pdf>. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4191): https://lists.spdx.org/g/Spdx-tech/message/4191 Mute This Topic: https://lists.spdx.org/mt/85658846/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
