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}
Alexandre Oliva wrote:
> 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:
>
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.
On Jun 21, 2007, jimmy bahuleyan <[email protected]> wrote:
> 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}
On Thu, 21 Jun 2007, Alexandre Oliva wrote:
> On Jun 21, 2007, jimmy bahuleyan <[email protected]> wrote:
>
>> 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
On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
> 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
... and inherit GPLv3 additional restrictions. No.
> - GPLv3 projects could use code from Linux
Oh, rapture! How could one object against such a glorious outcome?
> - each copyright holder would still get to enforce the terms s/he
> chose for his/her own code
... except for that pesky "no added restrictions" part, but hey, who
cares?
> 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
... because it's For The Benefit Of User Freedoms!!!
No. Permission denied. And I don't know of any suckers who would buy that
and hadn't been already hooked by FSF peddlers already.
If somebody wants to dual-license their code, they can do it just fine.
If somebody wants to dual-license *others* code, they can go and play
with themselves until they reach RMS-level clarity of vision.
Alexandre Oliva wrote:
> 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:
Wouldn't that defeat the entire purpose of the GPLv3? Couldn't I take any
GPLv3 program, combine it with a few lines of Linux code, and Tivoize the
result?
The fundamental problem is this: Any proposed mutually compatible license
must either permit or prohibit Tivoization. If it prohibits it, then it's no
different from changing the kernel license to GPLv3. If it allows it, then
it's no different from the GPLv2 and it would be suicide to the whole
purpose of the GPLv3 for it to be compatible with it.
DS
On Jun 21, 2007, "David Schwartz" <[email protected]> wrote:
> Alexandre Oliva wrote:
>> 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:
> Wouldn't that defeat the entire purpose of the GPLv3? Couldn't I take any
> GPLv3 program, combine it with a few lines of Linux code, and Tivoize the
> result?
No. This is not permission to relicense. This is permission to
combine. Each author still gets to enforce the terms of her own code.
So a tivoizer would have to take out the code licensed under the
GPLv3, and use only the code that permits tivoization. Same as today,
but without the possibility of cooperation for licensees who don't
tivoize.
Sorry if this wasn't obvious, it was for me.
--
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}
On Jun 21, 2007, [email protected] wrote:
> 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.
> 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.
> 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}
On Jun 21, 2007, Al Viro <[email protected]> wrote:
> On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
>> - the kernel Linux could use code from GPLv3 projects
> ... and inherit GPLv3 additional restrictions. No.
Respecting the wishes of the author of that code. Are you suggesting
they should not be respected?
Anyone who's not happy about it can still take that portion out,
unless you accept changes that make this nearly impossible, which I
suppose you wouldn't given how strongly you feel about this.
Without this provision, you wouldn't be able to use the code in the
first place, so I don't perceive any loss for anyone. Do you?
>> - GPLv3 projects could use code from Linux
> Oh, rapture! How could one object against such a glorious outcome?
Exactly ;-)
Two-way cooperation. I'm told that's good. I was told this was even
desirable.
I can see that one-way cooperation could be perceived as unfair, even
if permissions granted by GPLv3 are all granted by GPLv2 as well.
>> - each copyright holder would still get to enforce the terms s/he
>> chose for his/her own code
> ... except for that pesky "no added restrictions" part, but hey, who
> cares?
But see, nobody would be adding restrictions to *your* code. You'd
only be enabling mutual cooperation with projects whose authors
weren't happy about restrictions some licensees could impose on others
(including the authors themselves).
>> 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
> ... because it's For The Benefit Of User Freedoms!!!
It is either way. Do you deny that tivoization also benefits one
user/licensee? And in detriment of others, while at that?
> No. Permission denied.
Your opinion is duly noted. Thanks.
> If somebody wants to dual-license *others* code,
This is not about dual licensing at all, and this is not about others
code. This is a decision you would have to make in order to enable
cooperation between projects.
If you don't want to make this decision, that's fine. Nobody can be
forced to cooperate. This works in both directions.
Don't try to frame those who want to respect and defend users'
freedoms as uncooperative. This is *your* decision, and your decision
alone.
--
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}
On 21/06/07, Alexandre Oliva <[email protected]> wrote:
[snip]
>
> 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 ;-)
>
Given your signature below, no, that's not at all clear :
> --
> Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
> FSF Latin America Board Member http://www.fsfla.org/
If you don't speak for the FSF then adverticing the fact that you are
a FSF board member seems a little odd. I also fail to see (or at least
wonder at) how a board member of the FSF can state that he's not
associated with the FSF... hmm, the mind boggles..
> Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Same thing for the RedHat bit here, along with posting from a
@redhat.com email addr.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> > I take any
> > GPLv3 program, combine it with a few lines of Linux code, and
> > Tivoize the
> > result?
> No. This is not permission to relicense. This is permission to
> combine. Each author still gets to enforce the terms of her own code.
This makes no sense. We are not talking mere aggregation here, we are
talking developmental convergence. If I wrote some code that was in the
Linux kernel, how can I enforce the terms of my code (guaranteed write to
Tivoize) in the derivative work that it becomes mixed with?
> So a tivoizer would have to take out the code licensed under the
> GPLv3, and use only the code that permits tivoization. Same as today,
> but without the possibility of cooperation for licensees who don't
> tivoize.
I am baffled how this could possibly work. You understand that the GPLv2
specifically guarantees that any derivative work will be Tivoizable and the
people who chose the GPLv2 specifically want it that way?
If I chose the GPLv2 over the GPLv3 as a conscious choice, that means I want
people to be able to Tivoize any derivative work made from my work that is
distributed.
DS
Alexandre Oliva wrote:
> 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
On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Al Viro <[email protected]> wrote:
>
> > On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
>
> >> - the kernel Linux could use code from GPLv3 projects
>
> > ... and inherit GPLv3 additional restrictions. No.
>
> Respecting the wishes of the author of that code. Are you suggesting
> they should not be respected?
Do piss off. You know full well what I'm saying.
> Anyone who's not happy about it can still take that portion out,
> unless you accept changes that make this nearly impossible, which I
> suppose you wouldn't given how strongly you feel about this.
Oh, right. "Anyone who doesn't like proprietary code in the tree
can just remove it, what's the big deal?" analog. Sorry, doesn't work.
> Without this provision, you wouldn't be able to use the code in the
> first place, so I don't perceive any loss for anyone. Do you?
Replace GPLv3 with proprietary in your argument and look in archives.
That had come up quite a few time in such form.
> >> - GPLv3 projects could use code from Linux
>
> > Oh, rapture! How could one object against such a glorious outcome?
>
> Exactly ;-)
Look up "sarcasm".
>
> Two-way cooperation. I'm told that's good. I was told this was even
> desirable.
Again, replace v3 with proprietary and reread your argument.
> I can see that one-way cooperation could be perceived as unfair, even
> if permissions granted by GPLv3 are all granted by GPLv2 as well.
... but not the other way round. So in effect we get a change of kernel
license, GPLv3 people *do* *not* get any license changes on their projects.
And you are saying that it's not one-way?
> > ... except for that pesky "no added restrictions" part, but hey, who
> > cares?
>
> But see, nobody would be adding restrictions to *your* code.
Liar. I'm sorry, but I do _not_ believe that you are honestly clueless
about GPL to that extent, especially given your claims of participation
of v3 development. What you are saying is "but your code will be still
available under GPLv2". Yes, it will. So it will be if e.g. SCO pulls
it into proprietary codebase. And you know damn well that this _is_
against the intentions of the license. Besides, changes to code should
be available under the same license. The first change in v3 project
affecting both imported v2 code and native v3 one will create a big problem.
> > ... because it's For The Benefit Of User Freedoms!!!
>
> It is either way. Do you deny that tivoization also benefits one
> user/licensee? And in detriment of others, while at that?
You know, we have another wanker here starting another thread from
hell - one about allowing stable driver ABI, to make the life of
proprietary modules more convenient. The funny thing is, it's _also_
said to be for the benefit of users. I.e. it's basically an equivalent
of "Will somebody think of chiiildrun!!!?!?!?"
> > No. Permission denied.
>
> Your opinion is duly noted. Thanks.
It's not an opinion. It's a lack of permission to distribute GPLv2 code
under conditions violating its license.
> > If somebody wants to dual-license *others* code,
>
> This is not about dual licensing at all, and this is not about others
> code. This is a decision you would have to make in order to enable
> cooperation between projects.
>
> If you don't want to make this decision, that's fine. Nobody can be
> forced to cooperate. This works in both directions.
>
> Don't try to frame those who want to respect and defend users'
> freedoms as uncooperative. This is *your* decision, and your decision
> alone.
Ah. Got it. Nice spin. "Your license doesn't allow to put your code
under the license we want, you are mean and uncooperative! Giiiimmeeee!!!
Or be condemned as a Bad Person and an Enemy of Freedom"
On Jun 21, 2007, "Jesper Juhl" <[email protected]> wrote:
> On 21/06/07, Alexandre Oliva <[email protected]> wrote:
> [snip]
>>
>> 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 ;-)
> Given your signature below, no, that's not at all clear :
Do you assume I speak for the GNU project and for University of
Campinas as well, just because my signature implies that I am somehow
associated with them?
>> FSF Latin America Board Member http://www.fsfla.org/
> If you don't speak for the FSF then adverticing the fact that you are
> a FSF board member seems a little odd.
What's odd is your assuming that I'm an FSF board member. Especially
when there's a URL just next to it that explains what FSFLA is, and
how it's not the FSF, but rather one of four members of the network of
FSFs.
> I also fail to see (or at least wonder at) how a board member of the
> FSF can state that he's not associated with the FSF... hmm, the mind
> boggles..
Yeah, it's really hard to clarify broken assumptions and jumping to
conclusions.
>> Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
> Same thing for the RedHat bit here, along with posting from a
> @redhat.com email addr.
Why would this convey the impression that I'm speaking on behalf of
Red Hat, tell me. It doesn't even say I'm president, CEO, PR manager,
press contact or any such thing...
If I posted from my ISP e-mail address, would you assume I was
speaking for the ISP?
--
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}
On 22/06/07, Alexandre Oliva <[email protected]> wrote:
> On Jun 21, 2007, "Jesper Juhl" <[email protected]> wrote:
>
> > On 21/06/07, Alexandre Oliva <[email protected]> wrote:
> > [snip]
> >>
> >> 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 ;-)
>
> > Given your signature below, no, that's not at all clear :
>
> Do you assume I speak for the GNU project and for University of
> Campinas as well, just because my signature implies that I am somehow
> associated with them?
>
My point was that your signature does indicate your affiliation with a
lot of different organizations/companies, so unless you explicitly
state that you are not speaking on behalf of them it's easy to assume
you do.
> >> FSF Latin America Board Member http://www.fsfla.org/
>
> > If you don't speak for the FSF then adverticing the fact that you are
> > a FSF board member seems a little odd.
>
> What's odd is your assuming that I'm an FSF board member. Especially
> when there's a URL just next to it that explains what FSFLA is, and
> how it's not the FSF, but rather one of four members of the network of
> FSFs.
>
Quoting from that web page: "FSF Latin America is a sister
organization of Free Software Foundation (FSF)"
So when your signature states that you are a "FSF Latin America Board
Member" and FSFLA is a "sister organization of Free Software
Foundation (FSF)" that, at least to me, implies some association with
the FSF.
> > I also fail to see (or at least wonder at) how a board member of the
> > FSF can state that he's not associated with the FSF... hmm, the mind
> > boggles..
>
> Yeah, it's really hard to clarify broken assumptions and jumping to
> conclusions.
>
See above.
> >> Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
>
> > Same thing for the RedHat bit here, along with posting from a
> > @redhat.com email addr.
>
> Why would this convey the impression that I'm speaking on behalf of
> Red Hat, tell me. It doesn't even say I'm president, CEO, PR manager,
> press contact or any such thing...
>
No, it does not, but it's easy to mistake a post by someone posting
from a company email and including that company in their signature for
speaking for that company.
> If I posted from my ISP e-mail address, would you assume I was
> speaking for the ISP?
>
Of course not. The @redhat.com email is just one more thing, that
added together with the signature could lead people to believe you are
speaking on their behalf.
You were the one who brought up the " I should probably have made
clear that, as usual, I was speaking my own mind, not speaking on
behalf of ..." bit. I'm simply replying to you that indeed it is not
clear for whom you speak with all that info in your signature and the
email address you post from.
Especially the FSF association seems likely given that most of your
emails seem heavily influenced by the FSF cool aid.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Jun 21, 2007, "David Schwartz" <[email protected]> wrote:
>> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
>> > I take any
>> > GPLv3 program, combine it with a few lines of Linux code, and
>> > Tivoize the
>> > result?
>> No. This is not permission to relicense. This is permission to
>> combine. Each author still gets to enforce the terms of her own code.
> This makes no sense. We are not talking mere aggregation here, we are
> talking developmental convergence. If I wrote some code that was in the
> Linux kernel, how can I enforce the terms of my code (guaranteed write to
> Tivoize) in the derivative work that it becomes mixed with?
In just the same way you'd enforce it today: with help from a lawyer
who understands these issues that you clearly don't understand.
>> So a tivoizer would have to take out the code licensed under the
>> GPLv3, and use only the code that permits tivoization. Same as today,
>> but without the possibility of cooperation for licensees who don't
>> tivoize.
> I am baffled how this could possibly work. You understand that the GPLv2
> specifically guarantees that any derivative work will be Tivoizable and the
> people who chose the GPLv2 specifically want it that way?
Yes. And the GPLv2 code would remain that way.
If GPLv3 had this provision I suggested, and you wanted to cooperate
with some other project that offered GPLv3 drivers, then you could use
them by adding the mutual-cooperation provision I suggested.
Of course you're free to not want to cooperate with anyone else who
doesn't share your opinion. That's your call.
> If I chose the GPLv2 over the GPLv3 as a conscious choice, that means I want
> people to be able to Tivoize any derivative work made from my work that is
> distributed.
This provision was not intended to prevent anyone from tivoizing your
work or derived works thereof. It was only intended to enable you to
use code from GPLv3 projects as long as these GPLv3 projects could
also use your code. Mutual cooperation, as opposed to no cooperation
whatsoever.
I *think* lawyers would probably recommend you to keep code under
different licenses in separate files, like you already do with code
licensed under GPLv2-compatible licenses.
I *think* that, with this pair of mutual cooperation provisions, you
could even use code licensed under the Apache 2.0 license. And
OpenSolaris drivers, if it's licensed under GPLv3.
And you wouldn't be departing from your intent to enable people to
tivoize your code, which you currently choose not to enforce even
though GPLv2 might very well enable you to; you could keep on
cooperating with people who understand GPLv2 doesn't permit
tivoization, and you'd be able to establish mutual cooperation with
people who choose a license that makes this point clear.
It's not like anyone can safely tivoize devices with GPLv2 already, so
refusing to cooperate with GPLv3 on these grounds buys you nothing.
It is only a public statement of refusal to cooperate, with you are
entitled to make, even if it comes off as silly because you chose a
license that already contains the provisions for "complete
corresponding source code" and "no further restrictions on the
exercise of the rights granted by the license" that tivoizers fail to
comply with.
At which point one gets to wonder why you chose this license in the
first place, if it doesn't give you what you want.
FWIW, all of my (very few) contributions to Linux were made with the
intent of not permitting tivoization or any form of restricting users
freedoms. I guess this means, from now on, you'd stop accepting my
contributions and take out whatever contributions I've made, since
otherwise I'd be able to enforce them against tivoizers. And what's
more, I could still use your code in my GPLv2 projects, and enforce
that against tivoizers, and there's nothing you can do to stop me.
So what exactly are you trying to accomplish by pretending that mutual
compatibility with GPLv3 would set you back in any way?
--
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}
On Jun 21, 2007, "David Schwartz" <[email protected]> wrote:
> 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.
> 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.
> 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}
On Jun 21, 2007, "Jesper Juhl" <[email protected]> wrote:
> My point was that your signature does indicate your affiliation with a
> lot of different organizations/companies, so unless you explicitly
> state that you are not speaking on behalf of them it's easy to assume
> you do.
And then, I did that a number of times in the other recent long
thread, whenever I made statements that could be construed as FSF's
opinion. Now, this time I missed it, added the clarification just in
case, and you pick on me. Puhlease!
> Quoting from that web page: "FSF Latin America is a sister
> organization of Free Software Foundation (FSF)"
> So when your signature states that you are a "FSF Latin America Board
> Member" and FSFLA is a "sister organization of Free Software
> Foundation (FSF)" that, at least to me, implies some association with
> the FSF.
How does that make me an FSF Board Member, as you claimed at first?
Yes, I'm a co-founder of an independent organization that, for sharing
the same goals as other FSFs, was welcomed into the global network of
FSFes.
That we have the same goals does not imply I'm in any way associated
with the FSF. Your faulty assumption and your attempts to paper over
your mistake won't make it true.
> No, it does not, but it's easy to mistake a post by someone posting
> from a company email and including that company in their signature for
> speaking for that company.
Indeed, compiler engineers are often the bearers of company's voices.
Not!
> I'm simply replying to you that indeed it is not clear for whom you
> speak with all that info in your signature and the email address you
> post from.
Understood. Thanks for doing that so nicely.
I'm glad it's clear now.
--
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}
Alexandre Oliva wrote:
> 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
On Jun 21, 2007, Al Viro <[email protected]> wrote:
> On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote:
>> Anyone who's not happy about it can still take that portion out,
>> unless you accept changes that make this nearly impossible, which I
>> suppose you wouldn't given how strongly you feel about this.
> Oh, right. "Anyone who doesn't like proprietary code in the tree
> can just remove it, what's the big deal?" analog. Sorry, doesn't work.
Well, you do have proprietary code in Linux, and it's definitely not
easy to take it all out, so, point.
However, the difference that you appear to be missing is that when you
get code under GPLv3, or under this hypothetical combination of GPLv2
and GPLv3 code, everyone who received the combination could still do
everything the GPL says they could do: run the code for any purpose,
study it, adapt it, modify it and distribute it, with or without
modifications, under the same conditions, to the recipient, without
imposing any further restrictions.
The only thing that changes is that, for GPLv2, there's a possibility
that some licensees might be able to get away not permitting other
licensees to do the things the license you chose permits them to do,
using tricks that have been invented or that became matter of new laws
since GPLv2 was published.
But this doesn't mean GPLv2 unambiguously permits this behavior; that
you want it to doesn't make it so for all contributors. Just like you
have the right to veto any additional permissions on Linux, so can
other contributors. And unambiguous permission to tivoize is an
additional permission, just like permission to combine code with GPLv3
is an additional permission.
Heck, even the requirement to provide source code under GPLv1 and
GPLv2 is a clarification along the same lines of the new provisions of
GPLv3. Denying access to the source code is a restriction on the
exercise of the rights granted by the license. So it's implied. But
since some people might not see it that way, it's spelled out in full.
Same deal with patents in GPLv2, and all the other new provisions with
GPLv3. What makes them incompatible is not that they impose new
restrictions (they really don't), it's that they remove any doubts
about that.
>> I can see that one-way cooperation could be perceived as unfair, even
>> if permissions granted by GPLv3 are all granted by GPLv2 as well.
> ... but not the other way round. So in effect we get a change of kernel
> license, GPLv3 people *do* *not* get any license changes on their projects.
> And you are saying that it's not one-way?
GPLv3 people *do* get license changes too. This can be accomplished
with additional permissions on both licenses with the current GPLv3
draft. I'm proposing that this backward compatibility could be a
built-in feature of GPLv3.
As to whether this has any effects on GPLv3 projects, it does. It
weakens the legal defenses for the entire project, in as much as the
wholes in GPLv2 might still be exploited.
>> > ... except for that pesky "no added restrictions" part, but hey, who
>> > cares?
>> But see, nobody would be adding restrictions to *your* code.
> What you are saying is "but your code will be still
> available under GPLv2".
No, I'm saying far more than this obvious conclusion, on which you
apparently stopped thinking.
I'm saying the project that uses it won't get as strong legal defenses
as it would get if it were under GPLv3. So, yes, both sides sacrifice
some of their stances in order to enable mutual cooperation.
Sure, if you don't want to do that, that's your call. But don't try
to frame it as if there was something wrong or unfair about it.
> So it will be if e.g. SCO pulls it into proprietary codebase.
Except that then I won't be able to enjoy any of the rights that you
meant me to enjoy as to the code that SCO distributes.
Whereas with combination of GPLv2 with GPLv3, every licensee still
gets all of the same freedoms respected. The difference is only as to
how much they can deny other licensees the freedoms you meant them to
get.
And if someone cares about using your code to deny other licensees
freedoms, they still can. Depending on how much you intermingled your
code with code that doesn't want to permit this, it will be more or
less difficult to do, but it can be done.
> The first change in v3 project affecting both imported v2 code and
> native v3 one will create a big problem.
Why? The licenses permit combination/linking, each portion remains
under the same license as their authors meant.
>> > ... because it's For The Benefit Of User Freedoms!!!
>> It is either way. Do you deny that tivoization also benefits one
>> user/licensee? And in detriment of others, while at that?
> You know, we have another wanker here starting another thread from
> hell - one about allowing stable driver ABI, to make the life of
> proprietary modules more convenient.
And it's indeed the same issue: placing the interests of a few
licensees over others'.
That you decide differently in the two cases just goes to show how
consistent your opinion is.
>> > No. Permission denied.
>>
>> Your opinion is duly noted. Thanks.
> It's not an opinion. It's a lack of permission to distribute GPLv2 code
> under conditions violating its license.
Your whatever you want to call it is duly noted.
> Nice spin. "Your license doesn't allow to put your code under the
> license we want, you are mean and uncooperative! Giiiimmeeee!!! Or
> be condemned as a Bad Person and an Enemy of Freedom"
It's not nice to be on the other end of such silly accusations, is it?
--
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}
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[email protected]> wrote:
>
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> > Tivoize the
> >> > result?
>
> >> No. This is not permission to relicense. This is permission to
> >> combine. Each author still gets to enforce the terms of her own code.
>
> > This makes no sense. We are not talking mere aggregation here, we are
> > talking developmental convergence. If I wrote some code that was in the
> > Linux kernel, how can I enforce the terms of my code (guaranteed write to
> > Tivoize) in the derivative work that it becomes mixed with?
>
> In just the same way you'd enforce it today: with help from a lawyer
> who understands these issues that you clearly don't understand.
>
> >> So a tivoizer would have to take out the code licensed under the
> >> GPLv3, and use only the code that permits tivoization. Same as today,
> >> but without the possibility of cooperation for licensees who don't
> >> tivoize.
>
> > I am baffled how this could possibly work. You understand that the GPLv2
> > specifically guarantees that any derivative work will be Tivoizable and the
> > people who chose the GPLv2 specifically want it that way?
>
> Yes. And the GPLv2 code would remain that way.
>
> If GPLv3 had this provision I suggested, and you wanted to cooperate
> with some other project that offered GPLv3 drivers, then you could use
> them by adding the mutual-cooperation provision I suggested.
>
> Of course you're free to not want to cooperate with anyone else who
> doesn't share your opinion. That's your call.
>
> > If I chose the GPLv2 over the GPLv3 as a conscious choice, that means I want
> > people to be able to Tivoize any derivative work made from my work that is
> > distributed.
>
> This provision was not intended to prevent anyone from tivoizing your
> work or derived works thereof. It was only intended to enable you to
> use code from GPLv3 projects as long as these GPLv3 projects could
> also use your code. Mutual cooperation, as opposed to no cooperation
> whatsoever.
>
> I *think* lawyers would probably recommend you to keep code under
> different licenses in separate files, like you already do with code
> licensed under GPLv2-compatible licenses.
>
> I *think* that, with this pair of mutual cooperation provisions, you
> could even use code licensed under the Apache 2.0 license. And
> OpenSolaris drivers, if it's licensed under GPLv3.
>
> And you wouldn't be departing from your intent to enable people to
> tivoize your code, which you currently choose not to enforce even
> though GPLv2 might very well enable you to; you could keep on
> cooperating with people who understand GPLv2 doesn't permit
> tivoization, and you'd be able to establish mutual cooperation with
> people who choose a license that makes this point clear.
>
> It's not like anyone can safely tivoize devices with GPLv2 already, so
> refusing to cooperate with GPLv3 on these grounds buys you nothing.
> It is only a public statement of refusal to cooperate, with you are
> entitled to make, even if it comes off as silly because you chose a
> license that already contains the provisions for "complete
> corresponding source code" and "no further restrictions on the
> exercise of the rights granted by the license" that tivoizers fail to
> comply with.
So you really didn't pay any attention to anything people told you?
Ok, here are the relevant parts from GPLv2,
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0. ... Activities other than copying, distribution and modification
are not covered by this License; they are outside its scope. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6. ... You may not impose any further restrictions on the recipients'
exercise of the rights granted herein. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
11. ... THERE IS NO WARRANTY ... INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The license does not grant the right that you will be able to run the
software on any particular platform or whether it will even work at all.
You are only granted the rights to _COPY_, _DISTRIBUTE_, and _MODIFY_.
Tivo in no way limits your ability to exercise any of these rights.
> FWIW, all of my (very few) contributions to Linux were made with the
> intent of not permitting tivoization or any form of restricting users
> freedoms. I guess this means, from now on, you'd stop accepting my
> contributions and take out whatever contributions I've made, since
Only if the terms of your contributions are conflicting with the terms
of the GPLv2 and you are not willing to dual license your code. There is
no need to take out contributions because the GPLv2 does not prevent
tivoization.
Although you did license your code under the GPLv2 and as such gave the
permission to freely copy, distribute and modify, I think most kernel
developers will respect the wishes of the original author if he really
wants to have his code removed.
> So what exactly are you trying to accomplish by pretending that mutual
> compatibility with GPLv3 would set you back in any way?
GPLv3 adds additional restrictions, which the original authors did not
want to impose on their licensee's otherwise they would have licensed
(or would re-license) their code as GPLv2+.
A mutual compatibility agreement (sublicense) would effectively
terminate any rights granted by the GPLv2,
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this
License.
...
7. If ... for any other reason ... conditions are imposed on you ...
that contradict the conditions of this License, they do not excuse
you from the conditions of this License.
Jan
On Jun 21, 2007, "David Schwartz" <[email protected]> wrote:
> 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}
On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
> 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...
On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
> 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:
My god, you really have come totally unhinged in your attempt to
reconcile two incompatible ideas. Ouch.
The reason the GPLv2 ecosystem is so strong is that you can take any
code under GPLv2 and combine it with any other code under GPLv2 and the
result is GPLv2. All you have to check is that the original code is
either GPLv2 or a licence that allows conversion to GPLv2, that's it.
None of this "Projects" nonsense.
Who says what code is a "project" and if it has any special
relationships with other "projects" that allow code sharing above and
beyond their standard licence terms. Suddenly using other GPLv2 code
becomes fraught with "which path did I obtain this licence down" games
and either a big fat pile of paperwork or plain not being able to be
clear about the licencing of of the code.
It's not about projects, it's about the code. Gah. You're not going
to make a happy, happy merging code sharing world by fragmenting the
licence landscape even more.
Bron.
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[email protected]> wrote:
>
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> > Tivoize the
> >> > result?
>
> >> No. This is not permission to relicense. This is permission to
> >> combine. Each author still gets to enforce the terms of her own code.
>
> > This makes no sense. We are not talking mere aggregation here, we are
> > talking developmental convergence. If I wrote some code that was in the
> > Linux kernel, how can I enforce the terms of my code (guaranteed write to
> > Tivoize) in the derivative work that it becomes mixed with?
>
> In just the same way you'd enforce it today: with help from a lawyer
> who understands these issues that you clearly don't understand.
Great, so for ever and ever afterwards the code would have to keep a
clear separation between the bits that are under different licences and
make sure that no re-factor ever blurred the lines between them enough
that you had trouble telling which was which.
And don't even get me started about some poor innocent end-user who just
wants to use some code from your mutant frankenstein "project" in her
pong game (or was it tetris, I lose track of what you're supposed to be
playing on your hacked TiVo while it's not allowed to connect to their
network any more) and understand what licence the final work is under.
Ouch.
Bron.
On Jun 21, 2007, Jan Harkes <[email protected]> wrote:
> On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
>> It's not like anyone can safely tivoize devices with GPLv2 already,
> So you really didn't pay any attention to anything people told you?
Yes. Particularly to what Alan Cox and his legal counsel told me. A
single copyright holder able and willing to enforce the license
against tivoization is enough. What part of this don't you
understand?
> The license does not grant the right that you will be able to run the
> software on any particular platform or whether it will even work at all.
It doesn't grant TiVo the right to distribute the program without
corresponding source code.
They fail to distribute the source code to the functional signature
derived from the kernel binary.
Kaboom!
As for the right to run the program, I've also explained why in
Brazilian copyright law this is a right granted by the license,
because the license says that right is unrestricted.
Kaboom!
> There is no need to take out contributions because the GPLv2 does
> not prevent tivoization.
Says you (or perhaps you're just repeating what you heard and want to
believe).
But what did your lawyer say about it? In reference to which
jurisdiction?
> A mutual compatibility agreement (sublicense) would effectively
> terminate any rights granted by the GPLv2,
Additional permissions to combine are not permission to relicense.
Look at section 13 of GPLv3dd4 and of Affero GPLv3dd1. That's the
sort of additional permission I'm talking about here.
The same kind of additional permission that GPLed projects that use
openssl adopt.
--
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}
On Fri, Jun 22, 2007 at 02:34:17AM +0100, Al Viro wrote:
> 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".
> 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
On Jun 21, 2007, Al Viro <[email protected]> wrote:
> On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
>> 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.
No, this thread was about additional permissions to combine with other
licenses. I didn't suggest anything about relicensing whatsoever,
that's all noise out of not understanding the suggestion.
You objected to granting additional permissions. You have that right,
per copyright law, and the other developers can then decide between
not granting an additional permission or removing all the code you
contributed such that they can. That's veto.
Similarly, if someone proposed an additional unambiguous permission to
tivoize under GPLv2, any developer who objected to it could veto it
(the alternative being to remove all of his contributions).
> What really gets me is that you know it.
Yes. The only disagreement is that I'm talking "additional permission
to combine" and you seem to keep understanding "relicensing", even
though these are very different concepts, with significantly different
consequences.
What they have in common is that you can veto either one with your
status as copyright holder, and that they would both permit some forms
of cooperation.
Permission to relicense would provide for one-way cooperation out of
Linux. I'm not proposing this. That would be stupid. You've already
decided about it. I respect that decision. I even understand why you
made that decision.
Relicensing would provide for two-way cooperation, but under terms
that you don't consider acceptable. You've pretty much already
decided not to do it. I respect that decision. I even understand why
you made that decision.
Permission to combine in both sides would provide for two-way
cooperation in ways that enable each author to enforce the terms s/he
chose for his/her own contributions. This would address many of the
concerns raised about relicensing, and would increase the amount of
contributions in kind you can get.
--
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}
On Jun 21, 2007, Bron Gondwana <[email protected]> wrote:
> None of this "Projects" nonsense.
The reason I mentioned projects was because each project has its
policies, around the interests of its own community. Each project can
thus make a decision about its own policies, just like Linux has made
its own decisions.
It was not my intent to suggest that developers in certain projects
(communities, groups, however you want to name that) should grant
permissions for cooperation with other specific projects, even though
this is certainly something that can be done under copyright law.
So don't read too much into "project", think of it as "policy in a
particular community of developers", and note that the terms I
suggested didn't make any reference whatsoever to projects, but rather
to licenses (part of the policy of each project).
> Suddenly using other GPLv2 code becomes fraught with "which path did
> I obtain this licence down" games
I don't see how this could possibly be come up as a consequence of my
suggestion. In fact, it is my understanding that the path is not
relevant, what matters is the terms under which the copyright holders
are willing to license their code. That someone might be able to
enforce stricter terms upon a combined work is just a consequence of
the "most restrictive license" rule, not of the path the code
followed. But IANAL.
> You're not going to make a happy, happy merging code sharing world
> by fragmenting the licence landscape even more.
I take it that removing barriers to cooperation in GPLv3 by default is
undesirable. Well, then, what can I say? I tried. :-(
--
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}
On Jun 21, 2007, Bron Gondwana <[email protected]> wrote:
> Great, so for ever and ever afterwards the code would have to keep a
> clear separation between the bits that are under different licences and
> make sure that no re-factor ever blurred the lines between them enough
> that you had trouble telling which was which.
As long as you care about being able to tell which is which, yes. I
can understand why, under some circumstances, this might be taken as
worse than not being able to use code under GPLv3 (or any other
incompatible license) at all.
> understand what licence the final work is under.
If it's a mingled combination of code under GPLv2 plus permission to
combine with v3, and GPLv3 plus (potential built-in?) permission to
combine with v2, these are the combined terms. You can still use it
with code under GPLv2 plus permission to combine with v3, and with
GPLv3 plus (potential built-in?) permission to combine with v2. I can
see that it boggles the minds not used to this kind of combination.
--
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}
On Fri, Jun 22, 2007 at 01:14:27AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Jan Harkes <[email protected]> wrote:
> > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> >> It's not like anyone can safely tivoize devices with GPLv2 already,
>
> > So you really didn't pay any attention to anything people told you?
>
> Yes. Particularly to what Alan Cox and his legal counsel told me. A
> single copyright holder able and willing to enforce the license
> against tivoization is enough. What part of this don't you
> understand?
>
> > The license does not grant the right that you will be able to run the
> > software on any particular platform or whether it will even work at all.
>
> It doesn't grant TiVo the right to distribute the program without
> corresponding source code.
>
> They fail to distribute the source code to the functional signature
> derived from the kernel binary.
>
> Kaboom!
A signature is not a creative work and as such not covered by copyright.
At the moment the only protection that the signature/key has is that of
a trade secret, the GPLv2 does not cover that type of intellectual
propery and does not grant the licensee access to trade secrets.
Show me any case law that indicates otherwise. Maybe the content
producers will at some point manage to establish that encryption keys
and signatures are somehow copyrightable, but until a court of law
makes that determination there is no kaboom here.
> As for the right to run the program, I've also explained why in
> Brazilian copyright law this is a right granted by the license,
> because the license says that right is unrestricted.
>
> Kaboom!
No, the license says that it does not address the right to run a
program, and states that the license does not impose restrictions.
That is quite different from saying that the right is unrestricted.
So again, not much of a kaboom here either.
> > A mutual compatibility agreement (sublicense) would effectively
> > terminate any rights granted by the GPLv2,
>
> Additional permissions to combine are not permission to relicense.
> Look at section 13 of GPLv3dd4 and of Affero GPLv3dd1. That's the
> sort of additional permission I'm talking about here.
I'm talking about the GPLv2, so it doesn't matter what the GPLv3 says
wrt. additional permissions. Even if GPLv2 and GPLv3 grant the same
freedoms (permissions), the collective work would have additional
restrictions because of the GPLv3 code and as such the combined work
would result in a sublicensing of the GPLv2 licensed code, which is
explicitly not permitted.
> The same kind of additional permission that GPLed projects that use
> openssl adopt.
If they are the original author they can make that decision, just like
authors can dual-license, or decide to license their code as GPLv2+. It
is kind of funny how they phrase the exception as granting permission to
link against OpenSSL, where in reality they accept the added restriction
that results from the advertising clause of the BSD license. (i.e.
instead of granting you an additional freedom, they chose to remove the
freedom to modify the part of the code that advertises).
However with the openssl case there is no tight coupling because openssl
is a separate library. Some people have argued that the LGPL was never
really necessary because (unlike static libraries) shared libraries are
still separable from the GPL'd program.
Furthermore, those projects are not pulling individual source files from
into their project. There are also alternative crypto libraries (gnutls,
nessie) which can in many cases easily replace the openssl dependency.
Finally the original author accepts the additional restriction that
comes from the BSD + advertising clause, while the GPLv2 authors do not
accept the additional restrictions they would inherit from the GPLv3
otherwise they would re-license their code to GPLv2+.
Jan
On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Al Viro <[email protected]> wrote:
>
> > On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
> >> 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.
>
> No, this thread was about additional permissions to combine with other
> licenses. I didn't suggest anything about relicensing whatsoever,
> that's all noise out of not understanding the suggestion.
And that constitutes the change of license. If you *really* do not understand
that, I'd recommend asking FSF legal folks, especially since you have
mentioned working on v3. And that, BTW, is far more serious detail than
your affiliation (or lack thereof) with FSF. Don't forget to bring a copy
of your posting that had started this thread when you talk to them.
And really, stop digging. Please. YANAL. You are definitely not in
position to offer any specific changes in v3. Are you seriously expecting
an ACK on your handwaving, when conditions mentioned in your patch to
license are not just vague as hell, but are 100% certain to be interpreted
in conflicting ways as shown by the previous thread?
What are you expecting, anyway? "You guys can link to v3 code if you read
v2 as prohibiting tivoization, otherwise the code is withdrawn" != "some
people think that v2 prohibits it, some do not". And somehow I doubt that
this change of situation will make the latter happy.
Besides, what you are suggesting is logistical nightmare. Somebody in
v3 project changes borrowed v2 code. Result is pulled back into Linux.
What is the license of that thing? v3 with additional permission? v2
with additional permission? What happens if code is then rewritten, with
some pieces remaining from v3 changes? Oh, you want to deal only with
entire modules? And then both sides need to be damn careful not to copy
pieces across the module boundary?
Suppose ZFS _is_ pulled into the tree via that mechanism. Just what
will happen if some code is massaged a bit, found generically useful
and lifted into a helper function? Do other filesystems (v2 ones)
calling it suddenly get into patent violations?
Just what makes you think that anybody would like that kind of "cooperation"?
On Fri, Jun 22, 2007 at 01:34:24AM -0300, Alexandre Oliva wrote:
> I take it that removing barriers to cooperation in GPLv3 by default is
> undesirable. Well, then, what can I say?
That It's All Their[kernel developers'] Fault(tm), of course.
> I tried. :-(
Or that, indeed.
On Fri, 22 Jun 2007 01:34:24 -0300 Alexandre Oliva wrote:
> > You're not going to make a happy, happy merging code sharing world
> > by fragmenting the licence landscape even more.
>
> I take it that removing barriers to cooperation in GPLv3 by default is
> undesirable. Well, then, what can I say? I tried. :-(
preferably that you give up.
Thanks.
---
~Randy
On Jun 22, 2007, Theodore Tso <[email protected]> wrote:
> has probably made it made it much more *unlikely* that the Linux
> kernel will ever go GPLv3.
That was a given from the start. The spin that there was any chance
whatsoever it could possibly happen was just that. Even if Linus
could possibly consider this, others have made it pretty clear that
this was never an option for them, and Linus' explosion at my first
one-liner intervention on GPLv3 isn't exactly a sign of being
considering something reasonably.
So, no, as I've repeatedly stated, I wasn't here to convince anyone to
adopt GPLv3. I know you won't believe me. I don't care.
I was here to dispell the lies that were being spread about GPLv3, the
spirit and the goals of the GPL, as far as I understood them. I knew
from the start that it was an uphill battle, and that I wouldn't be
able to convince those who distrusted the FSF so much that they would
listen to anything that resembled an FSF discourse with an extremely
high rejection level. This was all expected.
I wasn't here to convince them. I knew I wouldn't. I was here to set
the record straight on the spirit of the GPL, not towards the most
vocal opponents, but for others who hadn't formed an opinion,
prejudiced or not. I was here to inform about GPLv3, not to push it.
That I was perceived as pushing it is not surprising at all. The
perception of "being forced" whenever something resembling the FSF
ideology comes up is so strong here that some people just stop
listening, stop thinking rationally (limbic system take-over?), or
even get into outright name calling. No surprise here. I knew this
was hostile territory, and I came prepared for this.
I feel I have accomplished my goal: I've informed a lot of people
about the GPL, about GPLv3, about Free Software and even about the
FSFes. Whether they make a decision for GPLv3, GPLv2, or more liberal
Free Software licenses, is up to them. Now, people who'd only been
exposed to the prevailing views in this list can take something
different into account, and make more-informed decisions.
Thanks for listening.
o-o
--
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}
On Jun 22, 2007, Al Viro <[email protected]> wrote:
> On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote:
>> No, this thread was about additional permissions to combine with other
>> licenses. I didn't suggest anything about relicensing whatsoever,
>> that's all noise out of not understanding the suggestion.
> And that constitutes the change of license.
I stand corrected. I misread what you wrote as "relicensing under
GPLv3, or GPLv2+". Sorry.
> Suppose ZFS _is_ pulled into the tree via that mechanism.
Or even kept outside, such that third parties can create a combined
work and distribute that.
--
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}
> 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
Untrue. Many of us think (and the lawyers are unsure) that it is covered
by GPLv2 anyway. Some drivers actually make this clear in their comments
about intepretation
> Another law of negotiations --- don't goad people into hardening their
> positions; it helps neither you nor your interests.
That always depends which side you really support, whether you want to
force someone to wedge themselves in an undefendable corner and so on..
Alan
On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote:
> I was here to dispell the lies that were being spread about GPLv3, the
> spirit and the goals of the GPL, as far as I understood them. I knew
> from the start that it was an uphill battle, and that I wouldn't be
> able to convince those who distrusted the FSF so much that they would
> listen to anything that resembled an FSF discourse with an extremely
> high rejection level. This was all expected.
News flash: almost no one except for you cares about the "spirit of
the GPL", and it was not on that basis that people decided that the
GPLv3 was an inferior license, FOR THE LINUX KERNEL.
> That I was perceived as pushing it is not surprising at all.
So the fact that you keep talk about the general case, when in fact
the concern was about the specific case of the Linux kernel, certainly
DID make it seem like that you were pushing it. THE GENERAL CASE IS
OUT OF SCOPE FOR THIS MAILING LIST.
And no, it's not a perception of "being forced", it's was a matter of
consuming huge amounts of bandwidth on a topic which was out-of-scope
for this mailing list. And the only topic which was in scope (whether
or not GPLv3 was appropriat for the Linux kernel development
community) was one where you would keep slidng away from.
> I feel I have accomplished my goal: I've informed a lot of people
> about the GPL, about GPLv3, about Free Software and even about the
> FSFes. Whether they make a decision for GPLv3, GPLv2, or more liberal
> Free Software licenses, is up to them. Now, people who'd only been
> exposed to the prevailing views in this list can take something
> different into account, and make more-informed decisions.
Great. So can we please END this thread?
Thank you.
- Ted
On Fri, Jun 22, 2007 at 10:14:23AM +0100, Alan Cox wrote:
> > Another law of negotiations --- don't goad people into hardening their
> > positions; it helps neither you nor your interests.
>
> That always depends which side you really support, whether you want to
> force someone to wedge themselves in an undefendable corner and so on..
Well yes, I'm assuming that the goal is successfully concluded
negotiations. If in fact the idea is to force people to wedge
themselves into an undefensible corner so that you can blame the
failed negotiations on *them*, when it was really *you* who had no
interest in reaching a mutually agreeable compromise, then of course
that could be a valid tactic. That's a bit of an advanced technique,
though; and some might call it a tad slimeball thing to do. Happens
all the time in political and labor discussions, though!
I hope that wasn't want Alexandre was trying to do, although at times
where one could wonder if he was really sent by Tivo to make sure the
kernel would stay GPLv2. :-)
- Ted
On Jun 22, 2007, Theodore Tso <[email protected]> wrote:
> On Fri, Jun 22, 2007 at 10:14:23AM +0100, Alan Cox wrote:
>> > Another law of negotiations --- don't goad people into hardening their
>> > positions; it helps neither you nor your interests.
>>
>> That always depends which side you really support, whether you want to
>> force someone to wedge themselves in an undefendable corner and so on..
> Well yes, I'm assuming that the goal is successfully concluded
> negotiations.
I guess this means you don't believe what I claimed all the way from
the beginning about what I was trying to accomplish. Not surprising,
really.
Please believe me. I know I'm a terrible negotiator. I know I get
people to harden their positions.
Why on earth would I, knowing about these shortcomings of mine, get
into this debate if my goal were to convince you guys, who'd pretty
much all made up your minds months ago, to change anything? This
would be utterly stupid. Do you think I'm *that* stupid?
Not just a terrible negotiator, but also a stupid liar? :-)
I know what I was trying to accomplish. I can even show evidence of
that, which you may very well disbelieve. When one of the FSF execs,
worriedly wrote to me after reading about a discussion I was allegedly
having with Linus on behalf of the FSF
http://digg.com/linux_unix/Linus_Torvalds_to_the_FSF_I_m_damn_fed_up,
he asked me what I was trying to achieve. On the same day, June 14, I
responded that I'd repeatedly made it clear (but apparently never
clear enough) that I didn't speak for the FSF, and not even for FSFLA,
and that what I was trying to achieve was:
- set the record straight on my opinion as to whether GPLv3 changes
the spirit of the GPL (it doesn't, not even in the case of
Tivoization, as argued in
http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite
- dispell myths as to other apparent new obligations that people
seem to perceive in GPLv3, that were either already present in GPLv2
or that are necessary to better abide by the spirit of the GPL
encoded in the preamble
- offer evidence that whatever perceived losses the Linux (kernel)
community might suffer from switching to GPLv3 would be from
non-contributors who are not really willing to abide by the spirit
of the GPL chosen by the Linux authors, and that it would rather be
more beneficial for Linux because it would push the exploiters away
while making room for more actual contributors
Now, since I wrote this, I learned that many Linux authors really
understood the "no further restrictions" provision of GPLv2 in a far
more limited different way, that the spirit in which they licensed
their code departed from the spirit of the GPL. Nevertheless, I
offered the reasoning I had to offer about potential benefits of
anti-tivoization provisions, because I saw no evidence that anything
but potential negative consequences had been taken into account. The
same negative consequences that are being brought up WRT the GPLv3
clarifications have repeatedly been brought up against the GPL since
its inception: "Oh my God, this will scare businesses, they will never
use it." Time is showing these fears were largely exaggerated. I
hope this will prove true for GPLv3 as well, but my crystal ball is
failing me, even more so because a critical piece of code that would
enable us to tell, in the long run, is, let's say, highly skeptical of
the possibility that prohibiting certain uses can be beneficial in the
long run.
As for why I got into this debate... Isn't it much simpler to believe
that I got into the debate because Greg KH wrote things about GPLv3
that I understand to be incorrect, and I wanted to set the record
straight on it, than that I, an admittedly unskilled negotiator, was
going to try to "push GPLv3 down your throats"?
And that the most important issue to set the record straight on was
*precisely* about the complaint, signed by him and about half of the
major contributors to Linux, and later supported by other major
contributors, that GPLv3 changed the spirit of the license? How on
earth can you and others possibly claim with a straight face that
"nobody cares about the spirit"?
The other point I intended to make was the accusation that the FSF was
dividing the community. This is very unfair. If the release of a
license that more clearly expresses the intent of part of the
community, and this part of the community adopts it, while another
part of the community rejects it, is this not a sign that the
community is already divided?
Given that part of the community at large, including the FSFes, seeks
better defenses for the freedom of their code, seeks respect for the
"freedom or death" provision already present in GPLv2 (even if
interpreted by some in a narrower sense than it was meant), how is it
fair to complain that they exercise the option to obtain such
defenses, on the grounds that the complaining party might no longer
get the full cooperation of the party who wanted more?
If you're unhappy with GPLv3, why couldn't people who want better
assurance that their code won't be used in ways they don't want be
unhappy that GPLv2 doesn't guarantee these defenses for them?
Don't you see that attacks on GPLv3, suggestions that it's weakened or
dropped, such that these two parts of the community could keep on
cooperating under terms you prefer but they don't, would be just as
bad for others as taking GPLv2 away from you would?
GPLv2 is not going away. GPLv3 is going to be one more option, and
it's better than GPLv2 for many people. You can have different goals
than GPLv3 and prefer other licenses over it as much as you want. I
don't care (*). But please respect that others disagree with your
goals and want GPLv3, and if this reduces the amount of cooperation
you get from them to achieve your goals, realize that you're also
refusing to cooperate with them to achieve theirs. This is
unfortunate, but it's not unfair. What's unfair is to try to shift
the blame onto only one of the parties.
(*) I reserve the right to vocally oppose decisions for non-Free
Software licenses, because I understand that, even though anyone may
have a legal right to make such decisions, it's unethical to make such
decisions, and it prolongs a social problem that I devote a
significant portion of my life to terminate. I thank you all for your
help in achieving this goal, even if it's involuntary.
> it was really *you* who had no interest in reaching a mutually
> agreeable compromise,
This is an unfair characterization of the situation. I think both
sides have very little interest in compromising their positions, and
that's fair. Yesterday, when *I* (!= FSF, != FSFLA) started this
thread with a proposal about mutual compatibility that seemed to me to
be a reasonable compromise, that AFAICT would meet all of the points
that had been brought in the long discussion that preceded, was when I
started an effort of mediating a negotiation between two parties that
AFAICT were not really interested in participating in such a
negotiation.
My suggestion wouldn't work unless both parties made some concessions,
in order to obtain the benefits of mutual cooperation. No party would
be required to make such concessions.
The only thing that's clear so far is that one person in one party is
not interested in using such an agreement; a person that had already
voiced an opinion against relicensing his contributions to Linux in a
GPLv3-compatible way, not even if Sun were to license the OpenSolaris
kernel under GPLv3. No surprise here.
I wish I'd got other opinions about this proposal, though, such that I
can make a decision on whether it even makes sense for me to champion
this suggestion towards inclusion in GPLv3.
> at times where one could wonder if he was really sent by Tivo to
> make sure the kernel would stay GPLv2. :-)
:-) Dammit, how did you guess? :-) I even tried to disguise it by
insisting that GPLv2 already prohibits this practice! :-)
--
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}
> > 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
> Untrue. Many of us think (and the lawyers are unsure) that it is covered
> by GPLv2 anyway. Some drivers actually make this clear in their comments
> about intepretation
I didn't mean to speak for every single contributor to Linux. I apologize if
I gave that impression.
Lawyers are almost always unsure of things that aren't well-settled. It's
practically a job requirement. However, I think that view is so incredibly
bizarre that I can't imagine anyone taking it seriously. Not even the FSF
agrees with it, and they have taken insanely expansive views of the scope of
the GPL.
If the GPLv2 says you can't Tivoize, then Linus is violating the GPL by
withholding the keys he uses to sign the Linux kernel source release. No
rational argument would defend one point and not the other (unless you add
crazy ad-hocery with no support in law or common sense). If you are one of
those people, please be consistent and condemn Linus' refusal to release his
signing keys and thus "Tivoizing" the Linux kernel.
Don't even try to make some kind of counter-argument about signatures that
are or aren't functional. Functionality would *exempt* things from copyright
coverage, not subject them to it. (And Linus' signature *is* functional.
People use it to decide whether or not to run the code. It serves no other
purpose than that. Some people will only run kernel code signed by Linus,
and my not having his signing key means that my changes can't be run on
machines controlled by those people.)
DS
On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote:
> That was a given from the start. The spin that there was any chance
> whatsoever it could possibly happen was just that. Even if Linus
> could possibly consider this, others have made it pretty clear that
> this was never an option for them, and Linus' explosion at my first
> one-liner intervention on GPLv3 isn't exactly a sign of being
> considering something reasonably.
>
> So, no, as I've repeatedly stated, I wasn't here to convince anyone to
> adopt GPLv3. I know you won't believe me. I don't care.
>
> I was here to dispell the lies that were being spread about GPLv3, the
> spirit and the goals of the GPL, as far as I understood them. I knew
> from the start that it was an uphill battle, and that I wouldn't be
> able to convince those who distrusted the FSF so much that they would
> listen to anything that resembled an FSF discourse with an extremely
> high rejection level. This was all expected.
Just because someone has a different opinion than you or the FSF does
not make what they say a lie. Is that particularly difficult to
understand? It is exactly this kind of nonsense that makes people not
want to listen to the FSF and its advocates.
> I wasn't here to convince them. I knew I wouldn't. I was here to set
> the record straight on the spirit of the GPL, not towards the most
> vocal opponents, but for others who hadn't formed an opinion,
> prejudiced or not. I was here to inform about GPLv3, not to push it.
Well what the spirit is, is certainly debateable, and it seems there
probably won't ever be a consensus on that. The thoughts in the head of
RMS are not the only ones that count in the world.
> That I was perceived as pushing it is not surprising at all. The
> perception of "being forced" whenever something resembling the FSF
> ideology comes up is so strong here that some people just stop
> listening, stop thinking rationally (limbic system take-over?), or
> even get into outright name calling. No surprise here. I knew this
> was hostile territory, and I came prepared for this.
Any organization that claims anyone that doesn't agree with its view of
thw world and its interpretation of some written text is "confused" will
be treated like all other religigous fanatics, and not listened too.
Intelligent people know better than to listen to such groups. Some of
us really can think for ourselves and don't have to be spoonfed
beliefs.
> I feel I have accomplished my goal: I've informed a lot of people
> about the GPL, about GPLv3, about Free Software and even about the
> FSFes. Whether they make a decision for GPLv3, GPLv2, or more liberal
> Free Software licenses, is up to them. Now, people who'd only been
> exposed to the prevailing views in this list can take something
> different into account, and make more-informed decisions.
I think I know exactly as much about the GPL now as I did two weeks ago.
Repeating the same arguments to people again and again when they
consider the argument invalid isn't going to change their minds.
--
Len Sorensen
On Jun 25, 2007, [email protected] (Lennart Sorensen) wrote:
> On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote:
>> I was here to dispell the lies that were being spread about GPLv3, the
>> spirit and the goals of the GPL, as far as I understood them.
> Just because someone has a different opinion than you or the FSF does
> not make what they say a lie.
As a general statement, yours is absolutely correct.
However, the situation at hand is quite different AFAICT. It's about
people repeatedly making statements that misconstrued the intent of a
third party, even after having been drawn attention to this. AFAICT,
both elements needed to characterize lying are present: deviation from
the truth, and intent to instill the incorrect statements on others as
if they were true.
Now, it might be that those making such statements hadn't fully
realized what they were writing on was on others' intentions, rather
than objective facts or their own opinions, and that they didn't
realize they were misrepresenting those intentions before I brought
this up here. In this case, if they confirm it, I'll be delighted to
retract my assessment of such behavior as 'lying'.
> Well what the spirit is, is certainly debateable,
If you misunderstand what 'the spirit of a legal text' as something
other than the intent of whoever wrote that document, then yes, it is
debatable. You may want to take up the alleged inaccuracy to
Wikipedia: http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law
When one obeys the letter of the law but not the spirit, he is
obeying the literal interpretation of the words (the "letter") of
the law, but not the intent of those who wrote the law. Conversely,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
when one obeys the spirit of the law but not the letter, he is doing
what the authors of the law intended, though not adhering to the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
literal wording.
> Any organization that claims anyone that doesn't agree with its view of
> thw world and its interpretation of some written text is "confused" will
> be treated like all other religigous fanatics, and not listened too.
I suppose it thus follows that people will then take this perception
further and selectively ignore portions of texts written by these
parties. And then become frustrated and complain when their
conclusions don't match those that are evidently encoded in the
portions that were ignored by them. And then complain when they're
misunderstanding the text, or when they're characterized as confused,
or however else their selective attention and its misleading
consequences are characterized.
> Intelligent people know better than to listen to such groups.
Ignoring facts that don't fit your ideology, or that support an
ideology you reject, will mislead you, no matter what your fanaticism
or anti-fanaticism is.
> I think I know exactly as much about the GPL now as I did two weeks ago.
Good for you (assuming you're not saying you've refused to learn
anything just because I was the one passing on the knowledge, because,
well, this would be unintelligent too, right? ;-)
Consider this scenario: vendor tivoizes Linux in the device, and
includes the corresponding sources only in a partition that is
theoretically accessible using the shipped kernel, but that nothing in
the software available in the machine will let you get to. Further,
sources (like everything else on disk) are encrypted, and you can only
decrypt it with hardware crypto that is disabled if the boot loader
doesn't find a correct signature for the boot partition, or maybe the
signature is irrelevant, given that everything on disk is encrypted in
such a way that, if you don't have the keys, you can't update the
kernel properly anyway. The vendor refuses to give customers other
copies of the sources. To add insult to the injury, the vendor
configures the computer to set up the encrypted disk partition
containing the sources as a swap device, such that the shared-secret
key used to access that entire filesystem is overwritten upon the
first boot, rendering the entire previous contents of the partition
holding the source code into an incomprehensible stream of bits.
Does anyone think this is permitted by the letter of GPLv2? Is it in
the spirit of GPLv2? How are the sources passed on in this way going
to benefit the user or the community?
Is this still desirable by the Linux developers?
--
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}
On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in the machine will let you get to. Further,
> sources (like everything else on disk) are encrypted, and you can only
Interesting scenario, it seems to comply with GPLv2 on the surface.
If that kernel doesn't actually allow access and wipes the source
partition to use it as swap on first boot, then no machine is actually
capable of reading the source. So it isn't really machine readable.
Another gripe is that encrypted media are not customarily used for
software interchange. So that's 2 (minor) strikes where this method of
distribution doesn't seem to match the language of section 3a.
You also cannot interpret the encrypted partition as source code because
a bit further down in section 3, it defines source code as,
"The source code for a work means the preferred form of the work for
making modifications to it."
So now we get to section 6. The recipient receives a license to copy,
distribute or modify. You may not impose further restrictions on
these rights granted herein.
You could argue that they do not restrict copying, distribution
and modification of the sources in general, only of the specific copy
they distribute. However here we go back to section 2 which states that
their modified copy is a derived work which must be licensed under the
GPLv2, so that would make it specific enough that recipients have in
fact been granted the right to copy, distribute and modify the copy of
the source of that corresponds to the distributed binaries, which is
restricted because of the encryption which prevents the user to copy,
distribute or modify the source code.
> Does anyone think this is permitted by the letter of GPLv2?
No.
> How are the sources passed on in this way going to benefit the user or
> the community?
Not a really interesting question if the method of distribution violates
the letter of the GPLv2, is it? They get sued for copyright infringement
because they are not in compliance with section 3 and the sources are
released as a result.
Jan
On Jun 26, 2007, Jan Harkes <[email protected]> wrote:
> On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
>> Consider this scenario: vendor tivoizes Linux in the device, and
>> includes the corresponding sources only in a partition that is
>> theoretically accessible using the shipped kernel, but that nothing in
>> the software available in the machine will let you get to. Further,
>> sources (like everything else on disk) are encrypted, and you can only
> Interesting scenario, it seems to comply with GPLv2 on the surface.
> If that kernel doesn't actually allow access and wipes the source
> partition to use it as swap on first boot, then no machine is actually
> capable of reading the source.
Granted, that was just adding insult to the injury ;-)
Assume the sources are kept in the encrypted disk. Or that the
sources are shipped in an encrypted CD, that only the machine itself
can read, using hardware-assisted decryption.
> Another gripe is that encrypted media are not customarily used for
> software interchange.
That the whole disk is encrypted is "just a technical detail". And
it's not the media that's encrypted, it's the data in it. Surely both
hard disks and CDs are media customarily used for software
interchange. And there is often compressed and encrypted data and
software in them.
> You also cannot interpret the encrypted partition as source code because
> a bit further down in section 3, it defines source code as,
> "The source code for a work means the preferred form of the work for
> making modifications to it."
The encrypted partition is not the source code. It contains the
source code. Very much like the computer, or the disk, or the boot
partition, is not the GPLed program, it contains the GPLed program.
That it's encrypted, signed, or hardware-protected, have all been
claimed as reasons why they're outside the scope of the GPL and can be
used to escape its intent in this or other recent threads.
> You could argue that they do not restrict copying, distribution
> and modification of the sources in general, only of the specific copy
> they distribute.
"We don't oppose that you do any of these things, once you get the
source code. We just make it difficult (hopefully impossible) that
you'll get to the source code in the first place."
> They get sued for copyright infringement because they are not in
> compliance with section 3 and the sources are released as a result.
I don't think a copyright lawsuit can be generally expected to obtain
this result. A court can stop the distributor from distributing in an
infringing manner, but I don't think a court could force the
distributing party to shell out source code. The distributing party
might not even *have* source code in the first place. And even if she
had, she might have no right to distribute it. Or she might not want
to, and then a court *might* require them to do so, but that would be
quite unusual.
--
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}
On Jun 26, 2007, Alexandre Oliva <[email protected]> wrote:
> On Jun 26, 2007, Jan Harkes <[email protected]> wrote:
>> You could argue that they do not restrict copying, distribution
>> and modification of the sources in general, only of the specific copy
>> they distribute.
> "We don't oppose that you do any of these things, once you get the
> source code. We just make it difficult (hopefully impossible) that
> you'll get to the source code in the first place."
Actually, they could even claim you don't need the source code to make
modifications. The license even says the source code is the most
convenient form to make modifications, not the only form. Now, that
the others suck rocks is not their fault, is it? ;-)
--
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}
On Tue, Jun 26, 2007 at 04:47:34AM -0300, Alexandre Oliva wrote:
> On Jun 26, 2007, Alexandre Oliva <[email protected]> wrote:
> > On Jun 26, 2007, Jan Harkes <[email protected]> wrote:
> >> You could argue that they do not restrict copying, distribution
> >> and modification of the sources in general, only of the specific copy
> >> they distribute.
>
> > "We don't oppose that you do any of these things, once you get the
> > source code. We just make it difficult (hopefully impossible) that
> > you'll get to the source code in the first place."
>
> Actually, they could even claim you don't need the source code to make
> modifications. The license even says the source code is the most
> convenient form to make modifications, not the only form. Now, that
> the others suck rocks is not their fault, is it? ;-)
GPLv2 section 3.
The source code for a work means the preferred form of the work for
making modifications to it.
I believe this states that the source code has to be in the preferred
form for making modifications and not some other form that sucks rocks.
As far as your argument that making it difficult or impossible to obtain
the source code could be in compliance. I don't see how (intentionally)
making something difficult could not be interpreted as a restriction so
it still violates section 6 of the GPLv2.
And yes, I do realize that you intentionally tried to come up with your
example to somehow bring tivoization to the source code. However
although the GPLv2 doesn't address the freedom to use (and specifically
does not grants the user a right to run a modified version of the
program on some specific piece of hardware), it does (try) to address
the recipients rights to copy, distribute and modify.
Jan
On Jun 26, 2007, Jan Harkes <[email protected]> wrote:
> GPLv2 section 3.
> The source code for a work means the preferred form of the work for
> making modifications to it.
> I believe this states that the source code has to be in the preferred
> form for making modifications and not some other form that sucks rocks.
Yes, but in the scenario I proposed, the source code *is* in the
preferred form for making modifications, it just so happens to be
behind a barrier you cannot trespass. This is not different from
shipping binaries and sources in a CD inside a locked box that you
can't open. You've received both, but how is the fact that you can't
reach the source code (or the binaries) a violation of the GPL in this
case?
And, if it's not a violation, what is it that makes the case of
shipping programs in a locked enclosure different from shipping them
in a locked computing device?
As for making modifications, I'd like to take this opportunity to
withdraw, for purposes of interpretation, my earlier agreement that
TiVo permits modification, even though it doesn't permit modification
in place. I don't see any distinction in US copyright law between
modification in place and modification by creating a separate work.
This distinction makes sense for some cases of modification of
software, but it doesn't make sense for other copyrightable works,
such as sculptures, paintings, drawings, etc.
When you modify a sculpture, you're modifying it in place, and this
requires as much copyright permission as creating a modified copy of
it. Both count as modification. And if TiVo creates artificial
obstacles to your modifying the copy of GPLed programs that ships in
its devices, then I believe it counts as a restriction on
modification. I ought to be entitled to modify any bit in the
executable and expect that to have the same effect as modifying that
bit on that executable on any other computer. The fact that it stops
working as a result of TiVo's design to prohibit modification, rather
than by any other differences in the computer (e.g., the absence of
the signature checks), just goes to show that there is intent to
impose further restrictions on modification of the software.
Saying that I can modify the sources and build another copy of the
binary and then install that, but then it won't work, but that's fine
because this is not modifying, while true, does not disqualify the
claim that TiVo's design imposes artificial restrictions on my
abilities to modify the copies of the program that I have received.
> And yes, I do realize that you intentionally tried to come up with your
> example to somehow bring tivoization to the source code.
Actually, I first came up with this example long before GPLv3dd3 was
published, and I know there have been changes to the draft in response
to it.
Here are variations of another scenario I proposed back then:
- Tivoizing device ships with tivoized software, regardless of whether
the corresponding sources are accessible to the end user or hidden
inside the box, in a fully-encrypted disk that only that machine can
read.
- The software that ships is feature-limited. It's just barely enough
to enable the device to connect to the network and download
feature-complete software.
- Network authenticates the device with help of the built-in crypto
device, and device requests feature-complete binaries in encrypted
network sessions. It's in the fature-complete binaries that the most
valuable improvements made by the tivoizer are, that they don't want
to share with anyone else. Sources *are* available behind the same
authentication machinery you don't can't get past. Whether the device
chooses to download them into the encrypted device you can't get to,
to dispose of them right away or even leave them around, or it simply
refrains from downloading the sources because it doesn't need them,
the end result is the same: you've received the sources over the
network, but you can't get to them.
- Updates to the feature-complete software can be delivered over the
same secure channel, and, as a result, derived versions of your
software are distributed to third parties in ways that neither you nor
the recipient can get to the sources.
Here's another variation:
- Vendor distributes device with feature-limited software in the
fully-encrypted disk, with just enough software to download sources
from the network, build the feature-complete software from sources,
and install it.
- Sources are behind network authentication, as above, so although
your device receives them, you can't get to them because they're in
the encrypted disk.
Does it seem to you that GPLv2 blocks any of these means to distribute
your code without granting its users access to the source code?
--
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}
Alexandre Oliva writes:
> Yes, but in the scenario I proposed, the source code *is* in the
> preferred form for making modifications, it just so happens to be
> behind a barrier you cannot trespass. This is not different from
> shipping binaries and sources in a CD inside a locked box that you
> can't open. You've received both, but how is the fact that you can't
> reach the source code (or the binaries) a violation of the GPL in this
> case?
Behind a barrier is not the preferred form for modification. Encrypted with
a key you don't have is not the preferred form for modification.
> And, if it's not a violation, what is it that makes the case of
> shipping programs in a locked enclosure different from shipping them
> in a locked computing device?
I honestly don't see what relevance this could possibly have. Getting access
to the source is a fundamental GPL right. The GPL is clear that you cannot
burden access to the source.
> When you modify a sculpture, you're modifying it in place, and this
> requires as much copyright permission as creating a modified copy of
> it. Both count as modification. And if TiVo creates artificial
> obstacles to your modifying the copy of GPLed programs that ships in
> its devices, then I believe it counts as a restriction on
> modification.
Of course your nonsense view leads to nonsense results. What a surprise. By
this argument, shipping a GPL'd work in ROM would violate the GPL because
you cannot easily modify that particular copy. Burning a GPL'd work to CDROM
would also be a violation. (See below for why your 'artificial' distinction
is wrong.)
> I ought to be entitled to modify any bit in the
> executable and expect that to have the same effect as modifying that
> bit on that executable on any other computer.
Nope, sorry. If this were true, you ought to be entitled to modify a bit in
the Linux kernel and have it have the same effect as modifying that Linux
kernel on my desktop. Again, nonsense view leads to nonsense conclusions.
The fix is to reject the nonsense view. There are no special GPL rights to
particular copies of works or particular hardware.
> The fact that it stops
> working as a result of TiVo's design to prohibit modification, rather
> than by any other differences in the computer (e.g., the absence of
> the signature checks), just goes to show that there is intent to
> impose further restrictions on modification of the software.
Intent is not the issue. The GPL does not care whether you intended to
comply or why you cannot comply, it just cares whether you do or don't
comply. If modifying software in this way is a GPL right, then anything that
prevents you from modifying software in this way is a GPL violation. If you
can't distribute so as to give all GPL rights, you can't distribute at all.
If the GPL says I can modify my distributed copy, then distributing on CDROM
is a GPL violation. It doesn't matter what your intent is. If you can't
distribute so as to honor all GPL rights, you can't distribute.
It is mind-bogglingly obvious that any sort of "right to modify one
particular copy" is *not* a GPL right.
> Saying that I can modify the sources and build another copy of the
> binary and then install that, but then it won't work, but that's fine
> because this is not modifying, while true, does not disqualify the
> claim that TiVo's design imposes artificial restrictions on my
> abilities to modify the copies of the program that I have received.
It doesn't matter. The GPL does not distinguish between artificial
restrictions and other restrictions. It doesn't permit *ANY* further
restrictions on GPL rights. If you can't grant all the rights (whether due
to artificial restrictions or other types of restrictions) you can't
distribute at all.
You are wasting an awful lot of time and effort analyzing things that have
*NO* GPL consequence at all.
DS
On Jun 27, 2007, "David Schwartz" <[email protected]> wrote:
> Alexandre Oliva writes:
>> Yes, but in the scenario I proposed, the source code *is* in the
>> preferred form for making modifications, it just so happens to be
>> behind a barrier you cannot trespass. This is not different from
>> shipping binaries and sources in a CD inside a locked box that you
>> can't open. You've received both, but how is the fact that you can't
>> reach the source code (or the binaries) a violation of the GPL in this
>> case?
> Behind a barrier is not the preferred form for modification.
Where does it state that there must not be a barrier? I see it saying
the source must accompany the binary, under 3a.
> Encrypted with a key you don't have is not the preferred form for
> modification.
Indeed, but why does it matter? In a CD is not the preferred form for
making modifications either. In fact, in the CD, you can't modify it
at all. What's *behind* encryption is the source code, along with the
binary it accompanies.
>> And, if it's not a violation, what is it that makes the case of
>> shipping programs in a locked enclosure different from shipping them
>> in a locked computing device?
> I honestly don't see what relevance this could possibly
> have. Getting access to the source is a fundamental GPL right.
That's the spirit. But where does the *letter* of the GPL state it?
> By this argument, shipping a GPL'd work in ROM would violate the GPL
> because you cannot easily modify that particular copy.
I've already explained that the inability to modify what's in the CD
is not a restriction imposed by whoever recorded the bits in there as
a means to stop you from making modifications.
>> I ought to be entitled to modify any bit in the executable and
>> expect that to have the same effect as modifying that bit on that
>> executable on any other computer.
> Nope, sorry. If this were true, you ought to be entitled to modify a bit in
> the Linux kernel and have it have the same effect as modifying that Linux
> kernel on my desktop.
If your desktop is sufficiently similar, and the kernel binaries are
identical, why should I not expect the same result to arise?
> Again, nonsense view leads to nonsense conclusions. The fix is to
> reject the nonsense view. There are no special GPL rights to
> particular copies of works or particular hardware.
2. You may modify your copy or copies of the Program or any portion
of it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> The fact that it stops
>> working as a result of TiVo's design to prohibit modification, rather
>> than by any other differences in the computer (e.g., the absence of
>> the signature checks), just goes to show that there is intent to
>> impose further restrictions on modification of the software.
> Intent is not the issue.
Imposing further restrictions is the issue.
> If modifying software in this way is a GPL right, then anything that
> prevents you from modifying software in this way is a GPL violation.
If it is imposed by the licensee, yes, it is indeed.
> If you can't distribute so as to give all GPL rights, you can't
> distribute at all.
Exactly.
> If the GPL says I can modify my distributed copy, then distributing
> on CDROM is a GPL violation.
It doesn't state "you must distribute sources in modifyable media", it
says "you may modify your copies, and the distributor must not have
imposed restrictions on your exercise of this right"
If you can't modify your copies because others get in the way, too
bad. If you can't just because the distributor stops you, there's a
GPL violation.
> It is mind-bogglingly obvious that any sort of "right to modify one
> particular copy" is *not* a GPL right.
Please read the license instead of assuming you know what it says.
You clearly don't. See above.
> You are wasting an awful lot of time and effort analyzing things that have
> *NO* GPL consequence at all.
Let's just say I honestly hope you are right and I'm wrong.
--
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}
> On Jun 27, 2007, "David Schwartz" <[email protected]> wrote:
>
> > Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass. This is not different from
> >> shipping binaries and sources in a CD inside a locked box that you
> >> can't open. You've received both, but how is the fact that you can't
> >> reach the source code (or the binaries) a violation of the GPL in this
> >> case?
> > Behind a barrier is not the preferred form for modification.
> Where does it state that there must not be a barrier? I see it saying
> the source must accompany the binary, under 3a.
Behind a barrier is not on a medium customarily used for software
interchange, which 3a requires.
> > Encrypted with a key you don't have is not the preferred form for
> > modification.
> Indeed, but why does it matter? In a CD is not the preferred form for
> making modifications either. In fact, in the CD, you can't modify it
> at all. What's *behind* encryption is the source code, along with the
> binary it accompanies.
On a CD is a preferred form for making modifications to it. You are assuming
"it" means one particular copy of the source code when in fact "it" means
the source code.
> >> And, if it's not a violation, what is it that makes the case of
> >> shipping programs in a locked enclosure different from shipping them
> >> in a locked computing device?
>
> > I honestly don't see what relevance this could possibly
> > have. Getting access to the source is a fundamental GPL right.
>
> That's the spirit. But where does the *letter* of the GPL state it?
3a says it.
> > By this argument, shipping a GPL'd work in ROM would violate the GPL
> > because you cannot easily modify that particular copy.
> I've already explained that the inability to modify what's in the CD
> is not a restriction imposed by whoever recorded the bits in there as
> a means to stop you from making modifications.
It makes no difference who imposes the restriction. Read section 7
carefully. If *anything* imposes restrictions on the recipient's exercise of
their GPL rights, you can't distribute.
> >> I ought to be entitled to modify any bit in the executable and
> >> expect that to have the same effect as modifying that bit on that
> >> executable on any other computer.
> > Nope, sorry. If this were true, you ought to be entitled to
> > modify a bit in
> > the Linux kernel and have it have the same effect as modifying
> > that Linux
> > kernel on my desktop.
> If your desktop is sufficiently similar, and the kernel binaries are
> identical, why should I not expect the same result to arise?
Because you have no way to get that software to run on my desktop, just as
you have no way to get that software to run on your Tivo.
> > Again, nonsense view leads to nonsense conclusions. The fix is to
> > reject the nonsense view. There are no special GPL rights to
> > particular copies of works or particular hardware.
> 2. You may modify your copy or copies of the Program or any portion
> of it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is pretty clear that no copy is special. In any event, this is a grant
of license, not a guarantee of ability. (Read the context.)
> >> The fact that it stops
> >> working as a result of TiVo's design to prohibit modification, rather
> >> than by any other differences in the computer (e.g., the absence of
> >> the signature checks), just goes to show that there is intent to
> >> impose further restrictions on modification of the software.
>
> > Intent is not the issue.
>
> Imposing further restrictions is the issue.
No, read section 7. The GPL does not just prevent you from imposing further
restrictions, it also prohibits you from distrbuting if *anything* imposes
such restrictions. Otherwise, you could get around the GPL just by having
someone else impose restrictions.
> > If the GPL says I can modify my distributed copy, then distributing
> > on CDROM is a GPL violation.
> It doesn't state "you must distribute sources in modifyable media", it
> says "you may modify your copies, and the distributor must not have
> imposed restrictions on your exercise of this right"
> If you can't modify your copies because others get in the way, too
> bad. If you can't just because the distributor stops you, there's a
> GPL violation.
You are now directly contradicting yourself. We agreed that if anything
prevented your recipients from exercising your GPL rights, that means you
cannot distribute. How you are saying so long as you don't stop them, you
can distribute. In fact, the former view is correct and the latter is wrong,
as GPL section 7 makes clear.
If the right/ability to modify a particular copy is a GPL right, then you
cannot distribute on CDROM.
> > It is mind-bogglingly obvious that any sort of "right to modify one
> > particular copy" is *not* a GPL right.
> Please read the license instead of assuming you know what it says.
> You clearly don't. See above.
You are confusing a grant of license with an assurance of ability. Section 2
is a grant of permission.
If we were to read "may modify your copy or copies of the Program or any
portion
of it" the way you suggest, that would mean that you must be able to modify
every single copy of the program that is distributed to you. This would make
distribution on CDROM a GPL violation, which you agree it isn't. So this
must be a grant of permission, rather than an assurance of ability.
> > You are wasting an awful lot of time and effort analyzing
> > things that have
> > *NO* GPL consequence at all.
> Let's just say I honestly hope you are right and I'm wrong.
I am, and you are.
DS
On Jun 27, 2007, "David Schwartz" <[email protected]> wrote:
> Behind a barrier is not on a medium customarily used for software
> interchange, which 3a requires.
Are you per chance claiming that you've never heard of anyone
receiving encrypted software in a CD, or pre-installed in a computer?
>> > I honestly don't see what relevance this could possibly
>> > have. Getting access to the source is a fundamental GPL right.
>>
>> That's the spirit. But where does the *letter* of the GPL state it?
> 3a says it.
It says the sources must accompany the binaries (check), must be
machine-readable (check), and must be on a medium customarily used for
software interchange (check).
Where does it say you have to be able to access the sources? Or the
binary, for that matter?
> It makes no difference who imposes the restriction. Read section 7
> carefully. If *anything* imposes restrictions on the recipient's
> exercise of their GPL rights, you can't distribute.
This is actually not what section 7 says. If it were so, the GPL
would forbid you from distributing any software whatsoever, because it
might reach someone in the US who would then be forbidden by law from
distributing it to someone in Cuba. It would forbid you from
distributing cryptography software, or DVD descrambling software,
because the software might reach someone in a country where their
distribution is illegal. Or it would forbid you from distributing
software that is covered by some patent in some distant country, just
because the software might reach a person there who might then be
stopped by the patent holder from distributing the software.
But the GPL doesn't forbid any such things.
The GPL stops you from distributing the software when you impose the
restriction yourself, or when you are required by a third party to
impose such a restriction. For example, when you accept a patent
license that states you won't permit downstream users to distribute
the software, then you become a party that impose restrictions. If
you don't have the source or written offer needed to comply with the
conditions of section 3, then you can't distribute the software. It's
in this kind of situation that section 7 kicks in.
>> >> I ought to be entitled to modify any bit in the executable and
>> >> expect that to have the same effect as modifying that bit on that
>> >> executable on any other computer.
>> > Nope, sorry. If this were true, you ought to be entitled to
>> > modify a bit in
>> > the Linux kernel and have it have the same effect as modifying
>> > that Linux
>> > kernel on my desktop.
>> If your desktop is sufficiently similar, and the kernel binaries are
>> identical, why should I not expect the same result to arise?
> Because you have no way to get that software to run on my desktop,
Aah, I misunderstood what you wrote. Yes, as long as you are entitled
to stop me from modifying software on your desktop, then I'm not
entitled to modify it.
However, once I'm entitled to make an identical change to the
identical software running on both your (or my) desktop and another
nearly-identical computer, if they behaved exactly the same before the
modification, I'm reasonably entitled to expect them to do behave
exactly the same after the modification. If they don't, and I find
out that it's because the party who distributed the software to me
introduced mechanisms to prevent me from modifying the software, how
is that not a "further restriction"?
>> 2. You may modify your copy or copies of the Program or any portion
>> of it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is pretty clear that no copy is special. In any event, this is a grant
> of license, not a guarantee of ability. (Read the context.)
Yes, it's a grant of license. And then, section 6 tells a licensee
that, when he distributes the software to someone else, she receives a
license to modify that copy of the software, as well as to make
further copies and modify them, and he must not impose any further
restrictions on the exercise of the granted rights. QED
> Otherwise, you could get around the GPL just by having someone else
> impose restrictions.
Oh, wow, really? Are you familiar with the Microsoft Novell deal? Is
this not exactly how they got around the GPL?
The only reason GPLv3 can oppose distribution under these conditions
is precisely the existence of the deal, which turns both Microsoft and
Novell parties of an arrangement to distribute the software in a way
that imposes further restrictions on the recipient's rights granted by
the license. Unfortunately, I'm told GPLv2 is vulnerable to this
particular deal.
Also remember that it's not enough for Microsoft or anyone else to
have patents that might be used to impose restrictions on others'
exercise of their rights for the GPL to say you can't distribute the
software. You must (voluntarily or not) accept a restrictive license
before section 7 kicks in and stops you from distributing the software
under the restrictions imposed on you.
> We agreed that if anything prevented your recipients from exercising
> your GPL rights, that means you cannot distribute.
I didn't agree to that, and now I've explained why this would be a
terribly stupid idea. That's just not how the GPL works.
Draw satisfaction from the fact that you're not giving legal advice
:-)
FWIW, I'm not either, IANAL.
> If the right/ability to modify a particular copy is a GPL right,
> then you cannot distribute on CDROM.
Who's stopping you from modifying the copy in a CDROM? Is it the
distributor? Did it set things up such that you wouldn't be able to
modify that CDROM? Or could it be just because nobody has found a way
to overcome the natural (?) limitation of CDROMs (or rather of CDR
drives?)? If you find it out, you're free to use it. In the mean
time, you can still create other copies of the software in the CDROM
and modify those.
> If we were to read "may modify your copy or copies of the Program or
> any portion of it" the way you suggest, that would mean that you
> must be able to modify every single copy of the program that is
> distributed to you.
No, it only means that the distributor must not impose restrictions on
my ability to modify those copies. The copyright holder says I can.
Both nature and distributor might have means to stop me from doing it.
Copyright holder can't override nature, but it can override the
distributor.
--
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}
On Wednesday 27 June 2007 22:37:42 Alexandre Oliva wrote:
> On Jun 27, 2007, "David Schwartz" <[email protected]> wrote:
> > Behind a barrier is not on a medium customarily used for software
> > interchange, which 3a requires.
>
> Are you per chance claiming that you've never heard of anyone
> receiving encrypted software in a CD, or pre-installed in a computer?
It isn't common. In fact, I can only think of *ONE* instance of this - that of
the original Quake 1 "Demo" CD that, when given the proper unlock codes,
contained the entire game, along with all previous idsoft games.
> >> > I honestly don't see what relevance this could possibly
> >> > have. Getting access to the source is a fundamental GPL right.
> >>
> >> That's the spirit. But where does the *letter* of the GPL state it?
> >
> > 3a says it.
>
> It says the sources must accompany the binaries (check), must be
> machine-readable (check), and must be on a medium customarily used for
> software interchange (check).
>
> Where does it say you have to be able to access the sources? Or the
> binary, for that matter?
Section 3 doesn't apply to this situation. However, other sections do. They
are distributing in line with the distribution requirement, but not
the "modification and copying" requirements. These are granted early in the
license and covered by the "no further restrictions" clause.
You have to be able to copy and modify the source code for it to comply with
the GPL.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
> Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass. This is not different from
> >> shipping binaries and sources in a CD inside a locked box that you
> >> can't open. You've received both, but how is the fact that you can't
> >> reach the source code (or the binaries) a violation of the GPL in this
> >> case?
>
> > Behind a barrier is not the preferred form for modification.
>
> Where does it state that there must not be a barrier? I see it saying
> the source must accompany the binary, under 3a.
>
> > Encrypted with a key you don't have is not the preferred form for
> > modification.
>
> Indeed, but why does it matter? In a CD is not the preferred form for
> making modifications either. In fact, in the CD, you can't modify it
> at all. What's *behind* encryption is the source code, along with the
> binary it accompanies.
>
> >> And, if it's not a violation, what is it that makes the case of
> >> shipping programs in a locked enclosure different from shipping them
> >> in a locked computing device?
>
> > I honestly don't see what relevance this could possibly
> > have. Getting access to the source is a fundamental GPL right.
>
> That's the spirit. But where does the *letter* of the GPL state it?
I stand by my claim that any obstacle to obtaining and modifying any copy of
the source code (and thus encumbering your ability to use it at all) would
be a violation of both the letter and the spirit of the GPL. (As expressed
in section 3.)
Until someplace you can't actually access the software is customarily used
for software interchange, ...
But I fear that your interpretation of section 7 is mostly correct. This is
a defect in the GPL. At least as I understood it, the intent was to force
distributors to remove any code for which there was a patent claim that
might threaten redistribution. Section 7 fails to do that.
While you are granted rights under copyright, section 7 does not prevent
people from using other laws (so long as they don't impose the restrictions
or agree to them) to hamer your right to redistribute (or for those who
receive a distribution from you to lawfully use the work).
It is quite difficult to actually arrange this. You would need something
like a third party to indemnify your customers without your having to agree
to such indemnification.
DS
On Jun 27, 2007, Daniel Hazelton <[email protected]> wrote:
> Section 3 doesn't apply to this situation. However, other sections
> do. They are distributing in line with the distribution requirement,
> but not the "modification and copying" requirements. These are
> granted early in the license and covered by the "no further
> restrictions" clause.
> You have to be able to copy and modify the source code for it to
> comply with the GPL.
Let's hope courts see it this way.
But then, why is it that I can't use hardware to stop someone from
copying or modifying the source code, but I can use hardware to stop
someone from copying or modifying the binary? Or is that not so?
Remember, section 2 talks about modifying *your* *copies* of the
Program, without any reference whatsoever as to whether they're in
source or object form.
--
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}
On Thursday 28 June 2007 00:45:18 Alexandre Oliva wrote:
> On Jun 27, 2007, Daniel Hazelton <[email protected]> wrote:
> > Section 3 doesn't apply to this situation. However, other sections
> > do. They are distributing in line with the distribution requirement,
> > but not the "modification and copying" requirements. These are
> > granted early in the license and covered by the "no further
> > restrictions" clause.
> >
> > You have to be able to copy and modify the source code for it to
> > comply with the GPL.
>
> Let's hope courts see it this way.
I'm sure they will. Section 0 of the GPLv2 states what the license covers.
Copying & modification are two of those things.
> But then, why is it that I can't use hardware to stop someone from
> copying or modifying the source code, but I can use hardware to stop
> someone from copying or modifying the binary? Or is that not so?
As has been repeatedly stated, on a TiVO or similar device they can stop you
from running a user-built binary. They cannot, and do not, stop you from
accessing the copy on the disc. They don't even prevent modification of it.
What they do is stop the hardware from running the modified form.
> Remember, section 2 talks about modifying *your* *copies* of the
> Program, without any reference whatsoever as to whether they're in
> source or object form.
I can't argue with this.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
On Jun 28, 2007, "David Schwartz" <[email protected]> wrote:
> Until someplace you can't actually access the software is customarily used
> for software interchange, ...
As in TiVo boxes? :-) :-)
> This is a defect in the GPL. At least as I understood it, the intent
> was to force distributors to remove any code for which there was a
> patent claim that might threaten redistribution. Section 7 fails to
> do that.
It's not intended to do that. The existence of a patent doesn't
render the Software non-Free. The patent holder's threats or
willingness to enforce it doesn't render the Software non-Free. It's
accepting a restrictive license, voluntarily or by means of a court
order, that does. And the GPL is not about anything but doing as much
as a copyright license can do to make sure the covered Free Software
remains Free for all its users. So, requesting licensees to not use
their patents to deny other users' freedoms is something a copyright
license can do. But since it can't affect patent holders that are not
copyright licensees, or any other legal mechanisms that non-licensees
could use to restrict users' freedoms, it remains silent about this,
rather than forcing licensees to comply with laws or avoid risks that
might not even apply to themselves.
> While you are granted rights under copyright, section 7 does not prevent
> people from using other laws (so long as they don't impose the restrictions
> or agree to them) to hamer your right to redistribute (or for those who
> receive a distribution from you to lawfully use the work).
I think that's correct, and IMHO that's how it's intended to be.
> It is quite difficult to actually arrange this. You would need something
> like a third party to indemnify your customers without your having to agree
> to such indemnification.
... and without making you a party in this collusion. Basically, if
you're involved in the process of denying users' freedoms, the GPL may
have teeth for you. If you're not, and you're not a licensee of code
present in that software, there's no way the GPL can stop you from
imposing whatever restrictions that law permits you to impose, if you
choose to do so. But the GPL won't impose restrictions on others just
in case their downstream users might become your next target.
--
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}
On Wed, Jun 27, 2007 at 08:08:08PM -0300, Alexandre Oliva wrote:
> On Jun 26, 2007, Jan Harkes <[email protected]> wrote:
>
> > GPLv2 section 3.
> > The source code for a work means the preferred form of the work for
> > making modifications to it.
>
> > I believe this states that the source code has to be in the preferred
> > form for making modifications and not some other form that sucks rocks.
>
> Yes, but in the scenario I proposed, the source code *is* in the
> preferred form for making modifications, it just so happens to be
> behind a barrier you cannot trespass. This is not different from
> shipping binaries and sources in a CD inside a locked box that you
> can't open. You've received both, but how is the fact that you can't
> reach the source code (or the binaries) a violation of the GPL in this
> case?
That was explained in next paragraph where I said that preventing access
sure sounds like a restriction on copying and modification, which is
where the GPL violation would be.
> As for making modifications, I'd like to take this opportunity to
> withdraw, for purposes of interpretation, my earlier agreement that
> TiVo permits modification, even though it doesn't permit modification
> in place. I don't see any distinction in US copyright law between
> modification in place and modification by creating a separate work.
That doesn't really matter because the GPLv2 makes a distinction between
source code and binary object code. For instance in section 1 where it
says that you may copy and distribute the program's source code.
In section 2 where it talks about modifications it at first doesn't seem
to distinguish between source and binary, but it doesn't grant the right
that the resulting modified program will actually work. And yes, you can
still modify the kernel binary on the Tivo harddrive, it just won't boot
with the standard bootloader.
But there is an explicit no warranty clause in the GPLv2. Which I
believe is a good thing. If the license tried to enforce usability, i.e.
"continued functioning of the modified object code is in no case
prevented or interfered with", then any time a new release of the
program causes a regression for some users this would be a license
violation.
> This distinction makes sense for some cases of modification of
> software, but it doesn't make sense for other copyrightable works,
> such as sculptures, paintings, drawings, etc.
>
> When you modify a sculpture, you're modifying it in place, and this
> requires as much copyright permission as creating a modified copy of
> it. Both count as modification.
And when you scribble in the margin of a book you are also modifying it,
so what. I don't think you even need copyright permission, although you
will probably get into trouble if the book was borrowed from a library.
I don't see the relevance in the context of this discussion.
> And if TiVo creates artificial
> obstacles to your modifying the copy of GPLed programs that ships in
> its devices, then I believe it counts as a restriction on
> modification.
You can modify the source, recompile it, even binary patch the kernel on
the Tivo's harddrive. None of that is restricted. What is restricted is
the freedom to run the modified object code on Tivo's hardware. That
right is not granted by the GPLv2, and fitness for any purpose is
explicitly disclaimed in the NO WARRANTY section.
... skipped a whole bunch, you actually repeated yourself a couple of
times but the same answer applied, GPLv2 does not grant the right to be
able to run the (modified) program on their hardware, and none of the
granted rights, to copy, distribute and modify, are restricted ...
> Here are variations of another scenario I proposed back then:
>
> - Tivoizing device ships with tivoized software, regardless of whether
> the corresponding sources are accessible to the end user or hidden
> inside the box, in a fully-encrypted disk that only that machine can
> read.
I'm assuming no written offer for access to the software is included.
Source are inaccessible, restricted the recipients rights to copy,
distribute and modify the source code, GPLv2 violation.
otherwise, source is accessible and recipient can copy, distribute and
modify.
> - Network authenticates the device with help of the built-in crypto
> device, and device requests feature-complete binaries in encrypted
> network sessions. It's in the fature-complete binaries that the most
> valuable improvements made by the tivoizer are, that they don't want
> to share with anyone else. Sources *are* available behind the same
> authentication machinery you don't can't get past. Whether the device
> chooses to download them into the encrypted device you can't get to ,
> to dispose of them right away or even leave them around, or it simply
> refrains from downloading the sources because it doesn't need them,
> the end result is the same: you've received the sources over the
> network, but you can't get to them.
If it doesn't download the sources then the binary is not accompanied by
the corresponding source code and since we assumed no written offer this
is a violation of section 3.
If it does download the source code but stores them into an encrypted
device or discards them then the user is restricted in his rights to
copy, distribute or modify the source code, and we have a violation of
section 6.
> Here's another variation:
Sigh, same problem, same solution.
> Does it seem to you that GPLv2 blocks any of these means to distribute
> your code without granting its users access to the source code?
Yes, section 6 doesn't allow blocking access to the source code as it
restricts the recipients rights to copy, distribute and modify that
source code, so we have a license violation and the vendor has no right
to modify or distribute the program or any work based on the program.
Jan
> Let's hope courts see it this way.
> But then, why is it that I can't use hardware to stop someone from
> copying or modifying the source code, but I can use hardware to stop
> someone from copying or modifying the binary? Or is that not so?
You can use the hardware to stop someone from copying or modifying some
particular copy of the source code, so long as there is some copy of the
source code they can copy and modify. You are equivocating between a
particular copy and any copy at all.
The GPL requires the source code to be provided in a customary way and be
the preferred form for making modifications. It grants you the right to copy
and distrbute the source code. One accessible copy and no copyright
impediments should be all you need. The "further restriction" section solves
the issue of various workarounds to this.
Having access to the source code, being able to copy and modify it, being
able to incorporate bits of the source code in other GPL projects -- these
are all fundamental GPL rights. I do not see how anyone can get away with
encumbering these.
> Remember, section 2 talks about modifying *your* *copies* of the
> Program, without any reference whatsoever as to whether they're in
> source or object form.
I agree. You have the legal GPL right to modify any copy of a GPL'd work,
provided no technical or authorization obstacles stand in your way. If the
source code is on CDROM, you cannot modify that particular copy even though
you have the legal right to modify "the source code". You have the right to
copy it to someplace where no obstacles prevent you from modifying it.
The GPL grants you a right of access to the source code that is a genuine
guaranteed ability. The GPL also grants you the right to modify the source
code, but that is a legal right, not a guaranteed ability.
The GPL does sometimes use the word "may" where it's not clear whether it
means you have permission or you must be able to. The general rule of
construction is that "may" means permission, unless there's some clear
indication to the contrary. The "may"s in sections one and two are
permisssion against a claim of copyright enfrocement. The "further
restriction" clause is, at it states, only on the exercise of *rights*
(which I think means those rights licensed to you under copyright law,
namely the right of distribution and copying).
DS
On Jun 28, 2007, Jan Harkes <[email protected]> wrote:
>> As for making modifications, I'd like to take this opportunity to
>> withdraw, for purposes of interpretation, my earlier agreement that
>> TiVo permits modification, even though it doesn't permit modification
>> in place. I don't see any distinction in US copyright law between
>> modification in place and modification by creating a separate work.
> In section 2 where it talks about modifications it at first doesn't seem
> to distinguish between source and binary, but it doesn't grant the right
> that the resulting modified program will actually work. And yes, you can
> still modify the kernel binary on the Tivo harddrive, it just won't boot
> with the standard bootloader.
> But there is an explicit no warranty clause in the GPLv2. Which I
> believe is a good thing. If the license tried to enforce usability,
Yup. But will courts see this as a valid excuse for effectively
denying users the ability to modify the copies of the GPLed programs
they run on tivoized devices, even though the means to accomplish this
are based on blocking the ability to run the modified executable,
which happens to not require permission from the copyright holder in
the US?
Even more so when the modified binary provably works just fine on
similar computers, and fails to work on the tivoizing device just
because mechanisms were introduced to stop the user from modifying the
behavior of the software that runs in the device? I.e., it fails
because you changed it, rather than because you broke it.
Couldn't this be understood by a court as an attempt to exploit a
loophole in the letter of the license, rather than as an intentional
permission to restrict the ability to run covered programs, an act
that the license phrases as "not restricted" and "outside its scope"
just because US copyright law doesn't demand permission from the
copyright holder to run programs, which results in permission to run
being outside the scope of a copyright license?
Anyhow, I didn't mean to restart this debate, I just wanted (as stated
above) to withdraw my earlier tentative agreement that "modification
in place" was something that could be forbidden without infringing
GPL.
>> When you modify a sculpture, you're modifying it in place, and this
>> requires as much copyright permission as creating a modified copy of
>> it. Both count as modification.
> And when you scribble in the margin of a book you are also modifying it,
> so what.
Maybe it's fair use, especially for a printed book, of which many
copies presumably exist.
> I don't think you even need copyright permission, although you
> will probably get into trouble if the book was borrowed from a library.
> I don't see the relevance in the context of this discussion.
Relevance was only to counter the argument that the right to "modify
in place", as some put it, was not covered by the GPL, "because that's
not how copyright law defines modification." I bought that argument
at first, but then I referred back to US copyright law and not only
failed to find supporting evidence for this argument, but actually
found opposing evidence. So I brought it up to make sure my tentative
agreement wouldn't be used in a court as an indication that the
argument holds water.
>> Here are variations of another scenario I proposed back then:
>>
>> - Tivoizing device ships with tivoized software, regardless of whether
>> the corresponding sources are accessible to the end user or hidden
>> inside the box, in a fully-encrypted disk that only that machine can
>> read.
> I'm assuming no written offer for access to the software is included.
Yup, that's the idea.
> Source are inaccessible, restricted the recipients rights to copy,
> distribute and modify the source code, GPLv2 violation.
So, the same standards would apply to the binaries: if they were
inaccessible, copyright holder could claim infringement under the same
grounds, right?
> If it doesn't download the sources then the binary is not accompanied by
> the corresponding source code and since we assumed no written offer this
> is a violation of section 3.
Except, perhaps, for this bit:
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
So, let's narrow the scenario to: tivoized machine downloads binary
from protected site, refrains from downloading sources that it could
download, user can still access and copy the binaries, but can't
obtain the sources because the machine opted not to get them.
Now, the user can't distribute the binaries, because doing so without
being able to get the sources to pass them on would be copyright
infringement. Would a court see this as a restriction on distribution
imposed by the distributor? Or by the copyright holder?
--
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}
On Jun 28, 2007, "David Schwartz" <[email protected]> wrote:
>> Let's hope courts see it this way.
>> But then, why is it that I can't use hardware to stop someone from
>> copying or modifying the source code, but I can use hardware to stop
>> someone from copying or modifying the binary? Or is that not so?
> You can use the hardware to stop someone from copying or modifying some
> particular copy of the source code, so long as there is some copy of the
> source code they can copy and modify. You are equivocating between a
> particular copy and any copy at all.
How do you reach this conclusion as to this kind of distinction?
> I agree. You have the legal GPL right to modify any copy of a GPL'd work,
> provided no technical or authorization obstacles stand in your way.
Hey, why stop at these excuses to stop someone from modifying copies
of the GPL? Why not list legal obstacles as well?
> If the source code is on CDROM, you cannot modify that particular
> copy even though you have the legal right to modify "the source
> code".
Yup.
> The GPL does sometimes use the word "may" where it's not clear whether it
> means you have permission or you must be able to. The general rule of
> construction is that "may" means permission, unless there's some clear
> indication to the contrary. The "may"s in sections one and two are
> permisssion against a claim of copyright enfrocement. The "further
> restriction" clause is, at it states, only on the exercise of *rights*
> (which I think means those rights licensed to you under copyright law,
> namely the right of distribution and copying).
... and modification and, depending on the jurisdiction, execution.
--
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}
On Jun 28, 2007, Alexandre Oliva <[email protected]> wrote:
> So, let's narrow the scenario to: tivoized machine downloads binary
> from protected site, refrains from downloading sources that it could
> download, user can still access and copy the binaries, but can't
> obtain the sources because the machine opted not to get them.
> Now, the user can't distribute the binaries, because doing so without
> being able to get the sources to pass them on would be copyright
> infringement. Would a court see this as a restriction on distribution
> imposed by the distributor? Or by the copyright holder?
I'm not sure my point was clear (not even to myself), so let me try to
clarify with a slightly different scenario.
Software vendor places Free Software program for sale on a web site.
Customers pay a fee and are granted access to a web page from which
they can download both binaries and sources. The web page encourages
them to download the sources first, because, one hour after the
download of the binary completes, the password that grants access to
the web page and to the downloadable bits is revoked.
Sloppy customer downloads only the binaries. Days later, they decide
they want to hire someone else to modify the software for them. Then
they realize they don't have the sources, and that they declined the
opportunity to have them. So they can't reasonably modify the
software, or distribute the software for another party to do it for
them. They got themselves into this situation by declining the source
download. The software distributor is not imposing a restriction,
it's the copyright holder that is, through the license.
Now, compare this with the case quoted above, in which the computer,
on behalf of the customer, declines the source download. Clearly the
license stops the user from distributing the software in these
circumstances, and practical matters pretty much stop the user from
modifying the software for any other purpose, but how is this
different from the unquoted case above? Can one actually claim that
the tivoizing vendor is imposing a further restriction, even though
the restrictions actually stems from a decision made by the user (or
rather by the computer acting on the user's behalf), and from the
copyright holder? How could this be phrased as a further restriction,
if the license already restricts distribution without source code, and
concedes that not having the source code makes it nearly impossible to
make modifications?
--
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}
Alexandre Oliva write:
> > The GPL does sometimes use the word "may" where it's not clear
> > whether it
> > means you have permission or you must be able to. The general rule of
> > construction is that "may" means permission, unless there's some clear
> > indication to the contrary. The "may"s in sections one and two are
> > permisssion against a claim of copyright enfrocement. The "further
> > restriction" clause is, at it states, only on the exercise of *rights*
> > (which I think means those rights licensed to you under copyright law,
> > namely the right of distribution and copying).
> ... and modification and, depending on the jurisdiction, execution.
Modification, yes. Execution, well, if the rules of a jurisdiction are
insane, you will get insane results from almost any contract.
Fortunately, the GPL makes it clear that execution is unrestricted for GPL'd
works, but does not style this as a GPL right. One would hope that
jurisidictions that have such strange rules would interpret the GPL to
effect the same result under their laws as was intended under the laws the
GPL was written with respect to, to the extent possible.
Treating ordinary use as a copyright privilege leads to nonsensical results
no matter what you do. For example, you get that I can drop copies of my
poem from an airplane and then sue anyone who reads it.
DS
On Jun 28, 2007, "David Schwartz" <[email protected]> wrote:
> Alexandre Oliva write:
>> > The GPL does sometimes use the word "may" where it's not clear
>> > whether it
>> > means you have permission or you must be able to. The general rule of
>> > construction is that "may" means permission, unless there's some clear
>> > indication to the contrary. The "may"s in sections one and two are
>> > permisssion against a claim of copyright enfrocement. The "further
>> > restriction" clause is, at it states, only on the exercise of *rights*
>> > (which I think means those rights licensed to you under copyright law,
>> > namely the right of distribution and copying).
>> ... and modification and, depending on the jurisdiction, execution.
> Modification, yes. Execution, well, if the rules of a jurisdiction are
> insane, you will get insane results from almost any contract.
> Fortunately, the GPL makes it clear that execution is unrestricted for GPL'd
> works, but does not style this as a GPL right.
Possible consequence:
http://fsfla.org/svnwiki/blogs/lxo/2007-06-29-gplv3-tivo-and-linux.en
> One would hope that jurisidictions that have such strange rules
> would interpret the GPL to effect the same result under their laws
> as was intended under the laws the GPL was written with respect to,
> to the extent possible.
Hopefully. But we know how justice is in the US, right? :-(
> Treating ordinary use as a copyright privilege leads to nonsensical results
> no matter what you do. For example, you get that I can drop copies of my
> poem from an airplane and then sue anyone who reads it.
Who was talking about reading? You can read programs as much as you
can read poems. But since you (normally) can't run poems, copyright
law doesn't talk about this, just like it doesn't distinguish source
from object code of a poem. But software is different. So different
that it's governed by a separate law in Brazil, which could be
qualified as a subclass of copyright law. And this law states that
running programs requires permission from the copyright holder.
If you find that odd, you may have an idea of how ludicrous patents on
software, business methods et al are. At least copyright regulation
of execution saves us from a few abusive EULAs, created with the
purpose of, let's see, regulating execution. And then, since it's
already there, why not use it for other restrictions beneficial to the
vendor that a copyright license couldn't establish?
--
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}
> > Treating ordinary use as a copyright privilege leads to
> > nonsensical results
> > no matter what you do. For example, you get that I can drop copies of my
> > poem from an airplane and then sue anyone who reads it.
> Who was talking about reading?
They are both ordinary use. It is crazy to treat the ordinary use of a work
as a copyright privilege. If you do this, you get insane results. For
example, coloring in the pages of a coloring book is, arguably, creating a
derivative work. But you don't need a license to do this, because it's the
ordinary use.
My poem from airplanes example is just an example. You get analogously crazy
results if you treat ordinary use of other works as a right under copyright.
> You can read programs as much as you
> can read poems. But since you (normally) can't run poems, copyright
> law doesn't talk about this, just like it doesn't distinguish source
> from object code of a poem.
You get lucicrous results from copyright laws if lawful physical possession
(of a copy made with consent of the copyright holder) does not grant the
right to ordinary use. You get the same ludicrous results with patents
(imagine if I can buy a product from IBM whose ordinary use always violates
an IBM patent and then IBM can sue me for it or if they use this to prevent
me from selling the product or giving it away).
> But software is different. So different
> that it's governed by a separate law in Brazil, which could be
> qualified as a subclass of copyright law. And this law states that
> running programs requires permission from the copyright holder.
So do I have to buy a program and then negotiate the right to run it
separately? That seems very crazy.
> If you find that odd, you may have an idea of how ludicrous patents on
> software, business methods et al are. At least copyright regulation
> of execution saves us from a few abusive EULAs, created with the
> purpose of, let's see, regulating execution.
Quite the reverse. If execution is a copyright right, then I might need to
agree to a license or conract to get it. If execution is not a copyright
right, then I am safe from such craziness.
> And then, since it's
> already there, why not use it for other restrictions beneficial to the
> vendor that a copyright license couldn't establish?
Jurisdictions that treat ordinary use as a copyright right are simply
insane. I am probably one of the stronger supporters of intellectual
property rights (copyright and patent, not necessarily UCC and EULA issues)
that you will find on this list, and I think that treating ordinary use as a
right is simply insane.
DS
On Jun 30, 2007, "David Schwartz" <[email protected]> wrote:
>> But software is different. So different
>> that it's governed by a separate law in Brazil, which could be
>> qualified as a subclass of copyright law. And this law states that
>> running programs requires permission from the copyright holder.
> So do I have to buy a program and then negotiate the right to run it
> separately? That seems very crazy.
If you buy the program, then you become the copyright holder.
I assume you meant buying a license. In this case, especially in the
case of off-the-shelf non-Free Software, the license likely grants you
permission to run the program, otherwise why would you pay for the
license anyway?
>> If you find that odd, you may have an idea of how ludicrous patents on
>> software, business methods et al are. At least copyright regulation
>> of execution saves us from a few abusive EULAs, created with the
>> purpose of, let's see, regulating execution.
> Quite the reverse. If execution is a copyright right, then I might need to
> agree to a license or conract to get it. If execution is not a copyright
> right, then I am safe from such craziness.
Whoever gave you the copy you lawfully obtained is already subject to
and/or able to offer a copyright license anyway. If the copyright
holder wants to restrict your ability to run the software, whether
copyright covers this case or not is absolutely irrelevant.
And evidently some businesses have interests in restricting your
ability to run software, not only to be able to sell you multiple
licenses of non-Free Software, but also to turn Free Software into
non-Free Software.
> I am probably one of the stronger supporters of intellectual
> property rights
How do you reason about binary-only software fulfilling the goal of
copyright? How does it deliver its part of the copyright deal with
society if, even after it goes public domain, still nobody can create
derived works from it because the source code remains unavailable?
http://www.fsfla.org/?q=en/node/128#1
--
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}