spdx@lists.spdx.org | 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

Show quoted text

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?

McCoy Smith

#1548

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.

Show quoted text

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?

J Lovejoy

#1547

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

Show quoted text

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?

McCoy Smith

#1545

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?