Questions about copyleft-next

[Josh Triplett]

On Tue, Jul 01, 2025 at 10:44:27PM -0400, Richard Fontana wrote:
> On Tue, Jul 1, 2025 at 2:00 PM secureblueadmin
> <secureblueadmin at proton.me> wrote:
> 
> > I think something got mixed up here. I was making two separate and unrelated points.
> >
> > Point 1: Why have an explicit inbound list as opposed to allowing any license approved by the OSI and FSF?
> 
> I don't remember, but I remember that various approaches were
> experimented with for dealing with license compatibility (both the
> general or inbound compatibility issue or whatever people started
> calling it way back in the 2010s, and the special problem of GPL
> compatibility).
> 
> In the latest "Draft" there's an appendix with an enumeration of
> "Compatible Licenses", including a subset consisting of "GPL-Family
> Licenses". Whereas it appears that the approach taken in 0.3.1 was
> something reminiscent of what (in a completely different context) I
> once called the "Rule of Two" (that is, an inbound-compatible license
> has to be both FSF-free and OSI-approved). That Rule of Two was
> actually meant to describe the Software Freedom Conservancy's policy
> on licensing of member projects, if I'm remembering correctly. So
> undoubtedly that was the inspiration.
> 
> I think this, like pretty much everything else IMO, has to be
> completely rethought. :)

Having a list of compatible inbound licenses seems reasonable for a
license that's regularly kept up to date. And it seems safer than
deferring that list to external organizations.

> It's possible you're right. There was a general assumption for the
> entire (active) history of drafting of copyleft-next (if I remember
> correctly) that GPL compatibility was *so* important as a pragmatic
> goal that all other policies of the license could be subverted in
> favor of that goal, although I don't think I or anyone else put it
> that way explicitly. I think that assumption is probably questionable
> now, but I don't know.
[...]
> probably makes sense just to give up on GPL compatibility (which,
> after all, you could achieve in other ways, like dual-licensing).

I personally think it's critically important to keep inbound (and
*outbound*) GPL compatibility, in order to limit the degree to which a
new copyleft license bifurcates the ecosystem. It doesn't matter how
good the new license is; if using it means my users can't incorporate
GPLed software, I'd stick with the GPL (and not bother dual licensing).
And that's especially true if the new license's primary benefit is just
simplification; dual-licensing eliminates the benefit of simplicity.