On Mon, Jul 11, 2022 at 10:03 AM 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/
>

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 8:49 AM, McCoy Smith via lists.spdx.org <mccoy=
> [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:
>>
>>    1. Preserve all existing IP notices (or in some cases, just copyright
>>    notices)
>>    2. 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 (#1562): https://lists.spdx.org/g/spdx/message/1562
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]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to