Re: Take on concluded license; introducing effective license
|
J Lovejoy
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 JL: it was always intended to be used for this scenario also Declared License Concluded License see above Perhaps the level of traceability is the issue - you want it to be very granular? Why?
|
|
|