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 mybackground 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 <opensou...@jilayne.com>
*Date: *Friday, 17. September 2021 at 00:12
*To: *Karsten Klein <karsten.kl...@metaeffekt.com>
*Cc: *SPDX-legal <spdx-le...@lists.spdx.org>,
<Spdx-tech@lists.spdx.org>, Thomas Schulte
<thomas.schu...@metaeffekt.com>, Kate Stewart
<kstew...@linuxfoundation.org>
*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.kl...@metaeffekt.com
<mailto:karsten.kl...@metaeffekt.com>> 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
<http://www.metaeffekt.com/files/metaeffekt-data-privacy_v2018-05-29.pdf>.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4193): https://lists.spdx.org/g/Spdx-tech/message/4193
Mute This Topic: https://lists.spdx.org/mt/85658846/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
