- 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? :)
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.
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?
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
What is often the case? Do you mean the scenario that you mapped
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!)
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.
someone has questions or wants to understand the details,
I’m happy to stand in any time.
welcome your proposal to create/inspect further examples.
Perhaps this gives the option to revisit things from the one
or the other perspective.
you and regards,
we discussed this or something very similar during the
early licensing-profile discussions regarding a
“distributed license” concept and it was put to rest? :)
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.
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
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
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
- 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.
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
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.
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.
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.
that is all a bit blunt, but you asked! :)
direct comments to your list below
SPDX-Docfest I took the action item to raise a
question regarding the interpretation of concluded
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
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
- There is a license
decision (to not use the term conclusion here) to
specify how we pass on the item (downstream)
- That we need to
convey the upstream and downstream licenses
- 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
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
illustration separates this overloaded semantics
license, which then is also the
reference/commitment towards the binding terms and
conditions, the obligations and restrictions that
apply for my distribution/application.
to illustrate this:
- Detected one more
license than the authors declared
- Remove “or-later” on
effective license to determine explicit license
- Author declared
license correct and complete, but with option
decision towards more permissive license with less
obligations in the use case
Please let us know what you
Renettenweg 6/1, 69124 Heidelberg
Amtsgericht Mannheim, HRB 725313
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.