|
Re: Specific SPDX identifier question I didn't see addressed in the specification
On Mon, Jul 11, 2022 at 10:03 AM McCoy Smith <mccoy@...> wrote:
Back to the original query: Here’s an example of what I was talking about, albeit inbound BSD outbound GPL
This one is simple: BSD AND GPL-mumble for those files that contain both BSD and GPL code.
Warner
I’m suggestion an SPDX tag for what was used there:
This file is based on work under the following copyright and permission notice:
On Jul 11, 2022, at 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. 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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
Back to the original query: Here’s an example of what I was talking about, albeit inbound BSD outbound GPL
I’m suggestion an SPDX tag for what was used there:
This file is based on work under the following copyright and permission notice:
On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=lexpan.law@...> wrote:
On Jul 11, 2022, at 7:58 AM, Warner Losh <imp@...> wrote: You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
I asked a SPDX specific question. You jumped in with your legal analysis unrelated to the question of whether there was an existing SPDX identifier or should there be a new one. I responded to your off-topic thoughts. That’s bullying? But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
You’ve expressed it’s not a good idea. Is that dispositive? Jilayne had some mechanical/procedural questions about the questions I asked. Don’t think anyone else has weighed in. If I know my mailing lists, not everyone hops in immediately with their thoughts on proposals or questions.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote: “The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.” You have a case citation for that?
Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder. Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple. 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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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. 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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
On Mon, Jul 11, 2022 at 8:24 AM McCoy Smith <mccoy@...> wrote:
Don’t think the mailing list is the right place for this debate. I’m certainly familiar with the BSD=copyleft argument. You’re welcome to hold that position yourself. If you’re involved with FreeBSD as their licensing manager, might I suggest that FreeBSD make explicit that they believe the BSD license to be copyleft?
You are right, this isn't the right place for this debate. I can't even parse what you are saying here. copyleft has no legal basis as a term, so I'm not at all sure what you are saying. You are also somewhat misrepresenting what I'm saying and being a bit of a bully about it.
But since nobody else thought it was a good idea, I think the notion in SPDX is effectively dead unless another use case surfaces that makes sense.
Warner
From: spdx@... <spdx@...> On Behalf Of Warner Losh
Sent: Monday, July 11, 2022 7:20 AM
To: spdx@...
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification On Mon, Jul 11, 2022 at 8:13 AM McCoy Smith <mccoy@...> wrote: “The concept you are talking about doesn't exist in law. You can only change the 'outbound' license if the 'inbound' license expressly allows it.” You have a case citation for that?
Do you have one that does or that refutes the theory that the copyright holder granted you the ability to do certain things, but not to change the license? Without that, you are redistributing copyrighted material without the permission of the copyright holder. Again, I'm not a lawyer, but I've never encountered this in the last 30 years of doing open source. Downstream additions with a new license always an 'AND' unless the original license granted otherwise. It's certainly not the 'mainstream' of how open source operates and also goes against the oft-expressed desire to keep SPDX relatively simple. 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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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?
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. 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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
“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.*” 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. 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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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/
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... 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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? 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?
|
|
|
FW: SPDX Thurs General Meeting Reminder
No special presentation this month, so meeting should go shorter than usual.
GENERAL MEETING
Meeting Time: Thurs, July 7,
8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html
Conf call dial-in:
Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting
To join by phone instead, tap this: +1.512.647.1431,,1310118349#
Looking for a different dial-in number?
See meeting dial-in numbers: https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting
If also dialing-in through a room phone, join without connecting to audio: https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true
Etherpad for minutes:
https://spdx.swinslow.net/p/spdx-general-minutes
Administrative Agenda
Attendance
Minutes Approval: Not yet posted in GitHub but included at the bottom here.
Steering Committee Update - Phil
Technical Team Report – Kate/Gary/Others
-
Specification and Profiles
-
Overview
-
Core
-
Legal
-
Integrity
-
Defects
-
Usage and Other Emerging
-
Tooling
Legal Team Report – Jilayne/Paul/Steve
Outreach/Website Team Report – Jack/Sebastian/Alexios
|
|
|
* Attendance: 28
|
|
|
|
* Lead by Phil Odence
|
|
|
|
* Minutes from last meeting approved.
|
|
|
|
|
|
|
|
## Steering Committee Update - Phil
|
|
|
|
* Governance updates - minor clarifications
|
|
|
|
* Starting work on a project management framework
|
|
|
|
* Team Leads trying out a kickoff form before formalizing anything
|
|
|
|
* Alexios selected as new co-lead for Outreach Team, joining Steering Committee in that capacity
|
|
|
|
|
|
|
|
## OpenSSF and White House Meeting - Kate
|
|
|
|
* Focus on SBOMs - looking to engage with SPDX community, particularly on Defects side + laser focus on security
|
|
|
|
* Early January 2022 - discussing security and SBOMs; many companies putting resources towards solving problems are OpenSSF members; discussion was
under Chatham House Rule, info present but not disclosing speaker / organization
|
|
|
|
* New meeting - included representatives from many organizations, including outside OpenSSF / LF
|
|
|
|
* Kate and William Bartholomew present and active in SBOM workstream
|
|
|
|
* Mobilization plan: https://openssf.org/oss-security-mobilization-plan/ - Stream 9, "SBOMs Everywhere"
|
|
|
|
* Stream 10 also relevant to SPDX
|
|
|
|
* Additionally a working group for package managers, with recurring meetings
|
|
|
|
* June 20 or later - will be meeting in Austin among SPDX, CycloneDX and others re: identifying key use cases; reach out to Kate if wanting to participate
in discussion
|
|
|
|
* Looking to find companies willing to invest in improving tooling, especially with going to 2.3 and 3.0; tools requested by community; improving documentation;
doing outreach
|
|
|
|
* CISA Federal Register notice: https://www.federalregister.gov/documents/2022/06/01/2022-11733/public-listening-sessions-on-advancing-sbom-technology-processes-and-practices
|
|
|
|
* RedHat readout from meeting: https://www.linkedin.com/posts/mark-bohannon-54b66a_red-hats-open-approach-to-vulnerability-activity-6931970156457840640-BrD8/?utm_source=linkedin_share&utm_medium=member_desktop_web
|
|
|
|
|
|
|
|
|
|
|
|
## Tech Team Report - Gary/Kate/Thomas
|
|
|
|
|
|
|
|
### Spec
|
|
|
|
* SPDX 2.2.2 has been released
|
|
|
|
* docs bugs have been resolved, and can be accessed at: https://spdx.github.io/spdx-spec/
|
|
|
|
* SPDX 2.3 is close to feature complete, we'll be declaring a release candidate in the next week, and generating ontologies for the tools to start
trying it out.
|
|
|
|
* Likely aiming to release in next couple of weeks
|
|
|
|
* Documented in spdx-spec GitHub repo re: remaining tasks and activities
|
|
|
|
* Only a couple items left impacting syntax of documents; hoping they'll be resolved this week, though can't commit b/c seeking consensus across multiple
teams and time zones
|
|
|
|
* Aiming to have a draft schema out w/in a week after consensus, to be available for review
|
|
|
|
* Tooling folks then to update tools in parallel
|
|
|
|
* A couple of big issues
_separate from_ those impacting the syntax: e.g. license namespaces, licenses and snippets; intending to be compatible with existing syntax, but want to document in spec if adopting
|
|
|
|
* SPDX 3.0 moving in parallel, revised model posted.
|
|
|
|
* William leading up core profile team effort
|
|
|
|
* Small list of outstanding items, will soon transition to documentation phase, moving from visual to written model
|
|
|
|
* Defects profile, canonicalisation, usage profile
|
|
|
|
* WG: AI BOM team meeting regularly, looking at defining how to define training data, data sets, etc., starting to work up minimal set of fields
|
|
|
|
* focused on how to represent models and training data for models
|
|
|
|
* WG: SPDX Implementers Group - meeting to discuss best practices around generating SPDX documents, meeting every other Wednesday
|
|
|
|
* WG: Build data - Brandon Lum heading up recurring meeting, Monday nights European time
|
|
|
|
* WG: Canonicalization - Meets on Friday, discussing the serializations for the 3.0 model.
|
|
|
|
* Namespace discussions, additional meeting with Friday.
|
|
|
|
* Desire to have working group meetings listed and calendar invites visible
|
|
|
|
* Sebastian - looking to update wiki in short term, https://wiki.spdx.org/
|
|
|
|
* Gary - currently discussed primarily on tech team list
|
|
|
|
* Jilayne - would it make sense to add meeting times to https://github.com/spdx/meetings -- main README
|
|
|
|
|
|
|
|
## Legal Team Report - Jilayne/Paul/Steve
|
|
|
|
* License List 3.17 released in May
|
|
|
|
* Focus currently on discussion of cross-team topics for spec - license namespaces, etc.
|
|
|
|
* Looking to get a bit more formalization on cross-team topics:
|
|
|
|
* avoid multiple conversations on separate calls, look to have joint calls where appropriate
|
|
|
|
* proposals for something significant and new: aim to be more disciplined in articulating what's being solved for, e.g. "problem statement" / "what
is this trying to achieve"; articulate how this fits into the mission of the project
|
|
|
|
* try to define the goals / problem statement before jumping to implementation
|
|
|
|
* Namespace discussion tomorrow - https://lists.spdx.org/g/Spdx-tech/message/4539; please read first before coming to meeting
|
|
|
|
|
|
|
|
## Outreach Team Report - Sebastian / Jack / Alexios
|
|
|
|
* GSOC
|
|
|
|
* 2 projects for this summer, now in the community bonding period
|
|
|
|
* communicate with participants
|
|
|
|
* Coding period starts next week
|
|
|
|
* Material progress on SPDX website rebuild, sneak peek on upcoming outreach team call
|
|
|
|
* Joshua Marpet working on additional outreach things
|
|
|
|
* Upcoming talks:
|
|
|
|
* Kate - upcoming RSA talk with Allen Friedman re: SBOMs and tooling, come by and say hi in person if you'll be there!
|
|
|
|
* Steve - Zephyr Developer Summit next week, SBOMs at build time
|
|
|
|
* Steve - OSPOCon / OSS NA later in June, SPDX License List
|
|
|
|
|
|
|
|
##Steering Committee
|
|
|
|
* No update
|
|
|
|
|
|
|
|
## Attendees
|
|
|
|
* David Edelsohn, IBM
|
|
|
|
* Kate Stewart, LF
|
|
|
|
* Jeff Buddington
|
|
|
|
* Gary O'Neall
|
|
|
|
* Alex Rybak, Revenera
|
|
|
|
* Dick Brooks, REA
|
|
|
|
* Alexios Zavras
|
|
|
|
* Rich Steenwyk, GE Healthcare
|
|
|
|
* Jeff Schutt
|
|
|
|
* Sebastian Crane
|
|
|
|
* Molly Menoni
|
|
|
|
* Phil Odence, Synopsys
|
|
|
|
* Steve Winslow, Boston Tech Law
|
|
|
|
* Jack Manbeck
|
|
|
|
* Yoshiyuki Ito
|
|
|
|
* Brad Goldring, GTC Law Group
|
|
|
|
* Andrew Jorgensen
|
|
|
|
* Michael Herzog
|
|
|
|
* Joshua Watt
|
|
|
|
* Rose Judge
|
|
|
|
* Sunil Jain
|
|
|
|
* Karsten Klein
|
|
|
|
* Mark Atwood, Amazon.com
|
|
|
|
* Tony Aiuto, Google
|
|
|
|
* Marc-Etienne Vargenau, Nokia
|
|
|
|
* VM Brasseur, Wipro
|
|
|
|
* Adrian Diglio, Microsoft
|
|
|
|
* Hector Fernandez, VMware
|
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
On Wed, Jul 6, 2022 at 5:48 AM McCoy Smith <mccoy@...> wrote:
No, that’s not really my issue. I believe the logical operators and the ability to designate file-level licenses in SPDX handle your situation. I’m talking about using SPDX to provide a copy of the terms of a license which don’t apply, but which nevertheless must be provided per the license itself. As is required in BSD/MIT/Apache (as well as copyleft licenses, but that’s really not applicable to my circumstances since copyleft requires the license terms be provided, *and* be applied)
What makes you think they don't apply? If you have to reproduce the notice, the terms apply. You can't just take code and change the license without the permission of the copyright holders/owners/etc. As an author of BSD code, I for one would strongly and strenuously object to this sort of thing were it done to my code. Either you used enough code that the terms apply (you created a derived work and have to comply) or you didn't (you created a new enough work the terms do not apply and you don't need to comply). If it applies, it is an AND. If it doesn't apply, I'd say it's outside the scope of SPDX. There is no "provide the notice but doesn't comply" option that I'm aware of in copyright law.
So, I don't think legally there's this halfway thing that you are suggesting, but I'm going to let others on the list opine about that as I'm not an attorney. I've just been doing this for the last 30 years and have been FreeBSD's licensing expert for much of that time.
Warner
From: spdx@... <spdx@...> On Behalf Of Shawn Clark
Sent: Tuesday, July 5, 2022 10:48 AM
To: spdx@...
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification I have spent a lot of time contemplating the question, but want to confirm I'm thinking about the same thing: Are you talking about the nature of open source requiring (such as in a requirements.txt) other open source code/components that ultimately mean the terms of several licenses would apply to the top level software package (such as the total python package)? And how to include those identifiers in spdx, either as a requirement of the open source license, or as a pass-through of a license (such as lgpl/gpl)? I have thoughts on the topic but wanted to confirm before I ramble on about it 😁 I may be off the rails here. 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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. 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? Jilayne On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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? Jilayne
On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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? Jilayne
On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote: I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: Specific SPDX identifier question I didn't see addressed in the specification
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,
On Jul 1, 2022, at 12:01 PM, McCoy Smith < mccoy@...> wrote:
I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier. Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to: - Preserve all existing IP notices (or in some cases, just copyright notices)
- Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT) or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
The rules around element 1 and SPDX are well-described. With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this): SPDX-License-Identifier: MIT [This file/package/project contains code originally licensed under:] SPDX-License-Identifier: BSD-2-Clause The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.
One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
Thoughts? Am I missing something?
|
|
|
Re: License Type for Commercial Components
#spdx
toggle quoted message
Show quoted text
Hi ,
What is the license type that needs be used in spdx for 3rd parties with proprietary licenses (e.g., Microsoft)?
Regards
Sandeep
|
|
|
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?
|
|
|
Re: Where to put issues for "getting started with SPDX" documentation?
I lean strongly toward `docs` as the repo name. It’s a standard and expected name for a repo that contains any sort of documentation, so people will be able to
find it in GitHub.
Yes, the spec officially qualifies as a document but that’s easy enough to link to rather than move (and it would make little sense to move it under a docs repo
anyway).
--V
From:
<spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
Reply to: "spdx@..." <spdx@...>
Date: Friday, June 24, 2022 at 07:52
To: "spdx@..." <spdx@...>
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?
CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
I agree something like help or getting started as a repo name. That way someone can just grab all of the getting started collaterals that may get generated over time: documents, examples, etc.,.
Jack
toggle quoted message
Show quoted text
From: spdx@... <spdx@...>
On Behalf Of Alexios Zavras
Sent: Friday, June 24, 2022 5:23 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] Where to put issues for "getting started with SPDX" documentation?
May I propose something like github.com/spdx/help since “docs” covers a lot more things (even the specification itself).
+1 on being a new, separate location.
From:
spdx@... <spdx@...>
On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Thursday, 23 June, 2022 20:46
To: spdx@...
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?
GitHub is a given, which is why we decided to start opening issues rather than just maintaining a file.
I’d prefer to have either a dedicated docs repo or a /docs folder in another appropriate repo, so we can do the docs in docusaurus or some other static site generator
type thing.
Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.
--V
VM (Vicky) Brasseur
Director, Senior Strategy Advisor
Open Source Program Office
Wipro Limited
⏰ Time Zone: Pacific/West Coast US
CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
Yes! I think this is a great idea. We’ve tried in the past to do this but could never get people “focused” on it. I agree its needed.
I vote to put it the list in GitHub. The wiki doesn’t seem to be used much anymore. I would create a repo for “getting started” collateral. Besides the questions we could add examples and other documents over
time. The someone can just grab it when they want to get started,
We do have a FAQ:
https://spdx.dev/faq/ that may have some good info as well if you have not seen it.
Jack Manbeck
From:
spdx@... <spdx@...>
On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s
really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier
to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t
know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--V
VM (Vicky) Brasseur
Director, Senior Strategy Advisor
Open Source Program Office
Wipro Limited
⏰ Time Zone: Pacific/West Coast US
'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information.
If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com'
Internal to Wipro
'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information.
If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com'
Internal to Wipro
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0,
www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you
should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments
for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'
Internal to Wipro
|
|
|
Re: Where to put issues for "getting started with SPDX" documentation?
I agree something like help or getting started as a repo name. That way someone can just grab all of the getting started collaterals that may get generated over time: documents, examples, etc.,.
Jack
toggle quoted message
Show quoted text
From: spdx@... <spdx@...> On Behalf Of
Alexios Zavras
Sent: Friday, June 24, 2022 5:23 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] Where to put issues for "getting started with SPDX" documentation?
May I propose something like github.com/spdx/help since “docs” covers a lot more things (even the specification itself).
+1 on being a new, separate location.
From: spdx@... <spdx@...>
On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Thursday, 23 June, 2022 20:46
To: spdx@...
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?
GitHub is a given, which is why we decided to start opening issues rather than just maintaining a file.
I’d prefer to have either a dedicated docs repo or a /docs folder in another appropriate repo, so we can do the docs in docusaurus or some other static site generator type thing.
Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.
--V
VM (Vicky) Brasseur
Director, Senior Strategy Advisor
Open Source Program Office
Wipro Limited
⏰ Time Zone: Pacific/West Coast US
CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
Yes! I think this is a great idea. We’ve tried in the past to do this but could never get people “focused” on it. I agree its needed.
I vote to put it the list in GitHub. The wiki doesn’t seem to be used much anymore. I would create a repo for “getting started” collateral. Besides the questions we could add examples and other documents over
time. The someone can just grab it when they want to get started,
We do have a FAQ:
https://spdx.dev/faq/ that may have some good info as well if you have not seen it.
Jack Manbeck
From:
spdx@... <spdx@...>
On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?
Howdy, team.
In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently
it’s really hard for new people to show up and use/generate/understand SPDX, but we can (with time) fix that.
We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it
easier to keep track of them.
The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I
don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?
So what do y’all think? Where should these issues go for now?
--V
VM (Vicky) Brasseur
Director, Senior Strategy Advisor
Open Source Program Office
Wipro Limited
⏰ Time Zone: Pacific/West Coast US
'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information.
If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com'
Internal to Wipro
'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended
recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this
email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com'
Internal to Wipro
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
|
|
|
