lkml.org 
[lkml]   [2007]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

* Alexandre Oliva <aoliva@redhat.com> wrote:

> On Jun 14, 2007, Ingo Molnar <mingo@elte.hu> wrote:
>
> > * Alexandre Oliva <aoliva@redhat.com> wrote:
>
> > you are not "entitled" to dictate the hardware's design (or any
> > other copyrighted work's design),
>
> Agreed.

hey, that's progress. If you concede this single point then your
arguments about the Tivo situation all fall like domino stones. Just
watch it happen please:

> > By your argument we'd have to put the following items into the
> > license too:
>
> No, you're confusing two very different situations.
>
> In the case of TiVO, it's getting out of its way to make sure users
> can't enjoy one of the freedoms that the license says it ought to pass
> on.

the GPLv2 license says no such thing, and you seem to be mighty confused
about how software licenses work.

the GPL applies to software. It is a software license.

the Tivo box is a piece of hardware.

a disk is put into it with software copied to it already: a bootloader,
a Linux kernel plus a handful of applications. The free software bits
are available for download.

the Tivo box is another (copyrighted) work, a piece of hardware.

so how can, in your opinion, the hardware that Tivo produces, "take
away" some right that the user has to the GPL-ed software? Because they
distribute the software and the hardware in the same package, and
because the hardware (as _ALL_ hardware on this planet) has certain
limitations? It was _your_ choice to buy that particular
hardware+software combination, with whatever limitations the hardware
has. One such limitation of the hardware might be that its color is
butt-ugly pink. Another limitation might be that the buttons on it are
too small for elderly people to press. A third limitation might be that
it's not a general purpose computer and that it's not freely
programmable by the end user. Bugger, what did you expect? Why didnt you
buy a green PVR? Why didnt you buy a PVR with larger buttons? Why didnt
you buy a general purpose computer? Did perhaps the Tivo look like a
nice general purpose PC to you when you bought it?

> In the cases you mentioned, the company would have to get out of its
> way to put the other parties on equal grounds.

how about quoting what i wrote and rebutting it specifically if you
disagree with it, instead of writing a non-sequitor generality? You are
involved in compiler development, so you should have the mental ability
to follow logical arguments and you should be able to conduct a
meaningful and objective discussion. Lets look at one of the examples i
gave you:

> > - free access to all the hardware diagnostics tools that the
> > hardware maker has. (Without that it might be impossible to modify
> > the software as efficiently as the hardware maker's own engineers
> > can do it.)

by your argument, the user has some "right to modify the software", on
that piece of hardware it bought which had free software on it, correct?
By your argument, the "right to modify the software" becomes meaningless
if you cannot soft-upgrade your Tivo, if you have solder off the ROM to
install your own ROM with a bootloader that does not do the SHA1 check,
correct?

But by that _very same argument_, you are hindered _much more_ by not
having proper hardware diagnostics tools and no access to hardware
specifications. If you dont know how the hardware works, you cannot fix
bugs in the software. So by your argument, the user has an inherent
right to get on equal footing with the hardware manufacturer to modify
the software on that specific hardware? There's no ifs and when. "having
to solder off the ROM" is a "restriction on modifiability" just as much
as "having less information about the hardware's inner workings". In
fact, ask any kernel developer, "having to solder off the ROM" is a lot
_smaller_ restriction than "having no information about the hardware's
inner workings".

Ingo
-
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-15 01:53    [W:0.531 / U:1.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site