[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200706191928.13592.dhazelton@enter.net>
Date: Tue, 19 Jun 2007 19:28:13 -0400
From: Daniel Hazelton <dhazelton@...er.net>
To: Alexandre Oliva <aoliva@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@....linux.org.uk>,
Bernd Schmidt <bernds_cb1@...nline.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Ingo Molnar <mingo@...e.hu>, 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>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Tuesday 19 June 2007 13:06:17 Alexandre Oliva wrote:
> On Jun 19, 2007, Daniel Hazelton <dhazelton@...er.net> wrote:
> > On Tuesday 19 June 2007 04:04:52 Alexandre Oliva wrote:
> >> On Jun 19, 2007, Daniel Hazelton <dhazelton@...er.net> wrote:
> >> > On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote:
> >> >> GPLv3 forbids tivoization, therefore developer has requirement for
> >> >> tivoization in the license, therefore GPLv3 forbidding tivoization
> >> >> is bad.
> >> >
> >> > However, my argument is straight logic, nothing "circular" about it.
> >> > :) Replacing "X" in my logic path above with "tivoization" and
> >> > "license" with "GPLv3", as you've done, does produce a valid chain of
> >> > logic.
> >>
> >> Yes. Isn't it funny though that tivoization became necessary as a
> >> consequence of GPLv3 forbidding it?
> >
> > -ELOGIC
>
> I see. Try 'modprobe logic', it worked for me years ago ;-) :-D
Try using real logic rather than the logic of your religion.
> > It didn't become necessary as a result of the GPLv3 forbidding it.
>
> Which is why I said it was funny, because your inference chain stated
> *exactly* (with an implied "for the developers") that it did.
>
> Do you understand what an inference chain is? A => B, as in A implies
> B, which can also be read as A therefore B if A is known to hold.
Okay, since you want it in a specific language rather than as a set of bullet
points (which is what I used the => for)
Company X has requirement for restriction Y
=> License on product Z disallows restriction Y
=> Product Z loses Company X and the exposure use in their product gives
=> License on product Z is bad for the product
Understandable now?
> > there could be any number of reasons why "tivoization" is needed by
> > the manufacturer.
>
> This claim is false.
>
> Tivoization is when hardware manufacturer takes copyleft software and
> blocks updates by the user of the hardware.
By that definition you are correct.
> No single law so far has shown an example that even resembled to
> mandate copyleft software, and no contract could possibly establish a
> condition like this.
No argument here. What I was stating is that are legal (and other reasons) why
a company might have to lock down their software in a process similar
to "Tivoization".
> Therefore, this claim is false.
Only when you define a term as specifically as you have done
for "Tivoization". I should, perhaps, have used a different term - it would
then have been patently true. Though, at that point, you would likely have
argued that it wasn't "tivoization"
> > This whole bit was to point out that you were inferring circular
> > logic where none existed.
>
> There *is* circular logic is in place.
>
> The initial premise of this fallacy is that anti-tivoization is bad
> for the project.
>
> This is used to conclude that licenses with such provisions should be
> rejected.
>
> This is then used to conclude that there are fewer developers who
> would develop under such licenses.
>
> Which is then used to conclude that anti-tivozation is bad for the
> project.
Your view of the logic is, in this case, flawed. It's more along the lines of
what I've detailed above. Now, please, go away. You aren't doing
your "religion" any good. In fact, you are damaging it - repeatedly.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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