Message-ID: <orabuyfa7i.fsf_-_@oliva.athome.lsd.ic.unicamp.br>
Date:	Sun, 17 Jun 2007 20:11:13 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ingo Molnar <mingo@...e.hu>, Daniel Hazelton <dhazelton@...er.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>, david@...g.hm,
	Tarkan Erimer <tarkan@...one.net.tr>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Friesen <cfriesen@...tel.com>,
	Bernd Schmidt <bernds_cb1@...nline.de>,
	Robin Getz <rgetz@...ckfin.uclinux.org>,
	Rob Landley <rob@...dley.net>,
	Bron Gondwana <brong@...tmail.fm>,
	Al Viro <viro@....linux.org.uk>
Subject: mea culpa on the meaning of Tivoization (was: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3)

On Jun 17, 2007, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

>> > That accurately describes the FCC wireless rules.
>> 
>> AFAIK the FCC mandates not permitting the user to tinker.  It doesn't
>> mandate the vendor to retain this ability to itself.

> In practical terms it does since a recall/replacement in the event of
> rule changes is a bit impractical

Indeed.  But that's not a legal requirement, it's an economic reason.

"But I need to make a profit" or "But I need to reduce costs" is no
excluse to disrespect the GPL.


>> Therefore, per the above, FCC doesn't mandate tivoization.

> I'm sure you can find a definition to sort your goals whatever.

Are you per chance implying that I'm twisting the definition of
tivoization?


You know...  I now believe that would be correct.  I have indeed
twisted the definition of tivoization, and I'm sorry about that.
Which is not to say that I agree that the FCC or any other law
mandates tivoization, or that tivozation is a good thing or that it is
permitted by GPLv2.  Please read on.


After long conversations with RMS about the section on poisoned apples
and tivoization in my draft article about GPLv3 (Corresponding Sources
is the name of the section in
http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite) I had come
to the conclusion that Tivoization amounted to:

  denying the user of the computer the freedom to run modified
  versions of the Free Software in it, while retain this ability to
  oneself.

This understanding of mine had been strengthened by my understanding
of the wording and the rationale of GPLv3dd3, the wording about
technical restrictions in the rationales published along with
GPLv2dd2, and the various speeches in which the term was presented.

Nevertheless, I consulted with him and others highly involved in the
development of GPLv3 about some of the discussions going on here, and
got responses over the past few hours that surprised me.  A lot.

So I've just went back to that discussion about my article, and to
various other cases in which RMS, Eben Moglen and others presented
Tivoization, the rationales, and so on, and I came to the conclusion
that I had experienced a subtle but very significant misunderstanding.

I'm now convinced that a more appropriate definition would be:

  denying the user of the computer the freedom to run modified
  versions of the Free Software in it, by not sharing information as
  to how it could be accomplished.


This difference is very significant, and even more so for this
discusion, because it contradicts some of what I claimed before about
forms to use GPLed software where regulations require the user to be
unable to modify the software.


Let me start with an example: I bought a wireless router some time
ago, and it had a GNU+Linux distribution installed in it.  No source
code or written offer for source code, though.

Now, if I called the vendor next day and asked for the source code,
and they responded "sorry, I can't give you that.  I threw it all
away, such that I wouldn't be able to give it to you.", they would
still be disrespecting my freedoms, as well as the license, right?

You see where I'm going?  Now, if they gave me the source code, but I
still couldn't install modified versions, because they introduced
technical measures with the purpose of denying me this possibility,
then the inability to modify the program wouldn't be caused by
something like a physical impossibility (something like ROM), but
rather by an active measure to trample my ability to adapt the program
and run it for any purpose.

So, if I called them to ask how to install and run modified versions
of the GPLed programs, and they responded "sorry, I can't give you
that.  I threw it all away, such that I wouldn't be able to give it to
you.", they would still be disrespecting my freedoms, as well as the
license.

The reasons as to why they'd want to disrespect the freedoms don't
matter.  It could be "making a profit", "complying with the law",
"abiding by contractual restrictions", anything.  Imposing
restrictions to the exercise of the freedoms is not in line with the
spirit of the GPL, as such restrictions render the Software non-Free.


The conclusion?  Throwing keys away, or using split-key techniques, as
I have suggested as potential alternatives to ROM for compliance with
GPLv3 are not meant to be permitted by GPLv3.  There might be
practical advantages to compromising and permitting these techniques,
but that would amount to endorsing disrespect for users' freedoms, and
more, betraying those who licensed their works under GPLv1+ or v2+
with an intent to not permit these practices.  I don't think FSF is
willing to be part of this, and this is how it should be.

As for those who didn't mean the GPL this way, they can always grant
additional permissions, or simply refrain from enforcing the license
in these cases.


I apologize for my terrible misunderstanding, and for spreading it.

Hopefully this message will reach everyone I have misled.

I've tried to Cc: everyone who'd received copies of my mistaken claims
directly from me.  If I left you out by accident, please holler ;-)

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists