> -----Original Message-----
> From: Bradley M. Kuhn <bkuhn@xxxxxxx>
>
> [ Full Disclosure: I've written parts of copyleft-next, have been involved
> with the initiative basically since its inception, and obviously I like the
> license a lot. Take my comments with the recommend dose NaCl granules
> those facts require. ]
>
> Greg KH wrote:
> > Any chance you wish to just change the license of these files, given that
> > you are the only one that has tried to use it for kernel code?
>
> There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in
> Linux. Many corporate copyright holders have well documented strong reasons
> for wanting that. (Those policy goals and the analysis behind them, I find
> problematic and sometimes outright wrong, but nonetheless it's their right to
> license their copyrights that way, and the license *is* GPLv2-only
> compatible, as is Luis'!).
>
> I assume that you're not asking those companies to relicense to pure
> GPLv2-only. While those companies perhaps faced early resistance when they
> began their dual-licensing-in-upstream endeavor, it was ultimately accepted
> and that opens the door, IMO, to accepting any form of GPL-compatible
> dual-licensing upstream. There is no cogent argument that I can see that
> says “(GPLv2-only|{2,3}-Clause-BSD) is so special that it should be
> grandfathered in over other forms of dual licensing”.
>
> (Ironically, IIRC, (then acting on behalf of Qualcomm/Atheros, Luis — the
> person proposing the (GPLv2-only|copyleft-next) dual-licensing *now* was a
> champion of upstreaming (GPLv2-only|{2,3}-Clause-BSD) code years ago before
> it was a wide and common practice.)
>
> > As a follow-up to this, I do not want to see your "test_sysfs.c" module as
> > a dual-licensed file, as that makes no sense whatsoever. It is directly
> > testing GPL-v2-only code, so the attempt to dual license it makes no sense
> > to me. How could anyone take that code and do anything with it under the
> > copyleft-next license only? And where would that happen?
>
> But, it's a valid compatible license, so there is no harm. And, see below,
> regarding policy reasons …
>
> > I understand the appeal of copyleft-next in that it resolves many of the
> > "grey" areas around gplv2, but given that no one is rushing to advise us to
> > relicense all of the kernel with this thing,
>
> Consider me to be the first to advise that! I realize it's a tough thing to
> do, but every great adventure to solve a big problem starts with a first
> step! I further realize it's a non-starter, but please don't say again no
> one has advised you such!
>
> BTW, the only reason I didn't advise it because I know a top-level license
> change away from straight, no-exceptions/no-additional-permissions GPLv2-only
> is a non-starter for the Linux community. (Great, BTW, that you've stuck so
> firmly to your steadfast plan on this!)
>
> Greg continued:
> > there is no need to encourage the spread of it given the added complexity
> > and confusion that adding another license to our mix can only cause.
> Relatedly, Christoph asked (footnote mine):
> >> Why do we need a random weirdo [0] license in the kernel tree? Is there
> >> any benefit?
>
> To be frank, we in the copyleft-next community were very excited to learn
> that such dual-licensed code had been added to upstream Linux, back when it
> was many years ago. It's a vote of confidence from a well-known developer
> who really is excited about our policy goals. FOSS licensing isn't just
> about simplicity and cleanliness. Like budgets, which seem dry topics on
> surface, they are actual moral documents that make a statement about the
> philosophy and aspirations for software freedom by the licensor. Of course,
> we all know it's completely symbolic to dual license
> (GPLv2-only|copyleft-next), just like it's purely symbolic to dual license
> (GPLv2-only|2-Clause-BSD) upstream [1].
It's not at all purely symbolic to dual license (GPLv2-only|2-Clause-BSD).
That dual-licensing has allowed the interchange of a lot of code between
the BSD Unixes and Linux, that otherwise would not have happened.
It's very much in the spirit of Linus' tit-for-tat compact to allow the BSD Unixes
to benefit from improvements made to code that originated there and made
it's way to Linux.
-- Tim
> But it makes a statement that I
> think is a good one.
>
> Finally, while GPLv2-only compatibility has been a mainstay so far in
> copyleft-next drafting, it's not clear to me that we can keep that
> compatibility forever and reach copyleft-next's policy goals. There's been
> no discussion of this yet, but it's certainly in the realm of possibility.
> If GPLv2-incompatibility ultimately happens in future copyleft-next versions,
> having dual-licensed code out there will be a huge help as it will assure
> that code can forever be used both on GPLv2-only and copyleft-next sides of
> future single-license-project equations.
>
> Thanks for listening; of course it's the sole prerogative for the copyright
> holder to decide whether to change the license of their code or not, and I
> hope that they don't bow to pressure, just as Qualcomm wouldn't bow to
> pressure if you started asking them to stop dual licensing all their upstream
> Linux code under BSD licenses.
>
> [0] BTW, Christoph, I remember when I started in FOSS in the early 1990s,
> everyone called the GPL a “random weirdo license”. The incumbent always
> seems not as random and weirdo as the challenger.
>
> [1] There is the argument that 2-Clause-BSD has fewer requirements than
> GPLv2-only; however, that's not an argument to release the code
> *upstream* that way, it's an argument to release a separate version under
> 2-Clause-BSD.
>
> --
> Bradley M. Kuhn - he/him
>
> Pls. support the charity where I work, Software Freedom Conservancy:
> https://sfconservancy.org/supporter/
