Discussion:
how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva
2007-06-21 09:39:07 UTC
Permalink
Here's an idea that just occurred to me, after all the discussions
about motivations, tit-for-tat, authors' wishes and all.

If GPLv3 were to have a clause that permitted combination/linking with
code under GPLv2, this wouldn't be enough for GPLv3 projects to use
Linux code, and it wouldn't be enough for Linux code to use GPLv3
projects. That's because GPLv2 would still demand all code to be
licensed under GPLv2, and GPLv3 wouldn't permit this.

However, if GPLv3 had a permission to combine/link with code under
GPLv2, *and* Linux (and any other projects interested in mutual
compatibility) introduced an additional permission to combine/link
with code under GPLv3 (or even GPLv3+, constrained by some condition
if you will), then:

- the kernel Linux could use code from GPLv3 projects

- GPLv3 projects could use code from Linux

- each copyright holder would still get to enforce the terms s/he
chose for his/her own code

Does this sound like something that would make sense for your
community, so as to maintain/increase cooperation between authors who
love GPLv2 and those who love defense for freedom, while respecting
each author's not-always-compatible wishes?

In other words, does it even make sense for the FSF to consider
introducing such a provision in GPLv3, that AFAICT, by itself, would
have no effect whatsoever, since an additional permission would be
needed for the GPLv2 side?


If you were to permit compatibility with GPLv3+ (rather than GPLv3),
would you constrain it? Would something like:

as long as the later version grants each licensee the same
permissions as GPLv2, except for constraining permissions that would
enable one licensee to deny other licensees the exercise of the
permissions granted by both licenses

do, subject to translation to proper legalese (if that's at all
possible)?


Do you know of any other communities that are like-minded with you,
that are sticking with GPLv2, that I could poll about interest in such
a provision in GPLv3?


Thanks, and sorry for taking your attention away from coding one more
time. I hope you find it worth it this time.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
jimmy bahuleyan
2007-06-21 11:35:44 UTC
Permalink
Post by Alexandre Oliva
Here's an idea that just occurred to me, after all the discussions
about motivations, tit-for-tat, authors' wishes and all.
If GPLv3 were to have a clause that permitted combination/linking with
code under GPLv2, this wouldn't be enough for GPLv3 projects to use
Linux code, and it wouldn't be enough for Linux code to use GPLv3
projects. That's because GPLv2 would still demand all code to be
licensed under GPLv2, and GPLv3 wouldn't permit this.
However, if GPLv3 had a permission to combine/link with code under
GPLv2, *and* Linux (and any other projects interested in mutual
compatibility) introduced an additional permission to combine/link
with code under GPLv3 (or even GPLv3+, constrained by some condition
There, that right there, wouldn't it again require a 'nod' from all
those who have contributed to the kernel (because at the time they did,
the license was GPLv2 without any additions)?

-jb
--
Tact is the art of making a point without making an enemy.
Alexandre Oliva
2007-06-21 17:53:04 UTC
Permalink
Post by jimmy bahuleyan
There, that right there, wouldn't it again require a 'nod' from all
those who have contributed to the kernel (because at the time they did,
the license was GPLv2 without any additions)?
That's my understanding, yes, but IANAL.


Similarly, any GPLv2 and GPLv3 projects that wish to cooperate with
each other could introduce mutual additional permissions in the way I
suggested, even if neither GPLv2 nor GPLv3 themselves make such
provisions. This is a decision that copyright holders can make, in
very much the same way that they can make their decisions as to
permitting relicensing under newer versions of the GPL, or even older
versions of the GPL.


BTW, I should probably have made clear that, as usual, I was speaking
my own mind, not speaking on behalf of FSFLA or Red Hat, with whom I'm
associated, and certainly not on behalf of FSF, with whom I'm not
associated. Just in case this wasn't clear yet ;-)
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
d***@lang.hm
2007-06-21 18:00:40 UTC
Permalink
Post by Alexandre Oliva
Post by jimmy bahuleyan
There, that right there, wouldn't it again require a 'nod' from all
those who have contributed to the kernel (because at the time they did,
the license was GPLv2 without any additions)?
That's my understanding, yes, but IANAL.
Similarly, any GPLv2 and GPLv3 projects that wish to cooperate with
each other could introduce mutual additional permissions in the way I
suggested, even if neither GPLv2 nor GPLv3 themselves make such
provisions. This is a decision that copyright holders can make, in
very much the same way that they can make their decisions as to
permitting relicensing under newer versions of the GPL, or even older
versions of the GPL.
BTW, I should probably have made clear that, as usual, I was speaking
my own mind, not speaking on behalf of FSFLA or Red Hat, with whom I'm
associated, and certainly not on behalf of FSF, with whom I'm not
associated. Just in case this wasn't clear yet ;-)
this is standard dual-licensing, not special just becouse both licenses
are GPL versions

and for people who don't like one or the other of the two licenses this
will not be acceptable becouse it would allow someone else to take their
work, modify it a bit, and release the result only under the license that
they don't like

GPL+exceptions is the same thing, you are releasing it under multiple
licenses, GPL, GPL + 1st exception, GPL + 2nd exception, GPL + 1st and 2nd
exception, etc

one of the big problems that people don't realize is that if it takes
GPLv3+ exception to be compatible with the apache license it's technicaly
not legal to later strip that exception off becouse the result isn't
compatible with the apache license, even if the GPL license says that you
can.

after the code has passed through a couple hands it will be hard for
someone receiving the code to know this.

I expect a lot of flamage, and bad blood, and possibly a little legal
action between opensource projects over the next several years as people
realize their code is being hijacked this way.

David Lang
Alexandre Oliva
2007-06-21 20:02:52 UTC
Permalink
Post by d***@lang.hm
this is standard dual-licensing, not special just becouse both
licenses are GPL versions
No, seriously, it's not, it's quite different.

If you dual-license your code between GPLv2 and GPLv3, I could combine
your code with code under GPLv3, distribute it, and if anyone tivoized
your code, I might be able to enforce the anti-tivoization provisions
against the tivoizer.

With a mere permission to combine, I can only enforce these provisions
over my own code.


I see that, for tivoization, the end result is very much the same as
an all-GPL, although the tivoizer still has the option of removing the
GPLv3 code and hoping GPLv2's implicit anti-tivoization provisions are
not enforced. This would be just undoing the additional cooperation
that this additional permission would have provided.

However, for other GPLv3 defenses, it would make a difference. For
example, on the patent licenses that are implicit in GPLv2 and
explicit in GPLv3.
Post by d***@lang.hm
and for people who don't like one or the other of the two licenses
this will not be acceptable becouse it would allow someone else to
take their work, modify it a bit, and release the result only under
the license that they don't like
Which is precisely why I suggested this approach of permission to
combine, rather than as dual licensing. Because then nobody could do
what you say.
Post by d***@lang.hm
one of the big problems that people don't realize is that if it takes
GPLv3+ exception to be compatible with the apache license
For the record, it doesn't, GPLv3 is going to be compatible with the
apache 2.0 license, no additional exceptions needed.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
David Schwartz
2007-06-21 21:13:36 UTC
Permalink
Post by Alexandre Oliva
With a mere permission to combine, I can only enforce these provisions
over my own code.
What does "my own code" mean when we're talking about derivative works and
code in the codebase influencing the design of later code? Code from one
module gets copied into another. Code in one module influences the design of
code in the kernel. New files are added with pieces from multiple other
files.

Are you seriously suggesting that the Linux kernel source contain code with
various different licenses with an obligation for those who work on the
source too keep track of which licenses apply to bits of code when they work
on them? That seems impossible as a practical matter.

All the kernel code not being available under the same license is a short
term problem. Over time, the code will get so combined and interwoven that
the intersection of all permitted licenses would soon apply to effectively
the entire kernel.

This would be no different from adopting GPLv3. Unless, that is, GPLv3 makes
itself compatible with GPlv2. In which case it would be no different from
doing nothing at all. (Except for all the pain it would cause as people
diligently try to figure out what licenses apply to their code and try not
to borrow code from parts of the kernel that have a different license from
the parts they are working on.)

DS
Alexandre Oliva
2007-06-21 23:37:46 UTC
Permalink
Post by David Schwartz
Are you seriously suggesting that the Linux kernel source contain code with
various different licenses
It already does. All the way from permissive Free Software licenses
to GPLv2-incompatible non-Free Software licenses.
Post by David Schwartz
Over time, the code will get so combined and interwoven that the
intersection of all permitted licenses would soon apply to
effectively the entire kernel.
If you don't keep things clearly separate, yes.

I was honestly thinking more along the lines of ZFS as a separate
driver than about your bringing GPLv3 code into the core of the
kernel.

But then, it would be your call either way.

This option of mutual cooperation wouldn't work for either party if
you're not willing to cooperate, and that's what I believe makes it
fair.

Now, if you guys can't recognize a goodwill gesture when you see one,
and prefer to live in the paranoid beliefs that "those evil FSFers are
trying to force me into a situation in which they'll then be able to
steal my code", that's really up to you. Don't try to shift the blame
of your decisions onto the FSF.

One thing is missing the spirit of the GPL and using it to serve a
different purpose, without realizing it doesn't provide you with
exactly what you want (tivoization, for example); another completely
different is to try to put it as FSF's fault that clarifications and
amendments are desirable to ensure the ability for authors to enforce
the intent of the GPL.
Post by David Schwartz
Unless, that is, GPLv3 makes itself compatible with GPlv2.
Hey, but that was precisely what I was suggesting! Except that it
wasn't with GPLv2 alone, because this doesn't work. Each copyleft
license insists that it be *the* license. So, in order to be able to
combine two copyleft licenses, you need mutual compatibility
provisions in both. Which is what I was proposing.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
David Schwartz
2007-06-22 00:31:15 UTC
Permalink
Post by Alexandre Oliva
Now, if you guys can't recognize a goodwill gesture when you see one,
and prefer to live in the paranoid beliefs that "those evil FSFers are
trying to force me into a situation in which they'll then be able to
steal my code", that's really up to you. Don't try to shift the blame
of your decisions onto the FSF.
Hey, but that was precisely what I was suggesting! Except that it
wasn't with GPLv2 alone, because this doesn't work. Each copyleft
license insists that it be *the* license. So, in order to be able to
combine two copyleft licenses, you need mutual compatibility
provisions in both. Which is what I was proposing.
It's this simple, those who chose the GPLv2 for Linux and their
contributions to it don't want people to create derivative works of their
works that can't be Tivoized. They see this as a feature, and it's the
reason they're not willing to adopt GPLv3. (They want people who receive
derivative works of their programs to get all the GPLv2 rights, not just
some of them.)

I don't see any compromise that means that people don't get all the rights
to Linux that the GPLv2 grants as working.

DS
Alexandre Oliva
2007-06-22 01:00:22 UTC
Permalink
Post by David Schwartz
It's this simple, those who chose the GPLv2 for Linux and their
contributions to it don't want people to create derivative works of their
works that can't be Tivoized.
Do you agree that if there's any single contributor who thinks it
can't be tivoized, and he manages his opinion to prevail in court
against a copyright holder, then it can't? That this is the same
privilege to veto additional permissions that Al Viro has just
claimed?

http://lkml.org/lkml/2007/6/13/293
http://lkml.org/lkml/2007/6/13/354
http://lkml.org/lkml/2007/6/14/117
http://lkml.org/lkml/2007/6/14/432
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Al Viro
2007-06-22 01:34:17 UTC
Permalink
Post by Alexandre Oliva
Do you agree that if there's any single contributor who thinks it
can't be tivoized, and he manages his opinion to prevail in court
against a copyright holder, then it can't? That this is the same
privilege to veto additional permissions that Al Viro has just
claimed?
You know, I'm rapidly losing any respect for your integrity. The only
"privelege" claimed is that of not relicensing one's contributions.
_You_ are perfectly welcome to allow distribution of your code under
whatever license you happen to like. So is anybody else (provided that
they separate their code from that of other contributors). I cannot
do that to your code. Neither can Linus.

If Alan sues some company for doing things violating in his opinion his
copyright on some of his code *and* wins it, then it's likely to simplify
later cases of that kind, provided that situation is similar enough to
make the legal arguments used in the first case apply in the later one.

If Joe Random Wanker takes your code (in gcc, kernel, whatever) and starts
distributing it in violation of conditions set in your copyright *and*
you sue him *and* win (which is bloody likely), then further cases of that
kind get somewhat easier to win. Not much, actually, since there's already
a whole lot of precedents already.

What really gets me is that you know it. And you know that just about
everyone here knows it. Yet you keep playing with rather pathetic
attempts of innuendo and misdirection, when it's bloody obvious that
you won't even get a PR win out of the entire mess you've been sustaining
for about a week already (seriously, count postings in these threads).

The first law of holes: when you are in one, stop digging...
Theodore Tso
2007-06-22 04:19:49 UTC
Permalink
Post by Al Viro
What really gets me is that you know it. And you know that just about
everyone here knows it. Yet you keep playing with rather pathetic
attempts of innuendo and misdirection, when it's bloody obvious that
you won't even get a PR win out of the entire mess you've been sustaining
for about a week already (seriously, count postings in these threads).
I'm not sure Alexandre realizes it, but by his carrying on and on and
on with his really poorly reasoned arguments (I may disagree with
Eben's positions, but he's a much more reasonable debator and advocate
for the FSF's positions), Mr. Oliva, Latin America Board Member and
Free Software Evangelist, has probably made it made it much more
*unlikely* that the Linux kernel will ever go GPLv3.

About a week and half ago, Linus was saying he was a pragmatist and if
there was a good enough reason (such as if Solaris adopting GPLv3 and
there being aufficiently interesting technology that it would be worth
the code exchange), there was a chance that he might be for it. But
Alexandre has been so annoying and so obtuse, that people's positions
have hardened to the point where I doubt kernel developers would be
willing to go for at this point. Something that went from being
merely extremely unlikely has become "practically impossible".
Post by Al Viro
The first law of holes: when you are in one, stop digging...
Indeed.

Another law of negotiations --- don't goad people into hardening their
positions; it helps neither you nor your interests.

- Ted
Alexandre Oliva
2007-06-22 06:00:30 UTC
Permalink