Date   

SPDX Signing #spdx

Patil, Sandeep
 

Hi All,
Is there any guidelines to sign SPDX file ? 

Regards
Sandeep 


SPDX Merging #spdx

Patil, Sandeep
 

Hi All, 
Is there any tool to merge two spdx file ? 

Regards
Sandeep 


SPDX Thurs General Meeting Reminder

Phil Odence
 

Special Presentation this month by Matthew Crawford from Arm:

Title

A new era for SPDX at Arm, are we ready for change?

 

Let me walk you through the journey of open source software compliance at Arm, from spreadsheets of doom to a platform that captures OSS approvals and produces SPDX files. There were numerous hurdles along the journey but with the help of the internal and external community (including members of this group) we have achieved something that is helpful for Arm and its partners. 

 

Bio

 

Matthew Crawford has been working at Arm since 2017 mainly focusing on the Third Party Intellectual Property strategy and process management. His professional accomplishments include working to make Arm OpenChain conformant in 2019; involvement in the Google Summer of Code as a mentor and working with the SPDX community. He has a strong passion for open source hardware and software governance, trust and security. Before 2017, Matthew worked in the pharmaceutical industry for GlaxoSmithKline and amongst other things worked on building trust in the software being used throughout the supply chain (as well as designing and synthesising medicines!).

 

 

GENERAL MEETING

 

Meeting Time: Thurs, Aug 4, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval: https://github.com/spdx/meetings/blob/main/general/2022-06-02.md

 

Presentation- Matthew

 

Steering Committee Update - Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian/Alexios


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Neal Gompa
 

On Mon, Aug 1, 2022 at 4:20 AM Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> wrote:

Nice. This certainly makes it easy to map from Fedora to SPDX IDs!

 SPDX license identifiers have emerged as a standard

 

Woo hoo!

_,_._,_

I hope you are all ready for the upcoming pains in the next few years. Transitioning Fedora to SPDX is not going to be a happy time for a little while, since there's a huge impedance mismatch between Fedora and SPDX, as well as an incomplete identification of licenses on the SPDX side. I know I'm not looking forward to recategorizing all the MIT and BSD license variants. I expect we're going to see a lot of new license submissions over the coming years as all packages get re-audited in a future phase...

I wonder if we're going to regret this extra "precision" in the end?

On a personal note, I am still rather upset about some aspects of the expression syntax that I had been informed years ago would be fixed, but has apparently not been. In particular, the specification still does not allow lowercase "or"/"and"/"with" even though all the parsers accept it. Reading SPDX expressions with capital operands is very painful for humans (which is what these things are actually for). Any chance we can get this fixed soon?



--
真実はいつも一つ!/ Always, there's only one truth!


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Phil Odence
 

Nice. This certainly makes it easy to map from Fedora to SPDX IDs!

 SPDX license identifiers have emerged as a standard

 

Woo hoo!

 

 

From: Spdx-legal@... <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...>
Date: Saturday, July 30, 2022 at 12:06 PM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>, spdx@... <spdx@...>, Spdx-tech@... <Spdx-tech@...>, Spdx-outreach@... <Spdx-outreach@...>
Subject: Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Jilayne, this is awesome news -- thanks for passing it along!

 

Looking forward to us working with the Fedora community to support them adding SPDX license IDs across the distro.

 

Steve

 

On Fri, Jul 29, 2022 at 12:21 PM J Lovejoy <opensource@...> wrote:

Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne



-------- Forwarded Message --------

Subject:

[Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)

Date:

Fri, 29 Jul 2022 11:19:48 -0400

From:

Matthew Miller <mattdm@...>

Reply-To:

legal@...

To:

devel-announce@...

CC:

packaging@..., legal@..., devel@...




On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../


-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Steve Winslow
 

Jilayne, this is awesome news -- thanks for passing it along!

Looking forward to us working with the Fedora community to support them adding SPDX license IDs across the distro.

Steve

On Fri, Jul 29, 2022 at 12:21 PM J Lovejoy <opensource@...> wrote:
Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne


-------- Forwarded Message --------
Subject: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
Date: Fri, 29 Jul 2022 11:19:48 -0400
From: Matthew Miller <mattdm@...>
Reply-To: legal@...
To: devel-announce@...
CC: packaging@..., legal@..., devel@...



On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../



-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


Important changes to software license information in Fedora packages (SPDX and more!)

J Lovejoy
 

Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne


-------- Forwarded Message --------
Subject: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
Date: Fri, 29 Jul 2022 11:19:48 -0400
From: Matthew Miller <mattdm@...>
Reply-To: legal@...
To: devel-announce@...
CC: packaging@..., legal@..., devel@...



On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../



-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


SPDX Spec Version 2.3 Available for Review

Gary O'Neall
 

Greetings all,

 

The SPDX spec version 2.3 is now available for review at https://spdx.github.io/spdx-spec/v2.3-RC1/.

 

A summary of the changes can be found in the SPEC Annex I.

 

If you identify any issues, please submit an issue or pull request in the SPDX spec repository.  See the CONTRIBUTING.md file for details.  You can also submit issues to the SPDX tech mailing list.

 

Please submit any issues or proposed spec changes by end of day August 10.

 

Best regards,

SPDX Tech Team

 

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: Specific SPDX identifier question I didn't see addressed in the specification

J Lovejoy
 

Hi all, 

Again, this conversation belongs on the SPDX-legal mailing list, not the SPDX-general list. I tried to remedy this early on, but somehow SPDX-legal got dropped and it went back to SPDX-general.

Please be sure to check you are a member of the relevant mailing lists here: https://lists.spdx.org/groups

I’m happy to re-start this thread or raise it as a topic on the next SPDX legal team call, but either way a new thread or conversation needs to be started to avoid unnecessary traffic on the SPDX-general list.  

Thanks,
Jilayne
SPDX legal team co-lead
Steering Committee member

On Jul 11, 2022, at 11:17 AM, McCoy Smith <mccoy@...> wrote:



On Jul 11, 2022, at 9:51 AM, Alexios Zavras <alexios.zavras@...> wrote:

I think our understanding until now is that the package should have "License-A AND License-B", to denote the presence of these licenses. But conversely, this license expression should NOT be understood to mean that "everything in here is under this expression (combination of licenses)".

Richard's example of taking the license of a set and applying it to every single item shows the error in this approach.
Yes that’s it. I think AND alone could be (and might widely be) misconstrued as to what state is actually being represented.
One solution is for people and tools to correctly understand the SPDX tags and operators.
The other is to convey more information with those tags and operators.
Which is best I don’t know, depends on how well people and tools are interpreting the conveyed information.
This is a bit orthogonal from my initial inquiry, but perhaps my inquiry tests the limits of “just use AND” as the solution?
-- zvr

-----Original Message-----
From: spdx@... <spdx@...> On Behalf Of McCoy Smith
Sent: Monday, 11 July, 2022 19:43
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

At this risk of opening up a giant can of worms:
Does logical AND for SPDX make sense without more information? Even if a group of files clearly designate a single license at file level, and project identifies each of those licenses with logical AND at project level, you still can have misunderstandings if file level is not interrogated.

On Jul 11, 2022, at 9:21 AM, Richard Fontana <rfontana@...> wrote:
If you take the patch referenced in the LWN article, you could rewrite that as:
SPDX-License-Identifier: GPL-2.0-or-later AND ISC
But then subsequent modifications of the file are going to be assumed
to be licensed under both GPLv2 and ISC, whereas it is likely the
subsequent modifier conceptualized their changes as just being GPLv2.
This reminds me: I've recently been informed of a project that started
using SPDX-License-Identifier: and this has led to a complicated issue
around a desired license change because it appears as though many
contributions to the project were inadvertently made under a
conjunction of two licenses, which was the result of putting a
conjunctive SPDX-License-Identifier statement in a README file. I
don't have the case handy but it was something like, some source files
were BSD-3-Clause, some were Apache-2.0, someone then helpfully put
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file,
and then new source files started mechanically including
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0.
Richard
On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <rfontana@...> wrote:
Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.
I'm not sure what I think now. I will say, the norm SFLC was trying
to establish in the wake of the ath5k affair never really caught on.
The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.
Richard
On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:
Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD
outbound GPL
https://lwn.net/Articles/247806/
I’m suggestion an SPDX tag for what was used there:
This file is based on work under the following copyright and permission notice:
On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:

On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:
You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?
But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:
“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”
You have a case citation for that?
Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.
Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise.  It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:
These questions are really off-topic.
If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).
There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:
“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”
https://docs.freebsd.org/en/articles/bsdl-gpl/
What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.
The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:
Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.
I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).
But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.
Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...
Warner
From: spdx@... <spdx@...> On Behalf Of J
Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
Hi McCoy!
I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.
Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?
Thanks,
Jilayne
On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:
I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.
Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:
Preserve all existing IP notices (or in some cases, just copyright
notices) Provide a copy of the license (or something to that
effect: retaining “this permission notice” (ICU/Unicode/MIT)  or
“this list of conditions” (BSD) or providing “a copy of this
License” (Apache 2.0))
The rules around element 1 and SPDX are well-described.
With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):
SPDX-License-Identifier: MIT
[This file/package/project contains code originally licensed
under:]
SPDX-License-Identifier: BSD-2-Clause
The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928










Re: Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith
 



On Jul 11, 2022, at 9:51 AM, Alexios Zavras <alexios.zavras@...> wrote:

I think our understanding until now is that the package should have "License-A AND License-B", to denote the presence of these licenses. But conversely, this license expression should NOT be understood to mean that "everything in here is under this expression (combination of licenses)".

Richard's example of taking the license of a set and applying it to every single item shows the error in this approach.
Yes that’s it. I think AND alone could be (and might widely be) misconstrued as to what state is actually being represented.
One solution is for people and tools to correctly understand the SPDX tags and operators.
The other is to convey more information with those tags and operators.
Which is best I don’t know, depends on how well people and tools are interpreting the conveyed information.
This is a bit orthogonal from my initial inquiry, but perhaps my inquiry tests the limits of “just use AND” as the solution?
-- zvr

-----Original Message-----
From: spdx@... <spdx@...> On Behalf Of McCoy Smith
Sent: Monday, 11 July, 2022 19:43
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

At this risk of opening up a giant can of worms:
Does logical AND for SPDX make sense without more information? Even if a group of files clearly designate a single license at file level, and project identifies each of those licenses with logical AND at project level, you still can have misunderstandings if file level is not interrogated.

On Jul 11, 2022, at 9:21 AM, Richard Fontana <rfontana@...> wrote:
If you take the patch referenced in the LWN article, you could rewrite that as:
SPDX-License-Identifier: GPL-2.0-or-later AND ISC
But then subsequent modifications of the file are going to be assumed
to be licensed under both GPLv2 and ISC, whereas it is likely the
subsequent modifier conceptualized their changes as just being GPLv2.
This reminds me: I've recently been informed of a project that started
using SPDX-License-Identifier: and this has led to a complicated issue
around a desired license change because it appears as though many
contributions to the project were inadvertently made under a
conjunction of two licenses, which was the result of putting a
conjunctive SPDX-License-Identifier statement in a README file. I
don't have the case handy but it was something like, some source files
were BSD-3-Clause, some were Apache-2.0, someone then helpfully put
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file,
and then new source files started mechanically including
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0.
Richard
On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <rfontana@...> wrote:
Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.
I'm not sure what I think now. I will say, the norm SFLC was trying
to establish in the wake of the ath5k affair never really caught on.
The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.
Richard
On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:
Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD
outbound GPL
https://lwn.net/Articles/247806/
I’m suggestion an SPDX tag for what was used there:
This file is based on work under the following copyright and permission notice:
On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:

On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:
You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?
But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:
“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”
You have a case citation for that?
Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.
Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:
These questions are really off-topic.
If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).
There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:
“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”
https://docs.freebsd.org/en/articles/bsdl-gpl/
What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.
The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:
Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.
I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).
But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.
Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...
Warner
From: spdx@... <spdx@...> On Behalf Of J
Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification
Hi McCoy!
I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.
Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?
Thanks,
Jilayne
On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:
I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.
Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:
Preserve all existing IP notices (or in some cases, just copyright
notices) Provide a copy of the license (or something to that
effect: retaining “this permission notice” (ICU/Unicode/MIT) or
“this list of conditions” (BSD) or providing “a copy of this
License” (Apache 2.0))
The rules around element 1 and SPDX are well-described.
With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):
SPDX-License-Identifier: MIT
[This file/package/project contains code originally licensed
under:]
SPDX-License-Identifier: BSD-2-Clause
The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?




Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928



Re: Specific SPDX identifier question I didn't see addressed in the specification

Warner Losh
 



On Mon, Jul 11, 2022 at 10:42 AM McCoy Smith <mccoy@...> wrote:
At this risk of opening up a giant can of worms:
Does logical AND for SPDX make sense without more information? Even if a group of files clearly designate a single license at file level, and project identifies each of those licenses with logical AND at project level, you still can have misunderstandings if file level is not interrogated.

SPDX is a compliance tool. It's designed to help people comply with their obligations. It doesn't cover every possible eventuality, and this situation falls outside the spec. IMHO.

Having said that, one of the concerns that the FreeBSD project had in starting to move to a SPDX-only world was what does it mean, exactly, for the project. We've started to document what it means and how to read different situations (eg, both license and SPDX tags, then the license is controlling and the SPDX tags are intended to aid automation only vs SPDX only, then the copy of the license we'll be including in our tree, with the appropriate fields filled in, is how one should construct the license agreement, etc). How an individual file affects other files likely should be spelled out in the project's documentation (I didn't in mine, but we don't put SPDX tags in our global readme file, so there's no chance for confusion), as should other relevant issues not within the scope of the current standards.

Warner
 
> On Jul 11, 2022, at 9:21 AM, Richard Fontana <rfontana@...> wrote:
>
> If you take the patch referenced in the LWN article, you could rewrite that as:
>
> SPDX-License-Identifier: GPL-2.0-or-later AND ISC
>
> But then subsequent modifications of the file are going to be assumed
> to be licensed under both GPLv2 and ISC, whereas it is likely the
> subsequent modifier conceptualized their changes as just being GPLv2.
>
> This reminds me: I've recently been informed of a project that started
> using SPDX-License-Identifier: and this has led to a complicated issue
> around a desired license change because it appears as though many
> contributions to the project were inadvertently made under a
> conjunction of two licenses, which was the result of putting a
> conjunctive SPDX-License-Identifier statement in a README file. I
> don't have the case handy but it was something like, some source files
> were BSD-3-Clause, some were Apache-2.0, someone then helpfully put
> SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file,
> and then new source files started mechanically including
> SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0.
>
> Richard
>
>> On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <rfontana@...> wrote:
>>
>> Ah, that is exactly the issue I was asking about a few years ago. The
>> response on this list was that an SPDX-License-Identifier: statement
>> consisting of an "AND" expression was good enough as an alternative.
>> But my view at the time was that this entailed a loss of information
>> -- you lose the idea that the GPL is in some sense the overarching or
>> dominant license of some set of code with some subsidiary elements
>> under distinct licenses.
>>
>> I'm not sure what I think now. I will say, the norm SFLC was trying to
>> establish in the wake of the ath5k affair never really caught on.
>>
>> The 'snippet' solution isn't really practical in many cases because
>> you won't often be able to precisely identify the boundaries of the
>> snippet.
>>
>> Richard
>>
>>> On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:
>>>
>>> Back to the original query:
>>> Here’s an example of what I was talking about, albeit inbound BSD outbound GPL
>>>
>>> https://lwn.net/Articles/247806/
>>>
>>> I’m suggestion an SPDX tag for what was used there:
>>>
>>> This file is based on work under the following copyright and permission notice:
>>>
>>>
>>>> On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:
>>>
>>> 
>>>
>>>
>>>> On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:
>>>
>>>
>>> You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
>>>
>>> I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?
>>>
>>> But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
>>>
>>> You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.
>>>
>>>
>>> Warner
>>>
>>>>
>>>>
>>>>
>>>> From: spdx@... <spdx@...> On Behalf Of Warner Losh
>>>> Sent: Monday, July 11, 2022 7:20 AM
>>>> To: spdx@...
>>>> Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:
>>>>
>>>> “The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”
>>>>
>>>>
>>>>
>>>> You have a case citation for that?
>>>>
>>>>
>>>>
>>>> Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.
>>>>
>>>>
>>>>
>>>> Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise.  It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.
>>>>
>>>>
>>>>
>>>> Warner
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: spdx@... <spdx@...> On Behalf Of Warner Losh
>>>> Sent: Monday, July 11, 2022 7:07 AM
>>>> To: spdx@...
>>>> Cc: SPDX-legal <spdx-legal@...>
>>>> Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:
>>>>
>>>> These questions are really off-topic.
>>>>
>>>> If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).
>>>>
>>>> There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:
>>>>
>>>> “The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”
>>>>
>>>>
>>>>
>>>> https://docs.freebsd.org/en/articles/bsdl-gpl/
>>>>
>>>>
>>>>
>>>> What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.
>>>>
>>>>
>>>>
>>>> The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.
>>>>
>>>>
>>>>
>>>> Warner
>>>>
>>>>
>>>>
>>>> From: spdx@... <spdx@...> On Behalf Of Warner Losh
>>>> Sent: Friday, July 1, 2022 2:11 PM
>>>> To: spdx@...
>>>> Cc: SPDX-legal <spdx-legal@...>
>>>> Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:
>>>>
>>>> Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.
>>>>
>>>> I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).
>>>>
>>>> But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.
>>>>
>>>> Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...
>>>>
>>>>
>>>>
>>>> Warner
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: spdx@... <spdx@...> On Behalf Of J Lovejoy
>>>> Sent: Friday, July 1, 2022 1:11 PM
>>>> To: SPDX-legal <spdx-legal@...>
>>>> Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification
>>>>
>>>>
>>>>
>>>> Hi McCoy!
>>>>
>>>>
>>>>
>>>> I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.
>>>>
>>>>
>>>>
>>>> Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jilayne
>>>>
>>>>
>>>>
>>>> On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:
>>>>
>>>>
>>>>
>>>> I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.
>>>>
>>>>
>>>>
>>>> Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:
>>>>
>>>> Preserve all existing IP notices (or in some cases, just copyright notices)
>>>> Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
>>>>
>>>>
>>>>
>>>> The rules around element 1 and SPDX are well-described.
>>>>
>>>> With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):
>>>>
>>>>
>>>>
>>>> SPDX-License-Identifier: MIT
>>>>
>>>> [This file/package/project contains code originally licensed under:]
>>>>
>>>> SPDX-License-Identifier: BSD-2-Clause
>>>>
>>>>
>>>>
>>>> The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
>>>>
>>>>
>>>> One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
>>>>
>>>>
>>>>
>>>> Thoughts? Am I missing something?
>>>>
>>>>
>>>
>>>
>
>
>
>
>
>






Re: Specific SPDX identifier question I didn't see addressed in the specification

Alexios Zavras
 

McCoy,

Your example was about snippets in files, but this also happens one level up:
If there are some files under License-A and some files under License-B, how do you express the license of a package that includes all these files? (by "file" and "package" I use the SPDX terms).

I think our understanding until now is that the package should have "License-A AND License-B", to denote the presence of these licenses. But conversely, this license expression should NOT be understood to mean that "everything in here is under this expression (combination of licenses)".

Richard's example of taking the license of a set and applying it to every single item shows the error in this approach.

-- zvr

-----Original Message-----
From: spdx@... <spdx@...> On Behalf Of McCoy Smith
Sent: Monday, 11 July, 2022 19:43
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

At this risk of opening up a giant can of worms:
Does logical AND for SPDX make sense without more information? Even if a group of files clearly designate a single license at file level, and project identifies each of those licenses with logical AND at project level, you still can have misunderstandings if file level is not interrogated.

On Jul 11, 2022, at 9:21 AM, Richard Fontana <rfontana@...> wrote:

If you take the patch referenced in the LWN article, you could rewrite that as:

SPDX-License-Identifier: GPL-2.0-or-later AND ISC

But then subsequent modifications of the file are going to be assumed
to be licensed under both GPLv2 and ISC, whereas it is likely the
subsequent modifier conceptualized their changes as just being GPLv2.

This reminds me: I've recently been informed of a project that started
using SPDX-License-Identifier: and this has led to a complicated issue
around a desired license change because it appears as though many
contributions to the project were inadvertently made under a
conjunction of two licenses, which was the result of putting a
conjunctive SPDX-License-Identifier statement in a README file. I
don't have the case handy but it was something like, some source files
were BSD-3-Clause, some were Apache-2.0, someone then helpfully put
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file,
and then new source files started mechanically including
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0.

Richard

On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <rfontana@...> wrote:

Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.

I'm not sure what I think now. I will say, the norm SFLC was trying
to establish in the wake of the ath5k affair never really caught on.

The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.

Richard

On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:

Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD
outbound GPL

https://lwn.net/Articles/247806/

I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:


On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:



On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:

You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.

I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?

But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.

You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.


Warner




From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification







On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”



You have a case citation for that?



Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.



Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.



Warner





From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification







On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”



https://docs.freebsd.org/en/articles/bsdl-gpl/



What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.



The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.



Warner



From: spdx@... <spdx@...> On Behalf Of Warner
Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification





On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...



Warner





From: spdx@... <spdx@...> On Behalf Of J
Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see
addressed in the specification



Hi McCoy!



I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.



Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?



Thanks,

Jilayne



On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:



I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.



Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

Preserve all existing IP notices (or in some cases, just copyright
notices) Provide a copy of the license (or something to that
effect: retaining “this permission notice” (ICU/Unicode/MIT) or
“this list of conditions” (BSD) or providing “a copy of this
License” (Apache 2.0))



The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):



SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed
under:]

SPDX-License-Identifier: BSD-2-Clause



The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.



Thoughts? Am I missing something?









Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith
 

At this risk of opening up a giant can of worms:
Does logical AND for SPDX make sense without more information? Even if a group of files clearly designate a single license at file level, and project identifies each of those licenses with logical AND at project level, you still can have misunderstandings if file level is not interrogated.

On Jul 11, 2022, at 9:21 AM, Richard Fontana <rfontana@...> wrote:

If you take the patch referenced in the LWN article, you could rewrite that as:

SPDX-License-Identifier: GPL-2.0-or-later AND ISC

But then subsequent modifications of the file are going to be assumed
to be licensed under both GPLv2 and ISC, whereas it is likely the
subsequent modifier conceptualized their changes as just being GPLv2.

This reminds me: I've recently been informed of a project that started
using SPDX-License-Identifier: and this has led to a complicated issue
around a desired license change because it appears as though many
contributions to the project were inadvertently made under a
conjunction of two licenses, which was the result of putting a
conjunctive SPDX-License-Identifier statement in a README file. I
don't have the case handy but it was something like, some source files
were BSD-3-Clause, some were Apache-2.0, someone then helpfully put
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file,
and then new source files started mechanically including
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0.

Richard

On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <rfontana@...> wrote:

Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.

I'm not sure what I think now. I will say, the norm SFLC was trying to
establish in the wake of the ath5k affair never really caught on.

The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.

Richard

On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:

Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD outbound GPL

https://lwn.net/Articles/247806/

I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:


On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:



On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:

You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.

I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?

But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.

You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.


Warner




From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”



You have a case citation for that?



Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.



Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.



Warner





From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”



https://docs.freebsd.org/en/articles/bsdl-gpl/



What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.



The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.



Warner



From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification





On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...



Warner





From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification



Hi McCoy!



I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.



Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?



Thanks,

Jilayne



On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:



I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.



Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

Preserve all existing IP notices (or in some cases, just copyright notices)
Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))



The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):



SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause



The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.



Thoughts? Am I missing something?






Re: Specific SPDX identifier question I didn't see addressed in the specification

Richard Fontana
 

If you take the patch referenced in the LWN article, you could rewrite that as:

SPDX-License-Identifier: GPL-2.0-or-later AND ISC

But then subsequent modifications of the file are going to be assumed
to be licensed under both GPLv2 and ISC, whereas it is likely the
subsequent modifier conceptualized their changes as just being GPLv2.

This reminds me: I've recently been informed of a project that started
using SPDX-License-Identifier: and this has led to a complicated issue
around a desired license change because it appears as though many
contributions to the project were inadvertently made under a
conjunction of two licenses, which was the result of putting a
conjunctive SPDX-License-Identifier statement in a README file. I
don't have the case handy but it was something like, some source files
were BSD-3-Clause, some were Apache-2.0, someone then helpfully put
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file,
and then new source files started mechanically including
SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0.

Richard

On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <rfontana@...> wrote:

Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.

I'm not sure what I think now. I will say, the norm SFLC was trying to
establish in the wake of the ath5k affair never really caught on.

The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.

Richard

On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:

Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD outbound GPL

https://lwn.net/Articles/247806/

I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:


On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:




On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:


You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.

I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?

But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.

You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.


Warner




From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”



You have a case citation for that?



Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.



Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.



Warner





From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”



https://docs.freebsd.org/en/articles/bsdl-gpl/



What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.



The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.



Warner



From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification





On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...



Warner





From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification



Hi McCoy!



I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.



Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?



Thanks,

Jilayne



On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:



I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.



Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

Preserve all existing IP notices (or in some cases, just copyright notices)
Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))



The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):



SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause



The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.



Thoughts? Am I missing something?


Re: Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith
 

In the end if it’s just reproducing the text I cited below that’s fine [I got reasonably close to it off the top of my head] and if there isn’t enough demand for a tag representing that language then I suppose there’s no need for one.
I just wonder if scanners are going to output inaccuracies on licensing without a tag.

On Jul 11, 2022, at 9:12 AM, Richard Fontana <rfontana@...> wrote:

Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.

I'm not sure what I think now. I will say, the norm SFLC was trying to
establish in the wake of the ath5k affair never really caught on.

The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.

Richard

On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:

Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD outbound GPL

https://lwn.net/Articles/247806/

I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:


On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:




On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:


You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.

I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?

But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.

You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.


Warner




From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:
“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”



You have a case citation for that?



Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.



Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.



Warner





From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:
These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”



https://docs.freebsd.org/en/articles/bsdl-gpl/



What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.



The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.



Warner



From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification





On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:
Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...



Warner





From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification



Hi McCoy!



I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.



Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?



Thanks,

Jilayne



On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:


I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.



Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

Preserve all existing IP notices (or in some cases, just copyright notices)
Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))



The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):



SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause



The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.



Thoughts? Am I missing something?






Re: Specific SPDX identifier question I didn't see addressed in the specification

Richard Fontana
 

Ah, that is exactly the issue I was asking about a few years ago. The
response on this list was that an SPDX-License-Identifier: statement
consisting of an "AND" expression was good enough as an alternative.
But my view at the time was that this entailed a loss of information
-- you lose the idea that the GPL is in some sense the overarching or
dominant license of some set of code with some subsidiary elements
under distinct licenses.

I'm not sure what I think now. I will say, the norm SFLC was trying to
establish in the wake of the ath5k affair never really caught on.

The 'snippet' solution isn't really practical in many cases because
you won't often be able to precisely identify the boundaries of the
snippet.

Richard

On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <mccoy@...> wrote:

Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD outbound GPL

https://lwn.net/Articles/247806/

I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:


On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:




On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:


You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.

I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?

But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.

You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.


Warner




From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”



You have a case citation for that?



Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.



Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.



Warner





From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification







On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”



https://docs.freebsd.org/en/articles/bsdl-gpl/



What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.



The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.



Warner



From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification





On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...



Warner





From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification



Hi McCoy!



I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.



Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?



Thanks,

Jilayne



On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:



I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.



Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

Preserve all existing IP notices (or in some cases, just copyright notices)
Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))



The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):



SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause



The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.



Thoughts? Am I missing something?


Re: Specific SPDX identifier question I didn't see addressed in the specification

Warner Losh
 




On Mon, Jul 11, 2022 at 10:03 AM McCoy Smith <mccoy@...> wrote:
Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD outbound GPL


This one is simple: BSD AND GPL-mumble for those files that contain both BSD and GPL code.

Warner
 
I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:

On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:




On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:

You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?
But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.

Warner
 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”

 

You have a case citation for that?

 

Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.

 

Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise.  It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”

 

https://docs.freebsd.org/en/articles/bsdl-gpl/

 

What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.

 

The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.

 

Warner

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

Hi McCoy!

 

I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.

 

Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?

 

Thanks,

Jilayne

 

On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:

 

I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.

 

Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

  1. Preserve all existing IP notices (or in some cases, just copyright notices)
  2. Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))

 

The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):

 

SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause

 

The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.

 

Thoughts? Am I missing something?

 


Re: Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith
 

Back to the original query:
Here’s an example of what I was talking about, albeit inbound BSD outbound GPL


I’m suggestion an SPDX tag for what was used there:

This file is based on work under the following copyright and permission notice:

On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:




On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:

You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?
But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.

Warner
 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”

 

You have a case citation for that?

 

Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.

 

Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise.  It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”

 

https://docs.freebsd.org/en/articles/bsdl-gpl/

 

What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.

 

The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.

 

Warner

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

Hi McCoy!

 

I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.

 

Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?

 

Thanks,

Jilayne

 

On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:

 

I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.

 

Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

  1. Preserve all existing IP notices (or in some cases, just copyright notices)
  2. Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))

 

The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):

 

SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause

 

The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.

 

Thoughts? Am I missing something?

 


Re: Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith
 



On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:

You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying?
But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.

Warner
 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”

 

You have a case citation for that?

 

Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.

 

Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise.  It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”

 

https://docs.freebsd.org/en/articles/bsdl-gpl/

 

What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.

 

The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.

 

Warner

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

Hi McCoy!

 

I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.

 

Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?

 

Thanks,

Jilayne

 

On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:

 

I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.

 

Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

  1. Preserve all existing IP notices (or in some cases, just copyright notices)
  2. Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))

 

The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):

 

SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause

 

The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.

 

Thoughts? Am I missing something?

 


Re: Specific SPDX identifier question I didn't see addressed in the specification

Warner Losh
 



On Mon, Jul 11, 2022 at 8:24 AM McCoy Smith <mccoy@...> wrote:

Don’t think the mailing list is the right place for this debate.

I’m certainly familiar with the BSD=copyleft argument. You’re welcome to hold that position yourself. If you’re involved with FreeBSD as their licensing manager, might I suggest that FreeBSD make explicit that they believe the BSD license to be copyleft?


You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.

But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.

Warner
 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote:

“The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.”

 

You have a case citation for that?

 

Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder.

 

Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise.  It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple.

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:07 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

 

On Mon, Jul 11, 2022 at 7:38 AM McCoy Smith <mccoy@...> wrote:

These questions are really off-topic.

If you have questions about interpretation of BSD licenses, you probably ought to ask them of your counsel (or if you’re associated with FreeBSD, their counsel).

There are also a lot of resources, many on-line and free, concerning the interpretation of most of the major open source licenses, including the BSD variants. This one might be instructive for you:

“The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). *This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.*”

 

https://docs.freebsd.org/en/articles/bsdl-gpl/

 

What does that have to do with anything? This is marketing material, not a license nor a grant to "file off" the old license and add your own new one. You are only allowed to add your new one and the old one is quite permissive otherwise.

 

The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it. The BSD license is quite permissive, but it isn't that permissive. So, your desire to express this concept in SPDX doesn't make sense. You are asking the SPDX license expression to cover something that's not a thing. That's my basic point, and so far you've done nothing to refute that.

 

Warner

 

From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Friday, July 1, 2022 2:11 PM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

 

On Fri, Jul 1, 2022, 2:17 PM McCoy Smith <mccoy@...> wrote:

Well the example is the reverse: inbound BSD-2-Clause, outbound MIT.

I’m more thinking license identifiers that go with the code (since I think for most folks that’s where they do license attribution/license copy requirements).

But obviously the issue/problem is more generic given that some permissive licenses allow the notice to be in either (or in some cases require in both) the source or documentation.

Are you allowed to do that without it becoming an AND? You can't just change the terms w/o permission like that I'd imagine... And I'm not sure how it would generalize...

 

Warner

 

 

From: spdx@... <spdx@...> On Behalf Of J Lovejoy
Sent: Friday, July 1, 2022 1:11 PM
To: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

Hi McCoy!

 

I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.

 

Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?

 

Thanks,

Jilayne

 

On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:

 

I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.

 

Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

  1. Preserve all existing IP notices (or in some cases, just copyright notices)
  2. Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))

 

The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):

 

SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause

 

The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.

 

Thoughts? Am I missing something?

 

21 - 40 of 1598