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 (#1557): https://lists.spdx.org/g/spdx/message/1557 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]] -=-=-=-=-=-=-=-=-=-=-=-
