Date   

Re: Commutativity of SPDX expressions

McCoy Smith
 

Rather than getting into further debates about what various licenses do and don't require, or for that matter what copyright law does or doesn't require, I guess I'd turn back to the ath5k example.
Is the license designation they used the same as the AND operator in SPDX? I think it is not (or if AND encompasses it, AND may be interpreted too broadly so as to potentially cause confusion or incorrect assumptions about the license state).
Ath5k license designation is here: https://lwn.net/Articles/247806/
Now, people are free to respond back that the ath5k license designation is legally invalid, but I for one will not stand here and have Richard Fontana's legal skills besmirched!

-----Original Message-----
From: J Lovejoy <opensource@...>
Sent: Sunday, July 17, 2022 1:18 PM
To: McCoy Smith <mccoy@...>
Cc: Richard Fontana <rfontana@...>; SPDX-legal <spdx-
legal@...>
Subject: Re: Commutativity of SPDX expressions

Hi McCoy,

I’m wondering if you are trying to adapt SPDX identifiers in a situation not
anticipated. Consider that aim of an SPDX document (as per the SPDX
specification, and thus, using SPDX license ids in the various specification
field, is to communicate licensing, copyright, provenance, etc. information
for a given bundle of software. For example, I sell you Jilaynes-awesome-
software-app and provide an SPDX document for that software product. The
licensing info in this context would be presubaly what I think you are
referring to as the “outbound” license - that is the license under which the
software is used by the recipient.

Let’s say, Jilaynes-awesome-software-app includes some open source
software under various open source licenses, say, MIT and Apache-2.0, and I
also added some of my own (new) code under BSD-3-Clause, that all of this
can be reflected in the appropriate license fields at the package, file, and/or
snippet level.

I think of “inbound”, in relation to open source software, as usually referring
to the license under which contributions are provided to the project. But I
think you might be meaning “inbound” in relation to Jilayne’s-awesome-
software-app - that is, the open source software that I incorporate into my
app under MIT and Apache-2.0. Is that right?

Thanks,
Jilayne

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

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs
outbound, then AND may not be commutative, since the order of listing the
licenses may convey information about which license is inbound vs
outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point
already.

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

I'm working on some draft documentation for Fedora around use of
SPDX expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the
expression "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND
MIT". Does the SPDX spec actually take no position on this?

Richard









Re: Commutativity of SPDX expressions

J Lovejoy
 

Hi McCoy,

I’m wondering if you are trying to adapt SPDX identifiers in a situation not anticipated. Consider that aim of an SPDX document (as per the SPDX specification, and thus, using SPDX license ids in the various specification field, is to communicate licensing, copyright, provenance, etc. information for a given bundle of software. For example, I sell you Jilaynes-awesome-software-app and provide an SPDX document for that software product. The licensing info in this context would be presubaly what I think you are referring to as the “outbound” license - that is the license under which the software is used by the recipient.

Let’s say, Jilaynes-awesome-software-app includes some open source software under various open source licenses, say, MIT and Apache-2.0, and I also added some of my own (new) code under BSD-3-Clause, that all of this can be reflected in the appropriate license fields at the package, file, and/or snippet level.

I think of “inbound”, in relation to open source software, as usually referring to the license under which contributions are provided to the project. But I think you might be meaning “inbound” in relation to Jilayne’s-awesome-software-app - that is, the open source software that I incorporate into my app under MIT and Apache-2.0. Is that right?

Thanks,
Jilayne

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

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs outbound, then AND may not be commutative, since the order of listing the licenses may convey information about which license is inbound vs outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point already.

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

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard









Re: Commutativity of SPDX expressions

J Lovejoy
 

Hi Richard,

Annex D explains the order of precedence for the operators and use of parentheses. https://spdx.github.io/spdx-spec/SPDX-license-expressions/

I admit, I find the use of parentheses easier to understand overall (than relying on remembering the order of precedence).

I’m not sure it explicitly states that "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT” but I think that’s kind of implicit, no?

I also think this entire annex could use a re-write to make it a bit more user-friendly (on the topic of improving documentation…)

Jilayne

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

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard






Re: Commutativity of SPDX expressions

Warner Losh
 

Please define "INBOUND" and "OUTBOUND" licenses. None of the open source licenses indexed by SPDX grant permission to relicense the derived work, so any work including them either is solely the original license, or an AND of the project's license and the original license (to the extent the project creates a derived work). This is a clear case for "AND" where both licenses must be complied with. SPDX expressions do not have additional , secondary meanings, like what is the preferred license, what license do we accept changes for this derived work under, etc. All those secondary meanings would, if any, would need to be spelled out explicitly by the project wishing for them to apply for that project. For example, if a project takes MIT licensed code and creates a derived work they wish to license as GPL, they must list the license as GPL AND MIT because their desire to license under the GPL does not override the MIT license nor the IP of the original author. To say that the GPL is a proper-superset of the MIT license would be taking a legal position that's more aggressive than has been taken in the past, and I don't think that the SPDX project wants to be in the position of creating a matrix that says what is a superset of what so you can 'reduce' the complexity of the SPDX-License-Expression using some set of rules.

As for "AND": IThe standard says the following:

'If required to simultaneously comply with two or more licenses, use the conjunctive binary "AND"..."

Since each license is given equal weight in this construct, I'd say that AND is commutative where A AND B == B AND A. The standard has no verbage to the contrary to suggest one is controlling when there's a conflict, for example. Nor any of the other problems that might result from them being non-commutative. The standard is not explicit that it is commutative, but common usage for AND is. In the absence of a more specific definition, common usage would dictate interpretation should this be litigated. I'll let the better legal minds here, though, chime in as to whether or not the SPDX standard, as written, would need any correction to its language to address this potential ambiguity.

Warner


On Sun, Jul 17, 2022 at 1:18 PM McCoy Smith <mccoy@...> wrote:
At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs outbound, then AND may not be commutative, since the order of listing the licenses may convey information about which license is inbound vs outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point already.

> On Jul 17, 2022, at 11:22 AM, Richard Fontana <rfontana@...> wrote:
>
> I'm working on some draft documentation for Fedora around use of SPDX
> expressions in RPM spec file License: fields. I was surprised to
> apparently not see anything in the SPDX spec that says that the AND
> and OR operators are commutative. I want to assert that the expression
> "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
> SPDX spec actually take no position on this?
>
> Richard
>
>
>
>
>
>






Re: Commutativity of SPDX expressions

McCoy Smith
 

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs outbound, then AND may not be commutative, since the order of listing the licenses may convey information about which license is inbound vs outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point already.

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

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard






Commutativity of SPDX expressions

Richard Fontana
 

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard


call Thursday

J Lovejoy
 

Hi all,

We have our regularly schedule call tomorrow/Thursday at noon US eastern time.

After a bit of a hiatus, we’ll get back to our usual order of business. Please have a look through the current issues if possible, prior to the call.


Thanks!
Jilayne


Re: [spdx] 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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

Warner Losh
 



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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith <mccoy@...>
 

No, that’s not really my issue. I believe the logical operators and the ability to designate file-level licenses in SPDX handle your situation.

I’m talking about using SPDX to provide a copy of the terms of a license which don’t apply, but which nevertheless must be provided per the license itself. As is required in BSD/MIT/Apache (as well as copyleft licenses, but that’s really not applicable to my circumstances since copyleft requires the license terms be provided, *and* be applied)

 

From: spdx@... <spdx@...> On Behalf Of Shawn Clark
Sent: Tuesday, July 5, 2022 10:48 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

I have spent a lot of time contemplating the question, but want to confirm I'm thinking about the same thing:

 

Are you talking about the nature of open source requiring (such as in a requirements.txt) other open source code/components that ultimately mean the terms of several licenses would apply to the top level software package (such as the total python package)? And how to include those identifiers in spdx, either as a requirement of the open source license, or as a pass-through of a license (such as lgpl/gpl)?

 

I have thoughts on the topic but wanted to confirm before I ramble on about it 😁 I may be off the rails here.

 

Cheers!

-Shawn Clark

Michigan Attorney, P79081

 

 

 

 

On Fri, Jul 1, 2022, 4: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.

 

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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith <mccoy@...>
 

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.

 

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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

Richard Fontana
 

McCoy's topic reminds me of a question I asked here some time ago:
https://lists.spdx.org/g/Spdx-legal/message/2706?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Ccomposite%2C20%2C2%2C0%2C68280619

I wasn't really satisfied with that discussion; I was left feeling
that in some situations (perhaps rare in practice, admittedly) there
is a loss of useful information when you replace a set of license
notice strata in a source file with a conjunctive expression in an
SPDX-License-Identifier: statement. McCoy's question seems to be a
little different though.

Richard

On Wed, Jul 6, 2022 at 10:29 AM Steve Winslow <swinslow@...> wrote:

If I'm following the discussion correctly, I'd agree with Warner here.

If I take code that I received under BSD-2-Clause and I redistribute it under MIT, I'm really redistributing it under MIT subject to the requirements of the original BSD-2-Clause license under which I received it. I'd say that BSD-2-Clause doesn't give me the right to "relicense" the code in the sense of eliminating the inbound requirements and applying a fully different license in its place.

Rather, BSD-2-Clause allows me to redistribute under different terms as long as I also comply with the BSD-2-Clause obligations; and the same would apply to any downstream recipient of the code. In SPDX license expression terms, I'd describe the resulting license as "MIT AND BSD-2-Clause". (And subject of course to Warner's very good point, about whether in any particular case you're using a sufficiently copyrightable amount of the BSD-2-Clause code such that you need a license under applicable copyright laws.)

In terms of how to express this in source code files: I could see a couple of different ways to do so:

1. You could just include a single comment header at the top of the file with "SPDX-License-Identifier: MIT AND BSD-2-Clause"

2. Or if you wanted to be more specific about the particular portions of the code, you could use "SPDX-License-Identifier: MIT" at the top of the file, and then Snippet Tags [0] with "SPDX-License-Identifier: BSD-2-Clause" within the specific marked snippet of code which is subject to that license.

Steve

[0] Newly added in SPDX 2.3; see https://github.com/spdx/spdx-spec/blob/development/v2.3/chapters/file-tags.md#h3-snippet-tags-format-

On Wed, Jul 6, 2022 at 10:08 AM Warner Losh <imp@...> wrote:



On Wed, Jul 6, 2022 at 5:48 AM McCoy Smith <mccoy@...> wrote:

No, that’s not really my issue. I believe the logical operators and the ability to designate file-level licenses in SPDX handle your situation.

I’m talking about using SPDX to provide a copy of the terms of a license which don’t apply, but which nevertheless must be provided per the license itself. As is required in BSD/MIT/Apache (as well as copyleft licenses, but that’s really not applicable to my circumstances since copyleft requires the license terms be provided, *and* be applied)

What makes you think they don't apply? If you have to reproduce the notice, the terms apply. You can't just take code and change the license without the permission of the copyright holders/owners/etc. As an author of BSD code, I for one would strongly and strenuously object to this sort of thing were it done to my code. Either you used enough code that the terms apply (you created a derived work and have to comply) or you didn't (you created a new enough work the terms do not apply and you don't need to comply). If it applies, it is an AND. If it doesn't apply, I'd say it's outside the scope of SPDX. There is no "provide the notice but doesn't comply" option that I'm aware of in copyright law.

So, I don't think legally there's this halfway thing that you are suggesting, but I'm going to let others on the list opine about that as I'm not an attorney. I've just been doing this for the last 30 years and have been FreeBSD's licensing expert for much of that time.

Warner



From: spdx@... <spdx@...> On Behalf Of Shawn Clark
Sent: Tuesday, July 5, 2022 10:48 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification



I have spent a lot of time contemplating the question, but want to confirm I'm thinking about the same thing:



Are you talking about the nature of open source requiring (such as in a requirements.txt) other open source code/components that ultimately mean the terms of several licenses would apply to the top level software package (such as the total python package)? And how to include those identifiers in spdx, either as a requirement of the open source license, or as a pass-through of a license (such as lgpl/gpl)?



I have thoughts on the topic but wanted to confirm before I ramble on about it 😁 I may be off the rails here.



Cheers!

-Shawn Clark

Michigan Attorney, P79081









On Fri, Jul 1, 2022, 4: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.



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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

Steve Winslow
 

If I'm following the discussion correctly, I'd agree with Warner here.

If I take code that I received under BSD-2-Clause and I redistribute it under MIT, I'm really redistributing it under MIT subject to the requirements of the original BSD-2-Clause license under which I received it. I'd say that BSD-2-Clause doesn't give me the right to "relicense" the code in the sense of eliminating the inbound requirements and applying a fully different license in its place.

Rather, BSD-2-Clause allows me to redistribute under different terms as long as I also comply with the BSD-2-Clause obligations; and the same would apply to any downstream recipient of the code. In SPDX license expression terms, I'd describe the resulting license as "MIT AND BSD-2-Clause". (And subject of course to Warner's very good point, about whether in any particular case you're using a sufficiently copyrightable amount of the BSD-2-Clause code such that you need a license under applicable copyright laws.)

In terms of how to express this in source code files: I could see a couple of different ways to do so:

1. You could just include a single comment header at the top of the file with "SPDX-License-Identifier: MIT AND BSD-2-Clause"

2. Or if you wanted to be more specific about the particular portions of the code, you could use "SPDX-License-Identifier: MIT" at the top of the file, and then Snippet Tags [0] with "SPDX-License-Identifier: BSD-2-Clause" within the specific marked snippet of code which is subject to that license.

Steve


On Wed, Jul 6, 2022 at 10:08 AM Warner Losh <imp@...> wrote:


On Wed, Jul 6, 2022 at 5:48 AM McCoy Smith <mccoy@...> wrote:

No, that’s not really my issue. I believe the logical operators and the ability to designate file-level licenses in SPDX handle your situation.

I’m talking about using SPDX to provide a copy of the terms of a license which don’t apply, but which nevertheless must be provided per the license itself. As is required in BSD/MIT/Apache (as well as copyleft licenses, but that’s really not applicable to my circumstances since copyleft requires the license terms be provided, *and* be applied)


What makes you think they don't apply? If you have to reproduce the notice, the terms apply. You can't just take code and change the license without the permission of the copyright holders/owners/etc. As an author of BSD code, I for one would strongly and strenuously object to this sort of thing were it done to my code. Either you used enough code that the terms apply (you created a derived work and have to comply) or you didn't (you created a new enough work the terms do not apply and you don't need to comply). If it applies, it is an AND. If it doesn't apply, I'd say it's outside the scope of SPDX. There is no "provide the notice but doesn't comply" option that I'm aware of in copyright law.

So, I don't think legally there's this halfway thing that you are suggesting, but I'm going to let others on the list opine about that as I'm not an attorney. I've just been doing this for the last 30 years and have been FreeBSD's licensing expert for much of that time.

Warner 

 

From: spdx@... <spdx@...> On Behalf Of Shawn Clark
Sent: Tuesday, July 5, 2022 10:48 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

I have spent a lot of time contemplating the question, but want to confirm I'm thinking about the same thing:

 

Are you talking about the nature of open source requiring (such as in a requirements.txt) other open source code/components that ultimately mean the terms of several licenses would apply to the top level software package (such as the total python package)? And how to include those identifiers in spdx, either as a requirement of the open source license, or as a pass-through of a license (such as lgpl/gpl)?

 

I have thoughts on the topic but wanted to confirm before I ramble on about it 😁 I may be off the rails here.

 

Cheers!

-Shawn Clark

Michigan Attorney, P79081

 

 

 

 

On Fri, Jul 1, 2022, 4: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.

 

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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

Warner Losh
 



On Wed, Jul 6, 2022 at 5:48 AM McCoy Smith <mccoy@...> wrote:

No, that’s not really my issue. I believe the logical operators and the ability to designate file-level licenses in SPDX handle your situation.

I’m talking about using SPDX to provide a copy of the terms of a license which don’t apply, but which nevertheless must be provided per the license itself. As is required in BSD/MIT/Apache (as well as copyleft licenses, but that’s really not applicable to my circumstances since copyleft requires the license terms be provided, *and* be applied)


What makes you think they don't apply? If you have to reproduce the notice, the terms apply. You can't just take code and change the license without the permission of the copyright holders/owners/etc. As an author of BSD code, I for one would strongly and strenuously object to this sort of thing were it done to my code. Either you used enough code that the terms apply (you created a derived work and have to comply) or you didn't (you created a new enough work the terms do not apply and you don't need to comply). If it applies, it is an AND. If it doesn't apply, I'd say it's outside the scope of SPDX. There is no "provide the notice but doesn't comply" option that I'm aware of in copyright law.

So, I don't think legally there's this halfway thing that you are suggesting, but I'm going to let others on the list opine about that as I'm not an attorney. I've just been doing this for the last 30 years and have been FreeBSD's licensing expert for much of that time.

Warner 

 

From: spdx@... <spdx@...> On Behalf Of Shawn Clark
Sent: Tuesday, July 5, 2022 10:48 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

 

I have spent a lot of time contemplating the question, but want to confirm I'm thinking about the same thing:

 

Are you talking about the nature of open source requiring (such as in a requirements.txt) other open source code/components that ultimately mean the terms of several licenses would apply to the top level software package (such as the total python package)? And how to include those identifiers in spdx, either as a requirement of the open source license, or as a pass-through of a license (such as lgpl/gpl)?

 

I have thoughts on the topic but wanted to confirm before I ramble on about it 😁 I may be off the rails here.

 

Cheers!

-Shawn Clark

Michigan Attorney, P79081

 

 

 

 

On Fri, Jul 1, 2022, 4: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.

 

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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

Shawn Clark
 

I have spent a lot of time contemplating the question, but want to confirm I'm thinking about the same thing:

Are you talking about the nature of open source requiring (such as in a requirements.txt) other open source code/components that ultimately mean the terms of several licenses would apply to the top level software package (such as the total python package)? And how to include those identifiers in spdx, either as a requirement of the open source license, or as a pass-through of a license (such as lgpl/gpl)?

I have thoughts on the topic but wanted to confirm before I ramble on about it 😁 I may be off the rails here.

Cheers!
-Shawn Clark
Michigan Attorney, P79081




On Fri, Jul 1, 2022, 4: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.

 

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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

Warner Losh
 



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: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

J Lovejoy
 

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?


Reminder - meeting Friday on License Namespaces policy

Steve Winslow
 

Greetings SPDX tech and legal teams,

 

A reminder we are continuing the license namespace policy discussions on this Friday, July 1, 2022, at the same time as the prior meetings (15:00 UTC, 11AM Eastern, 8AM Pacific).

 

https://meet.jit.si/SPDXLegalMeeting

 

We will focus this meeting on finalizing the "policies" for the namespace proposals, continuing the discussions where we left off two weeks ago. Minutes from the prior meeting are in the joint meetings minutes folder at https://github.com/spdx/meetings/blob/main/joint/2022-06-17.md.


Best,

Steve



Joint SPDX Tech / Legal call - namespaces

Gary O'Neall
 

Greetings all,

 

Below is information on the follow-up meetings regarding license namespaces.  Please mark your calendars if you are interested in attending – I will not be sending out any calendar invites.

 

I copied the minutes from our last call to the github repo: https://github.com/spdx/meetings/blob/main/joint/2022-06-17.md.  The policy discussion is captured in this Google doc: https://docs.google.com/document/d/1DU8oDW_DeGEkU8PQLdqp67HGwwTueCzjh02Y6OF1eQQ/edit#heading=h.neu95tojxpgj

 

One of the key decisions from the last meeting is that we will require registered DNS domains for the external license namespaces.

 

There’s still some work on remaining on the policy, so please feel free to continue the discussion through comments and suggestions in the Google Doc before the next meeting.

 

It’s been a bit of a challenge to schedule the follow-up meetings, so we’re going to change the order of the discussions based on availability of those leading the discussions.

 

We’ll have a call limited to the namespace syntax immediately following the tech team call on Tuesday (10:30 AM Pacific Time, 17:30 GMT 28 June 2022) led by Alexios.  Please review the current proposed syntaxes in the GitHub Pull Request: https://github.com/spdx/spdx-spec/pull/681

 

We will have a separate call to complete the policy discussions on Friday at the usual time (8:00 AM Pacific, 15:00 GMT 1 July 2022) led by the legal team (Steve and/or Jilayne).

 

Both meetings will just the JITSI coordinates:

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

If any policy decisions impact the syntax, we will revisit the syntax after the policy discussion on Friday.

 

Let me know if you have any questions or concerns with the follow-up meetings or agendas.


Thanks,
Gary

 

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

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: Fun with licenses

Sebastian Crane
 

Dear Karsten,

„the and any this you license software for that not use with may code such agreement other terms under are rights work your all from shall source including copyright provided will without its party conditions must which licensee notice version distribute licensed program licensor means damages copy original have otherwise section liability third subject information distribution warranties contributor product documentation applicable law data granted warranty but purpose limited limitation implied only public following modifications form services non covered works available make above free derivative has copies right patent permission agree file part laws used licence modified modify each extent apply“!

... are the top 100 English words used in license text (as far as the metaeffekt universe goes).
This would make the perfect libretto for a foss-themed opera!

Best wishes,

Sebastian

101 - 120 of 3281