Date   

Missing today's call

VM (Vicky) Brasseur
 

And thereby missing all of you lovely people.

 

We’ve a big deadline this week so I need to use that hour for other things, unfortunately.

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'


Re: Caldera license question

Philippe Ombredanne
 

Dear Warner, Armijn and Jillayne:

On Tue, Oct 26, 2021 at 1:20 AM Warner Losh <imp@...> wrote:

Did they harvest these files from the 7th Edition of Unix, or did Sun license these and Caldera made them put this license on things? The version 7 /bin/sh was included in the grant of the original license, and the System V version was excluded which is what the OpenSolaris one is based on if it came from Sun's repo... But I've not done the software archaeology to know from whence this project started their sources...
So with a bit of digging in CVS (yeah!) ... on only one file
(gmatch.c), it looks like the original commit had this caldera license
header alright and that must have been added when porting from the 7th
edition, per the "Derived from /usr/src/cmd/sh/expand.c, Unix 7th
Edition:" comment in that file.
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/expand.c
did not have such notice.

So I would surmise that Gunnar Ritter (Heirloom's original creator)
took the original 7th edition code from TUHS and used the
TUHS-provided Caldera notice (such as at
https://www.in-ulm.de/~mascheck/bourne/Caldera-license.txt ) to add as
a comment in the code. The timeline of various events supports this
analysis.

Sven Mascheck <mascheck@...> has an extensive Shell history at
https://www.in-ulm.de/~mascheck/bourne/#heirloom including a Heirloom
shell commit log that matches the CVS's log at
https://sourceforge.net/projects/heirloom/

With all that said, the license text that we discuss here and as seen
in gmatch.c is IMHO closest to a plain BSD-4-Clause with minor
variations (e.g. scope of source and documentation vs. only source in
BSD-4-Clause) so if the intro blurb seen in the SPDX Caldera text is
not material, then may be the body text itself could be just a minor
variant of the BSD-4-Clause.

Someone could bug Gunnar Ritter at <gunnarr@...> of course to get
confirmation.

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


Re: Caldera license question

Warner Losh
 



On Mon, Oct 25, 2021 at 4:15 PM Armijn Hemel <armijn@...> wrote:


Op 25 okt. 2021 om 23:24 heeft Warner Losh <imp@...> het volgende geschreven:

The Heirloom Bourne Shell project is used in Fedora, so that's how it came up. I don't know if it's used elsewhere or if this variant of the license, but any info on that would be helpful!

I wonder why they are using the Caldera license?


Right. This doesn't answer my question about their heirloom /bin/sh. Was it from Caldera or was it from Sun? And why did they drop the intro text?

Warner
 

Did they harvest these files from the 7th Edition of Unix, or did Sun license these and Caldera made them put this license on things? The version 7 /bin/sh was included in the grant of the original license, and the System V version was excluded which is what the OpenSolaris one is based on if it came from Sun's repo... But I've not done the software archaeology to know from whence this project started their sources...


Re: Caldera license question

Armijn Hemel - Tjaldur Software Governance Solutions
 



Op 25 okt. 2021 om 23:24 heeft Warner Losh <imp@...> het volgende geschreven:

The Heirloom Bourne Shell project is used in Fedora, so that's how it came up. I don't know if it's used elsewhere or if this variant of the license, but any info on that would be helpful!

I wonder why they are using the Caldera license?




Did they harvest these files from the 7th Edition of Unix, or did Sun license these and Caldera made them put this license on things? The version 7 /bin/sh was included in the grant of the original license, and the System V version was excluded which is what the OpenSolaris one is based on if it came from Sun's repo... But I've not done the software archaeology to know from whence this project started their sources...


Re: remove recommendation re: standard license headers

Warner Losh
 



On Mon, Oct 25, 2021 at 9:43 AM J Lovejoy <opensource@...> wrote:
Hi all,

We have some text at the bottom of this page https://spdx.dev/ids/ regarding the use of SPDX ids related to a recommendation about using and retaining standard headers when using/adding an SPDX id in source code.

If memory serves, we wrote this at the time when use of SPDX ids in source code was a very new thing. We didn't know if some license stewards might have discomfort with the use of SPDX ids *instead* of their suggested standard license header, and thus felt the need to take a sort of conservative approach.

Now that SPDX ids are used more widely and we know a bit more about how scanning tools identify license headers in total - I think we can remove this section altogether. I don't think SPDX needs to make a statement either way and projects can make their own call, as we've seen with the Linux kernal and other projects.

Thoughts?

I've been grappling with this in the FreeBSD project. I'll share my perspective.

There's two parts to that advice. The first is to include the standard boilerplate text to invoke the license ("the standard header," though that phrase means something different in my world, so it should be eliminated for that reason alone). I think we can toss that. This project found dozens (hundreds) of variations in the prescribed text from the FSF GPL, suggesting that the suggested text is more of a suggestion than a requirement.

The suggestion of not removing the boilerplate text for a license is tricky. There's a lot of inertia and received wisdom that one must never do this (since often the text includes statements that it must be retained). With the SPDX, though, the text is substantially reproduced, in durable form by a 3rd party and the reference to that third party's copy could be construed to be reproducing the text (in fact, this notion seems like a bedrock SPDX principal axiom: giving a pointer to the license is just as good as reproducing the whole license). There's much consternation in the FreeBSD project, none-the-less, with wholesale removal of these standard license texts because the variations or slight word changes means we're not reproducing the conditions exactly, and that delta may put us out of license compliance. It's an open question for the chat I hope to have with a competent attorney before the project finalizes its policies towards SPDX. So removing the advice not to remove the license text is fine, imho, since that's legal advice for what constitutes compliance (imho). Replacing it with text that says it's OK or always OK, though would not be cool, imho. Though having that there might encourage others to adopt the SPDX-only policies that have become widespread but not universal.

Does that help?

Warner
 
Jilayne


Re: Caldera license question

Warner Losh
 



On Mon, Oct 25, 2021 at 9:39 AM J Lovejoy <opensource@...> wrote:
Hi all,

I came across a "variant" of the Caldera license. Here is what we have on SPDX: https://spdx.org/licenses/Caldera.html

But this project - http://heirloom.sourceforge.net/sh.html has this license but it omits the first paragraph and next few lines. That part alone isn't a full match otherwise. (see attached)

I'm wondering if we should made that first part optional as it does seem to be very specific code, as listed.

The Heirloom Bourne Shell project is used in Fedora, so that's how it came up. I don't know if it's used elsewhere or if this variant of the license, but any info on that would be helpful!

I wonder why they are using the Caldera license?

Did they harvest these files from the 7th Edition of Unix, or did Sun license these and Caldera made them put this license on things? The version 7 /bin/sh was included in the grant of the original license, and the System V version was excluded which is what the OpenSolaris one is based on if it came from Sun's repo... But I've not done the software archaeology to know from whence this project started their sources....

Though thinking about it, it likely doesn't matter for our purposes...  I think having a variant is fine as long as the consensus legal opinion of this team is that the differences don't change anything. The first few paragraphs could only apply to the ancient unix sources and nothing else that wants to use this license.

Followup question though: Once the first few lines are removed, is the license the same as one of the BSD and/or MIT variants?

Warner
 
Thanks,
Jilayne


remove recommendation re: standard license headers

J Lovejoy
 

Hi all,

We have some text at the bottom of this page https://spdx.dev/ids/ regarding the use of SPDX ids related to a recommendation about using and retaining standard headers when using/adding an SPDX id in source code.

If memory serves, we wrote this at the time when use of SPDX ids in source code was a very new thing. We didn't know if some license stewards might have discomfort with the use of SPDX ids *instead* of their suggested standard license header, and thus felt the need to take a sort of conservative approach.

Now that SPDX ids are used more widely and we know a bit more about how scanning tools identify license headers in total - I think we can remove this section altogether. I don't think SPDX needs to make a statement either way and projects can make their own call, as we've seen with the Linux kernal and other projects.

Thoughts?

Jilayne


Caldera license question

J Lovejoy
 

Hi all,

I came across a "variant" of the Caldera license. Here is what we have on SPDX: https://spdx.org/licenses/Caldera.html

But this project - http://heirloom.sourceforge.net/sh.html has this license but it omits the first paragraph and next few lines. That part alone isn't a full match otherwise. (see attached)

I'm wondering if we should made that first part optional as it does seem to be very specific code, as listed.

The Heirloom Bourne Shell project is used in Fedora, so that's how it came up. I don't know if it's used elsewhere or if this variant of the license, but any info on that would be helpful!

Thanks,
Jilayne


Re: [spdx] Message Approval Needed - tardyp@gmail.com posted to spdx@lists.spdx.org

Pierre Tardy
 

Thank you Jilayne and Richard for your kind answers.

I am so used to look at file headers that I didn't even think of looking if there was a LICENSE file :-}

Regards,
Pierre


Le mar. 19 oct. 2021 à 22:04, J Lovejoy <opensource@...> a écrit :
Hi Pierre,

I am moving the general SPDX list to BCC and sending this via the SPDX legal list, as that is the right place for this question! Also not - I have approved your message and copied you here so you will get the response, but you generally have to join the SPDX mailing list to post and receive message. https://lists.spdx.org/groups

Looking at the license file for that project: Alternative A is indeed MIT and Alternative B is the Unlicense (https://spdx.org/licenses/Unlicense.html)

Thus, the SPDX license expression would be:  MIT OR Unlicense

FYI - you might want to install the license diff browser plugin to help you with these kinds of things - https://chrome.google.com/webstore/detail/spdx-license-diff/kfoadicmilbgnicoldjmccpaicejacdh?hl=en (also available for Firefox)

Thanks
Jilayne
SPDX legal team co-lead



From: "Pierre Tardy" <tardyp@...>
Subject: Public Domain license identifier
Date: October 19, 2021 at 7:12:29 AM MDT


Hello,

I am trying to identify this software in term of license expression


It's is claimed to be "public domain or MIT".
I don't see any license identifier for public domain. It is arguabily not a license, and not valid across jurisdictions, but anyway we would like to document the authors will even if we will conclude the use of MIT.

So what should we document in your opinion?

Regards

Pierre




Re: [spdx] Message Approval Needed - tardyp@gmail.com posted to spdx@lists.spdx.org

J Lovejoy
 

Hi Pierre,

I am moving the general SPDX list to BCC and sending this via the SPDX legal list, as that is the right place for this question! Also not - I have approved your message and copied you here so you will get the response, but you generally have to join the SPDX mailing list to post and receive message. https://lists.spdx.org/groups

Looking at the license file for that project: Alternative A is indeed MIT and Alternative B is the Unlicense (https://spdx.org/licenses/Unlicense.html)

Thus, the SPDX license expression would be:  MIT OR Unlicense

FYI - you might want to install the license diff browser plugin to help you with these kinds of things - https://chrome.google.com/webstore/detail/spdx-license-diff/kfoadicmilbgnicoldjmccpaicejacdh?hl=en (also available for Firefox)

Thanks
Jilayne
SPDX legal team co-lead



From: "Pierre Tardy" <tardyp@...>
Subject: Public Domain license identifier
Date: October 19, 2021 at 7:12:29 AM MDT


Hello,

I am trying to identify this software in term of license expression


It's is claimed to be "public domain or MIT".
I don't see any license identifier for public domain. It is arguabily not a license, and not valid across jurisdictions, but anyway we would like to document the authors will even if we will conclude the use of MIT.

So what should we document in your opinion?

Regards

Pierre




Re: call today

Warner Losh
 



On Thu, Oct 14, 2021 at 8:51 AM J Lovejoy <opensource@...> wrote:
We have our regularly scheduled call today in a bit over an hour from now.  We’ll get back to reviewing issues and prepping for the next release - as well as any updates on other on-going projects.

I'll give an update on FreeBSD's use of SPDX next time. Work has been unexpectedly busy so I've not had time to prepare.

Warner 


call today

J Lovejoy
 

Hi all,

We have our regularly scheduled call today in a bit over an hour from now. We’ll get back to reviewing issues and prepping for the next release - as well as any updates on other on-going projects.

Thanks,
Jilayne


Re: legal call today

Sebastian Crane
 

Dear Jilayne,

Hi all,

We have our regular call today at noon EDT.

We'll catch up on any other "intros"; I think Warner was going to give
an update on the SPDX work in FreeBSD (if you are ready to do so), and
get organized with the latest issues in the repo.
I'll do my best to come - apologies however, as I too am having network
issues so can't guarantee attendance! Has there been a solar flare or
something?!

Best wishes,

Sebastian


Re: legal call today

Warner Losh
 



On Thu, Sep 30, 2021 at 8:40 AM J Lovejoy <opensource@...> wrote:
Hi all,

We have our regular call today at noon EDT.

We'll catch up on any other "intros"; I think Warner was going to give an update on the SPDX work in FreeBSD (if you are ready to do so), and get organized with the latest issues in the repo.

That was my plan, but I will have to do it next time. I'm fighting internet issues and since comcast is involved, it's looking like it is going to take a while.

Warner
 
I'd like to have a bit of a brainstorm about some better methods for staying on top of new issues (something I know I struggle with) so we are not waiting for meetings to tackle stuff with very little done in between, so come with your project manager hat on!

Jilayne



legal call today

J Lovejoy
 

Hi all,

We have our regular call today at noon EDT.

We'll catch up on any other "intros"; I think Warner was going to give an update on the SPDX work in FreeBSD (if you are ready to do so), and get organized with the latest issues in the repo.

I'd like to have a bit of a brainstorm about some better methods for staying on top of new issues (something I know I struggle with) so we are not waiting for meetings to tackle stuff with very little done in between, so come with your project manager hat on!

Jilayne



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? :)

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 my background 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 <opensource@...>
Date: Friday, 17. September 2021 at 00:12
To: Karsten Klein <karsten.klein@...>
Cc: SPDX-legal <Spdx-legal@...>, <Spdx-tech@...>, Thomas Schulte <thomas.schulte@...>, Kate Stewart <kstewart@...>
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.klein@...> 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

  1.  

 

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.

 



Re: Take on concluded license; introducing effective license

Karsten Klein
 

Hi Jilayne,

  • 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.

  • 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. 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,

Karsten

 

 

From: J Lovejoy <opensource@...>
Date: Friday, 17. September 2021 at 00:12
To: Karsten Klein <karsten.klein@...>
Cc: SPDX-legal <Spdx-legal@...>, <Spdx-tech@...>, Thomas Schulte <thomas.schulte@...>, Kate Stewart <kstewart@...>
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.klein@...> 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

  1.  

 

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.

 


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


On Sep 16, 2021, at 12:30 PM, Karsten Klein <karsten.klein@...> 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
 
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.


Re: Take on concluded license; introducing effective license

Karsten Klein
 

Resending unsigned due to issues with the list and my signature; I hope this solves the problem…

 

 

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)

 

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)
  • 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 (downstream)

 

I sketched a picture that shows where I would like SPDX to go introducing an effective license separated from concluded license:

 

 

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

 

B:

  • Author declared license correct and complete, but with option
  • Policy-based decision towards more permissive license with less obligations in the use case

 

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.

 


Re: Take on concluded license; introducing effective license

Sebastian Crane
 

Dear Karsten,

Sorry; I can't read your email - it appears to be encrypted. The online
mailing list archives are also unable to show your email's content.

Now I'm even more curious to know what 'effective license' is :)

Best wishes,

Sebastian

261 - 280 of 3278