Hi all, Again, this conversation belongs on the SPDX-legal mailing list, not the SPDX-general list. I tried to remedy this early on, but somehow SPDX-legal got dropped and it went back to SPDX-general.
Please be sure to check you are a member of the relevant mailing lists here: https://lists.spdx.org/groups <https://lists.spdx.org/groups> I’m happy to re-start this thread or raise it as a topic on the next SPDX legal team call, but either way a new thread or conversation needs to be started to avoid unnecessary traffic on the SPDX-general list. Thanks, Jilayne SPDX legal team co-lead Steering Committee member > On Jul 11, 2022, at 11:17 AM, McCoy Smith <mc...@lexpan.law> wrote: > > > >> On Jul 11, 2022, at 9:51 AM, Alexios Zavras <alexios.zav...@intel.com> wrote: >> >> I think our understanding until now is that the package should have >> "License-A AND License-B", to denote the presence of these licenses. But >> conversely, this license expression should NOT be understood to mean that >> "everything in here is under this expression (combination of licenses)". >> >> Richard's example of taking the license of a set and applying it to every >> single item shows the error in this approach. > Yes that’s it. I think AND alone could be (and might widely be) misconstrued > as to what state is actually being represented. > One solution is for people and tools to correctly understand the SPDX tags > and operators. > The other is to convey more information with those tags and operators. > Which is best I don’t know, depends on how well people and tools are > interpreting the conveyed information. > This is a bit orthogonal from my initial inquiry, but perhaps my inquiry > tests the limits of “just use AND” as the solution? >> -- zvr >> >> -----Original Message----- >> From: s...@lists.spdx.org <s...@lists.spdx.org> On Behalf Of McCoy Smith >> Sent: Monday, 11 July, 2022 19:43 >> To: s...@lists.spdx.org >> Subject: Re: [spdx] Specific SPDX identifier question I didn't see addressed >> in the specification >> >> At this risk of opening up a giant can of worms: >> Does logical AND for SPDX make sense without more information? Even if a >> group of files clearly designate a single license at file level, and project >> identifies each of those licenses with logical AND at project level, you >> still can have misunderstandings if file level is not interrogated. >> >>> On Jul 11, 2022, at 9:21 AM, Richard Fontana <rfont...@redhat.com> 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 <rfont...@redhat.com> >>>>> 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 <mc...@lexpan.law> wrote: >>>>> Back to the original query: >>>>> Here’s an example of what I was talking about, albeit inbound BSD >>>>> outbound GPL >>>>> https://lwn.net/Articles/247806/ >>>>> I’m suggestion an SPDX tag for what was used there: >>>>> This file is based on work under the following copyright and permission >>>>> notice: >>>>>> On Jul 11, 2022, at 8:49 AM, McCoy Smith via lists.spdx.org >>>>>> <mccoy=lexpan....@lists.spdx.org> wrote: >>>>> >>>>>> On Jul 11, 2022, at 7:58 AM, Warner Losh <i...@bsdimp.com> 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: s...@lists.spdx.org <s...@lists.spdx.org> On Behalf Of Warner >>>>>> Losh >>>>>> Sent: Monday, July 11, 2022 7:20 AM >>>>>> To: s...@lists.spdx.org >>>>>> 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 <mc...@lexpan.law> 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: s...@lists.spdx.org <s...@lists.spdx.org> On Behalf Of Warner >>>>>> Losh >>>>>> Sent: Monday, July 11, 2022 7:07 AM >>>>>> To: s...@lists.spdx.org >>>>>> Cc: SPDX-legal <spdx-legal@lists.spdx.org> >>>>>> 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 <mc...@lexpan.law> 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: s...@lists.spdx.org <s...@lists.spdx.org> On Behalf Of Warner >>>>>> Losh >>>>>> Sent: Friday, July 1, 2022 2:11 PM >>>>>> To: s...@lists.spdx.org >>>>>> Cc: SPDX-legal <spdx-legal@lists.spdx.org> >>>>>> 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 <mc...@lexpan.law> 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: s...@lists.spdx.org <s...@lists.spdx.org> On Behalf Of J >>>>>> Lovejoy >>>>>> Sent: Friday, July 1, 2022 1:11 PM >>>>>> To: SPDX-legal <spdx-legal@lists.spdx.org> >>>>>> 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 <mc...@lexpan.law> wrote: >>>>>> I didn’t see this particular topic addressed in the specification >>>>>> (although I’m happy to be correcedt if I missed it), so I thought I’d >>>>>> post and see whether there is a solution that’s commonly used, or if >>>>>> there’s room for a new identifier. >>>>>> Virtually all so-called “permissive” licenses permit the recipient of >>>>>> code to license out under different terms, as long as all the >>>>>> requirements of the in-bound license are met. In almost all of these >>>>>> permissive licenses those requirement boil down to: >>>>>> Preserve all existing IP notices (or in some cases, just copyright >>>>>> notices) Provide a copy of the license (or something to that >>>>>> effect: retaining “this permission notice” (ICU/Unicode/MIT) or >>>>>> “this list of conditions” (BSD) or providing “a copy of this >>>>>> License” (Apache 2.0)) >>>>>> The rules around element 1 and SPDX are well-described. >>>>>> With regard to element 2, a fully-compliant but informative notice when >>>>>> there is a change from the in-bound to the out-bound license would look >>>>>> something like this (with the square bracketed part being an example of >>>>>> a way to say this): >>>>>> SPDX-License-Identifier: MIT >>>>>> [This file/package/project contains code originally licensed >>>>>> under:] >>>>>> SPDX-License-Identifier: BSD-2-Clause >>>>>> The point being to express that the outbound license is MIT, but in >>>>>> order to fully comply with the requirements of BSD-2-Clause, one must >>>>>> retain “ this list of conditions and the following disclaimer” which >>>>>> including a copy of BSD-2-Clause accomplishes. Without the square >>>>>> bracketed statement above, it seems confusing as to what the license is >>>>>> (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause. >>>>>> One way to do this I suppose is to use the LicenseComment: field to >>>>>> include this information, but it seems to me that this is enough of a >>>>>> common situation that there ought to be something more specific to >>>>>> address this situation. >>>>>> Thoughts? Am I missing something? >> >> >> >> >> >> Intel Deutschland GmbH >> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany >> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> >> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva >> Chairperson of the Supervisory Board: Nicole Lau >> Registered Office: Munich >> Commercial Register: Amtsgericht Muenchen HRB 186928 >> >> >> > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1570): https://lists.spdx.org/g/spdx/message/1570 Mute This Topic: https://lists.spdx.org/mt/92118120/21656 Group Owner: spdx+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
