On Mon, Jul 11, 2022 at 8:24 AM McCoy Smith <[email protected]> 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:* [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 (#1559): https://lists.spdx.org/g/spdx/message/1559
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