Thanks Bradley. Your point re: other licenses building in a de facto “or later” clause versus the GPL family of licenses leaving the choice to the copyright holders is exactly the thing I wanted to confirm and is also (I think, but need to do more thinking on this) why the GPL family may indeed need it’s own unique treatment.
Deprecating “GPL-2.0” for use of “GPL-2.0-only”, along with the use of the existing “GPL-2.0+” is what I’m leaning towards, but again, we need to vet all options, think through all possible pros and cons, and ensure a clear path (with limited pain) for existing users before coming to a conclusion. I think putting this all on a wiki page will be helpful also so that when we reach a decision, we have a better record of what our thinking was and why we ended up the way we did (and avoids searching old email archives ;) I feel pretty confident we can get there. We have a great community around SPDX generally and I really can’t say enough good things about how active and engaged our legal team has been (even when I’m admittedly a bit “absent”, literally or figuratively). Jilayne SPDX Legal Team co-lead [email protected] > On May 26, 2017, at 11:54 AM, Bradley M. Kuhn <[email protected]> wrote: > > Jilyane, I'm glad work is proceeding on this. > > J Lovejoy wrote today: >> In any case, as Kate has already stated - we were just talking about this >> the other day and thinking through some paths to get to a point of using: >> "GPL-2.0-only" as the short identifier for when one means exactly that. > > As I mentioned, on the spdx-tech list yesterday, folks may also want to > review the original thread making this proposal back in October 2013: > https://lists.spdx.org/pipermail/spdx-legal/2013-October/000941.html > https://lists.spdx.org/pipermail/spdx-tech/2013-October/001965.html > >> GPL does not exist in a vacuum, so we need to make sure that either what’s >> good for the geese is also good for the gander (other licenses, use of >> SPDX, etc.); or we consider a proposal that treats the GPL family of >> licenses unique if that’s warranted. > > There's a related point that's often purposely obscured by GPL's critics and > is relevant to this problem that SPDX is now facing. GPL is the *only* > family of copyleft licenses that permit "-only" decisions by licensors using > the canonical text of the license. > > In other words, other copylefts (such as MPL, CC BY-SA, CDDL, EPL) all > require licensors to accept a de-facto "or-later" clause, which allows the > license steward (e.g., Mozilla, Creative Commons, Oracle, Eclipse Foundation) > to unilaterally relicense all works under their license text without any > additional permissions from licensors. By default, all non-GPL copylefts are > "-or-later" (in GPL's parlance). The FSF left the choice of { "-only", > "-or-later" } where it belongs: with the copyright holders. > > Giving more freedom to users (as FSF is wont to do) admittedly sometimes > complicates the world, and I think that's why the SPDX License List drafters > surely legitimately feel that this situation makes everything complicated. > I'm sympathetic to that challenge, which is why I de-lurk when this issue > comes up to offer assistance from my expertise in this area. > > And, I'm thankful that the SPDX team is now facing the issue head-on. I > understand given the timing it has become tricky because of the "GPL-2.0" > Identifier has in the intervening years since 2013 become used in the field > (... but, as David points out in the recent spdx-tech thread, it's often used > incorrectly). > > While I guess the License List team will receive is a radical proposal, I > suggest deprecating the "GPL-2.0" Identifier entirely (as was done the GPL > exception-based ones) and creating new "-or-later" and "-only" versions of > the Identifier to replace it going forward in future versions of SPDX's > License List. > >> In any case, this is a discussion that needs to start with the legal team, >> as the steward of the SPDX License List, so I’d like to ask that we >> move/keep the discussion there for the time being. > > The original 2013 thread that I mention above was sent to both spdx-tech and > spdx-legal. > -- > -- bkuhn > _______________________________________________ > Spdx-legal mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-legal _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
