Specific SPDX identifier question I didn't see addressed in the specification
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?
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-ClauseThe 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?
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.
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?
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?
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)
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?
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:
- 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?
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?
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/
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?
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.*”
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?
“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?
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.*”
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?
“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?
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.*”
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?
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?
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.*”
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?
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?
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.*”
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?
On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote:
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?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.
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.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
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.*”
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?
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: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?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.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.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
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.*”
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?
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: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?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.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.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
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.*”
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?
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
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?
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.
RichardOn 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 specificationOn 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 specificationOn 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 specificationOn 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,
JilayneOn 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?
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
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?
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.
RichardOn 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.
RichardOn 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?