lkml.org 
[lkml]   [2007]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
From
Date
On Jun 17, 2007, "Jesper Juhl" <jesper.juhl@gmail.com> wrote:

> On 17/06/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> [snip]

>> Serious, what's so hard to understand about:

>> no tivoization => more users able to tinker their formerly-tivoized
>> computers => more users make useful modifications => more
>> contributions in kind

> I have to disagree.

Your analysis stopped at the downside of prohibiting tivoization. You
didn't analyze the potential upsides, so you may indeed come to
different conclusions, and they may very well be wrong.

It's very human to look only at the potential downside of an action
and conclude it's a bad action.

But it's more rational to look at the potential upside as well,
evaluate the likelihood of each in the grand scheme of things, and
then decide whether the potential upside will make up for the
potential downside.


> Let's say that for some reason I don't want the end users of my
> device to tinker with the software inside my device.

Ok, keep the *want* in mind. This is very important.


> Now I think you can agree to these things being positive:

Yes, even if I'd phrase them slightly differently.

> The only downside is that the end user purchasing the device can't
> install modified versions of the software on it.

And therefore you severely limit the number of end users who might
turn into contributors because of self interest in hacking the device
to suit their needs.


> Now let's try it in a GPLv3 universe. Since I can no longer create my
> device without having to allow the end user to install modified
> software on it

False assumption. You can create the device using GPLv3 software in
it. So your acccounting of necessary downsides is only one of the
possibilities. The other possibility would be to have the program in
ROM, of course, which would come with a completely different set of
downsides, but that would retain all of the "these things being
positive" you mentioned above.


And, remember, since you merely don't *want* the end user of the
device to tinker with the software, you have the option to do let them
do that.

And, if you do, they may find in themselves reasons and incentives to
change the software in the device, and the improvements are likely to
get back to the community and thus back to you. Everybody wins.

This is the upside that you left out from your analysis, and from
every other analysis that set out to "prove" that anti-tivoization is
bad that I've seen so far.

It appears that people are so concerned about whatever little they
might lose from requiring respect for users' freedoms that they don't
even consider what they might win, and that they *would* win if at
least some of the vendors were to make an choice more favorable to
their users and the community.

--
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}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-18 01:55    [W:0.603 / U:0.236 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site