At this risk of opening up a giant can of worms: Does logical AND for SPDX make sense without more information? Even if a group of files clearly designate a single license at file level, and project identifies each of those licenses with logical AND at project level, you still can have misunderstandings if file level is not interrogated.
> On Jul 11, 2022, at 9:21 AM, Richard Fontana <[email protected]> wrote: > > If you take the patch referenced in the LWN article, you could rewrite that > as: > > SPDX-License-Identifier: GPL-2.0-or-later AND ISC > > But then subsequent modifications of the file are going to be assumed > to be licensed under both GPLv2 and ISC, whereas it is likely the > subsequent modifier conceptualized their changes as just being GPLv2. > > This reminds me: I've recently been informed of a project that started > using SPDX-License-Identifier: and this has led to a complicated issue > around a desired license change because it appears as though many > contributions to the project were inadvertently made under a > conjunction of two licenses, which was the result of putting a > conjunctive SPDX-License-Identifier statement in a README file. I > don't have the case handy but it was something like, some source files > were BSD-3-Clause, some were Apache-2.0, someone then helpfully put > SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0 in a README file, > and then new source files started mechanically including > SPDX-License-Identifier: BSD-3-Clause AND Apache-2.0. > > Richard > >> On Mon, Jul 11, 2022 at 12:12 PM Richard Fontana <[email protected]> wrote: >> >> Ah, that is exactly the issue I was asking about a few years ago. The >> response on this list was that an SPDX-License-Identifier: statement >> consisting of an "AND" expression was good enough as an alternative. >> But my view at the time was that this entailed a loss of information >> -- you lose the idea that the GPL is in some sense the overarching or >> dominant license of some set of code with some subsidiary elements >> under distinct licenses. >> >> I'm not sure what I think now. I will say, the norm SFLC was trying to >> establish in the wake of the ath5k affair never really caught on. >> >> The 'snippet' solution isn't really practical in many cases because >> you won't often be able to precisely identify the boundaries of the >> snippet. >> >> Richard >> >>> On Mon, Jul 11, 2022 at 12:06 PM McCoy Smith <[email protected]> wrote: >>> >>> Back to the original query: >>> Here’s an example of what I was talking about, albeit inbound BSD outbound >>> GPL >>> >>> https://lwn.net/Articles/247806/ >>> >>> I’m suggestion an SPDX tag for what was used there: >>> >>> This file is based on work under the following copyright and permission >>> notice: >>> >>> >>>> On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org >>>> <[email protected]> wrote: >>> >>> >>> >>> >>>> On Jul 11, 2022, at 7:58 AM, Warner Losh <[email protected]> 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: [email protected] <[email protected]> On Behalf Of Warner Losh >>>> Sent: Monday, July 11, 2022 7:20 AM >>>> To: [email protected] >>>> 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 <[email protected]> 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: [email protected] <[email protected]> On Behalf Of Warner Losh >>>> Sent: Monday, July 11, 2022 7:07 AM >>>> To: [email protected] >>>> Cc: SPDX-legal <[email protected]> >>>> 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 <[email protected]> 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: [email protected] <[email protected]> On Behalf Of Warner Losh >>>> Sent: Friday, July 1, 2022 2:11 PM >>>> To: [email protected] >>>> Cc: SPDX-legal <[email protected]> >>>> 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 <[email protected]> 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: [email protected] <[email protected]> On Behalf Of J Lovejoy >>>> Sent: Friday, July 1, 2022 1:11 PM >>>> To: SPDX-legal <[email protected]> >>>> Subject: Re: [spdx] Specific SPDX identifier question I didn't see >>>> addressed in the specification >>>> >>>> >>>> >>>> Hi McCoy! >>>> >>>> >>>> >>>> I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that >>>> is the right place for this discussion. >>>> >>>> >>>> >>>> Where is this question coming up in terms of context? That is, are you >>>> thinking in the context of an SPDX document and capturing the licensing >>>> info for a file that is under MIT originally but then redistributed under >>>> BSD-2-Clause? Or are you thinking in the context of using an SPDX license >>>> identifiers in the source files? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jilayne >>>> >>>> >>>> >>>> On Jul 1, 2022, at 12:01 PM, McCoy Smith <[email protected]> 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? >>>> >>>> >>> >>> > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1566): https://lists.spdx.org/g/spdx/message/1566 Mute This Topic: https://lists.spdx.org/mt/92118120/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
