Re: Take on concluded license; introducing effective license
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.
I was intentionally not bringing in the level. 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.
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,
From: J Lovejoy <opensource@...>
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
JL: it was always intended to be used for this scenario also
Perhaps the level of traceability is the issue - you want it to be very granular? Why?