Hmm... Really,it is damn too much time to wait! It's really better idea

to replace the code of this person as said before instead of waiting

such  90+ years!
-

exactly, however as others are pointing out, there are a lot of active

developers who do not agree with some of the key points of the GPLv3

(including Linus), so until you convince them that the GPLv3 is better it

really doesn't matter how hard it is to deal with the people who you can't

contact.
David Lang

-

Last heard, Linus was quite impressed with the toned down version of

the final draft of GPLv3. I think Linus, and other major developers

should make their stand on this issue clear so that the kernel

community can discuss the future steps.

-

Yep, the GPLv3 probably will release around July time. So;luckily, we

had very little time to see the final decision about it :-) I hope we

should upgrade to GPLv3 and Sun should "Dual License" the OpenSolaris

via GPLv3 (or at least,GPLv3 should be CDDL compatible.). So,we should

have more fruits (like ZFS,DTrace etc.) ;-)
-

I don't think that upgrading to GPLv3 just for the sake of tools

present in some other software should be the reason. We are capable

enough of developing our own tools, and many experienced people are

working on equivalent(etx4 etc.,) and much sophisticated tools for the

linux kernel.

-

It is not because of the sake of the tools and we have no capable enough

developers. It's just about an example that came to my mind, as I

mentioned before and also,it is the same thing as we, all the time, did.

I mean getting and sharing codes from many different open source

projects like BSD and countless others. So, OpenSolaris makes no

difference at this.
Regards,
Tarkan

-

I don't think that switch to GPLv3 can be described as upgrade.  I certainly

have no intention to do that to my code; some of it I might release under BSD

license, and that can be used in any project.  The rest of the kernel stuff

I've done (and that's the majority of my contributions) is under GPLv2 *only*.

-

I was impressed in the sense that it was a hell of a lot better than the

disaster that were the earlier drafts.
I still think GPLv2 is simply the better license.
I consider dual-licensing unlikely (and technically quite hard), but at

least _possible_ in theory. I have yet to see any actual *reasons* for

licensing under the GPLv3, though. All I've heard are shrill voices about

"tivoization" (which I expressly think is ok) and panicked worries about

Novell-MS (which seems way overblown, and quite frankly, the argument

seems to not so much be about the Novell deal, as about an excuse to push

the GPLv3).
		Linus

-

Btw, if Sun really _is_ going to release OpenSolaris under GPLv3, that

_may_ be a good reason. I don't think the GPLv3 is as good a license as

v2, but on the other hand, I'm pragmatic, and if we can avoid having two

kernels with two different licenses and the friction that causes, I at

least see the _reason_ for GPLv3. As it is, I don't really see a reason at

all.
I personally doubt it will happen, but hey, I didn't really expect them to

open-source Java either(*), so it's not like I'm infallible in my

predictions.
				Linus
(*) And I've been pushing for that since before they even released it - I

walked out on Bill Joy at a private event where they discussed their

horrible previous Java license.

-

Thanks for making things more clear :-) Some really strong indications

that Sun is very willing to,at least, "Dual-License" the OpenSolaris

with GPLv3. I think; in a very short time; we will see when the GPLv3

finalized and released.
Regards,
Tarkan

-

that would certainly be a good and productive move from them. Note the

issue that others have pointed out to you: OpenSolaris is probably more

interested in picking up code from Linux than the other way around! :-)

You mentioned "dtrace" and "ZFS". Firstly, Linux already has a "dtrace"

equivalent. Secondly, ZFS might be interesting in theory, although our

prior experience of having compatibly-licensed filesystems ported over

to Linux has been pretty negative: XFS ended up being an integration

nightmare - and that doesnt have to do anything with the qualities of

XFS (it's one of the cleanest Linux filesystems, if not the cleanest),

the problem is that components within a kernel are very tightly

integrated and rarely does it make sense to port over more than just

drivers or maybe libraries. And that's i guess what OpenSolaris lacks

and which i suspect it is mostly interested in: lots of nice Linux

drivers ;-) XFS, the largest Linux filesystem is 100K lines of code -

and ZFS (i've never seen it) is very likely smaller than that. Linux

drivers on the other hand, as of today, are _3.7 million_ lines of code

and enable Linux to run on 99% of the hardware that is produced today.

Guess which one has the larger strategic significance? ;-)
	Ingo

-

Per this reasoning, Sun wouldn't be waiting for GPLv3, and it would

have already released the OpenSolaris kernel under GPLv2, would it

not? ;-)
--

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}

-

Umm. You are making the fundamental mistake of thinking that Sun is in

this to actually further some open-source agenda.
Here's a cynical prediction (but backed up by past behaviour of Sun):
 - first off: they may be talking a lot more than they are or ever will

   be doing. How many announcements about Sun and Linux have you seen over

   the years? And how much of that has actually happened?
 - They may like open source, but Linux _has_ hurt them in the

   marketplace. A lot.
   They almost used to own the chip design market, and it took quite a

   long time before the big EDA vendors ported to Linux (and x86-64 in

   particular). But when they did, their chip design market just basically

   disappeared: sparc performance is so horribly bad (especially on a

   workstation kind of setup), that to do chip design on them is just

   idiotic. Which is not to say that there aren't holdouts, but let's face

   it, for a lot of things, Solaris is simply the wrong choice these days.
   Ergo: they sure as hell don't want to help Linux. Which is fine.

   Competition is good.
 - So they want to use Linux resources (_especially_ drivers), but they do

   *not* want to give anything back (especially ZFS, which seems to be one

   of their very very few bright spots).
 - Ergo: they'll not be releasing ZFS and the other things that people are

   drooling about in a way that lets Linux use them on an equal footing. I

   can pretty much guarantee that. They don't like competition on that

   level. They'd *much* rather take our drivers and _not_ give anythign

   back, or give back the stuff that doesn't matter (like core Solaris:

   who are you kidding - Linux code is _better_).
End result:
 - they'll talk about it. They not only drool after our drivers, they

   drool after all the _people_ who write drivers. They'd love to get

   kernel developers from Linux, they see that we have a huge amount of

   really talented people. So they want to talk things up, and t...
[ message continues ]

Err, no.  I was merely questioning Ingo's reasoning that Sun wanted

Linux's drivers as badly as he made it seem.  All the fuss about

waiting for and going to GPLv3 wouldn't get them that.  Moving to

GPLv2 would, and still, they aren't doing it.  That was my point.
FWIW, I share most of your assessment and wait-and-see attitude about

Sun's situation.
--

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}

-

Hi Linus,
Definitely. They already began to pull some people like Ian Murdock. And

I'm really very disappointed of this move,Ian did. Especially, such a

person who has very good reputation and high profile in the Linux

Community. He immediately shut down his company (also leaved

Linux-Foundation) and joined to sun. After joining, he made statements

like "How to make Solaris more like Linux ?" etc. Like a 40 years

employee at Sun. Another interesting thing is the timing of this hiring.

One more time,agreed ;-)
Regards,
Tarkan

-

FYI, Jonathan Schwartz' response:
Linus,
First, I'm glad you give credit to Sun for the contributions we've

made to the open source world, and Linux specifically - we take the

commitment seriously. It's why we freed OpenOffice, elements of Gnome,

Mozilla, delivered Java, and a long list of other contributions that

show up in almost every distro. Individuals will always define

communities, but Sun as a company has done its part to grow the market

- for others as much as ourselves.
But I disagree with a few of your points. Did the Linux community hurt

Sun? No, not a bit. It was the companies that leveraged their work. I

draw a very sharp distinction - even if our competition is

conveniently reckless. They like to paint the battle as Sun vs. the

community, and it's not. Companies compete, communities simply

fracture.
And OpenSolaris has come a very long way since you last looked. It and

its community are growing, as a result of more than ZFS (although we

seem to be generating a lot of interest there, not all intentional) -

OpenSolaris scales on any hardware, has built in virtualization, great

web service infrastucture, fault management, diagnosability, and tons

more. Feel free to try for yourself (and yes, we're fixing

installability, no fair knocking us for that.)
Now despite what you suggest, we love where the FSF's GPL3 is

headed. For a variety of mechanical reasons, GPL2 is harder for us

with OpenSolaris - but not impossible, or even out of the

question. This has nothing to do with being afraid of the community

(if it was, we wouldn't be so interested in seeing ZFS everywhere,

including Linux, with full patent indemnity). Why does open sourcing

take so long? Because we're starting from products that exist, in

which a diversity of contributors and licensors/licensees have rights

we have to negotiate. Indulge me when I say It's different than

starting from scratch. I would love to go faster, and we are all doing

everything under our control to accelerate progress. (Remem...
[ message continues ]

Really very very interesting! This words reminded me the same dialogues

and affair, between "Linus" and "Steve Jobs", that have been happened

several years ago :-)
Regards,
Tarkan

-

Yep, it is clear that sun needs more things like drivers etc. to make

OpenSolaris more usable and user friendly. Here is an article about this

subject and some thoughts of Ian (Murdock) about it ;-)
http://www.zdnet.com.au/news/software/soa/Sun-hopes-for-Linux-like-Solar...
-

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Having just got my first Sun box (one of those 48 disk Thumper machines)

I can say it's very interesting in practice too.  The admin tools for

zfs are a dream to use (unlike just about everything else on Solaris

which is a bugwards compatible nightmare to use) and the attitude of

checksumming everything on to disk and checking that those checksums

match on the way back out presses my "do your own safety checking and

don't trust the hardware" buttons very much the right way - especially

with that much hardware in there.
I would love to see Sun GPL3 OpenSolaris, not so much for the code

itself (maybe not portable into Linux) but for the clarity it would

give to the patent position.  The patent peace would be portable back

to GPL2.
Bron.

-

In a strange twist, the last-call draft contains a clause that

expressly permits some forms of "tivoization", provided a suitable

contractual arrangement exists ("Basic Permissions", second

paragraph).
Now a lot of the free software market follows this "sell yourself into

slavery" model (and even the FSF recommends to make money this way),

but I'm not sure if it's a good idea to state it so plainly in the

license.

-

Linus Torvalds wrote:

[ snip ]
One thing that would make that easier in the future is if contributers

at least started to dual-license their submissions.  I.e. if instead

of "GPL version 2", one could say "GPL version 2 or GPL version 3".

It isn't the same thing as the problematic "GPL version 2 or later",

because the developer is not agreeing to an unseen license (GPLv4,

etc).  What it does do is make it easier to move to GPLv3 a few years

from now, if that is decided then, as a significant fraction of the

code will already be GPLv3 compatible.  That way, if a reason is ever

found to move to v3, at least some of the work will already be done.
  - Jim Bruce
-

Good luck convincing all contributors to do that.
Personally I'm happy with GPL v2, and I for one won't be

dual-licensing anything I contribute until I see a clear benefit of

doing so (and I don't yet).
In any case, this whole debate is still a bit premature since GPL v3

has not even arrived in its final form yet.
--

Jesper Juhl <jesper.juhl@gmail.com>

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

-

Well, it's something that pro-GPLv3 people can do right now, instead of

just lobbying/complaining.  Given 1000 developers, if 400 start dual

licensing now, and down the road some compelling reason for GPLv3 does

arise (read: a lawsuit with teeth), that's 600 people you need to

contact/convince to change, not 1000.  This is made more interesting by

that fact that 40% of the kernel code is already "GPLv2 or later", as 
Well, all my personal (non-kernel) stuff is still GPLv2 only right now

(Linus' opinion is what convinced me that "or later" is dumb), and like

many I disliked the original GPLv3 draft.  I'm willing to wait until the

final one is out though, and I think my libraries will end up being

dual-licensed, with contributions required to be dual-licensed.  I want 
Agreed.
  - Jim Bruce

-

Ditto.
	Jeff
-

GPLv2 probably forbids Tivoisation anyway. Which is good IMHO even if not

yours 8)
-

^^^^^^^^
Now that is a bit waving in the air. GPLv2 forbids Tivoisation

theoretically but practically it didnt stop them doing it practically.

I agree with Linus that software licenses should have their influence

only on the software part and leave the freedom of the hardware on

which the software runs to the hardware manufacturers.
But was it the goal of GPLv2??
And what does Andrew Morton think of all this? I really want to know

his opinions....

-

A law never stops anybody from doing anything.  Enforcing the law does.
First of all, let's not confuse civil with criminal law:
Most variants of copyright infringement are a civil, not criminal matter.

This means the state has no interest in enforcing the, it's your job to sue

for damages and a restraining order if you want to exercise these rights

(some people choose not to), and you have to have standing (I.E. be a holder

of one of the infringed copyrights, or a designated legal representative

thereof) in order to sue.  If none of the copyright holders sue to stop it,

then it doesn't get stopped no matter how blatantly infringing it is.  Did

anybody even bother to send Tivo a cease and desist?
Erik Andersen burned himself out trying to enforce the copyrights on BusyBox

before Pamela Jones hooked that project (and uClibc) up with the SFLC.

Harald Welte's been burning the candle at both ends with gpl-violations.org,

but he's focusing on stuff sold in Germany.
As for anti-tivoisation, you can make a case that your signed binary is a

derived work of the GPL source code just like a non-signed binary is,

therefore the signing key is part of the source code used to create that

binary, therefore GPLv2 requires the signing key be handed over on request.

(I don't know if you'd WIN, I just know you could reasonably argue it in

court and probably get past the inevitable initial motions to dismiss.)
GPLv2 is a nice, elegant license.  It's not perfect but it's very simple for

what it does.
GPLv3 is not simple, not elegant, and contains numerous of special cases.

Lots of the programmers here have an instinctive aversion to it because it

reads like bad code.  We don't necessarily have to program in legalese to

sense bad code in that language, at least compared to a "good code" example

we've been using for some time.
Rob

-

They've never been given permission and there is no caselaw yet, doesn't

mean they are allowed to.
GPL2 actually in some ways was saner than GPL3 on this - you could

sensibly argue the key was part of the source/build environment but it

didn't then get muddled in with questions like ROMs which the new GPL3

wording is a bit messy about still.
Alan

-

Are you sure?  Tivo went and got a FSF "verification" of their system a

number of years ago and got their blessing that what they were doing was

just fine with regards to the GPLv2.
This is one reason Tivo's lawyers were so perplexed when the FSF then

turned around and made their company's name into a term to describe DRM

stuff and started preaching how it was so bad.  It seemed to be in

direct crontridiction from what they had previously been told by the

very same people.
Now yes, they didn't consult with the individual owners of the kernel,

who might hold different views as to if v2 covers keys like you have

stated in the past, but the FSF's position in this area does hold some

ammount of weight, especially in court if it were to come to that.
thanks,
greg k-h

-

The authors position does have rather a lot of weight too. Especially as

they have been made plain to Tivo and various other relevant parties.
Alan

-

I have yet to see Linus make a statement on these matters with which

I didn't agree.

-

The OpenSolaris community has already stated that they do not want to

accept GPLv3, why not discuss this with them if you want to try to
I think the transfer would be more the other way, we have a zillion more

things that they do not than the other way around.
thanks,
greg k-h

-

It was just an example came to my mind at first when thinking about

"Dual Licensing" or upgrading Linux Kernel to the GPLv3. Yeah maybe,the

"OpenSolaris Community" do not want GPLv3. But; IMHO, it is in the hands

of "Sun" not the "OpenSolaris Community".
Regards,
Tarkan

-

Perhaps.  However, since the only thing in hands of your kind of advocates

is best not mentioned on a family-friendly maillist, may I suggest taking

that exciting thread to more appropriate place?

-

I don't think that this thread is going unfriendly or harmfully.

However, what is your suggestion ?

-

if you want to change the minds of the OpenSolaris community, i'd

proffer that it's perhaps more efficient to talk to them, not to the

linux-kernel mailing list. Thanks,
	Ingo

-

I do not want to and try to change anyone's mind: nor the Open Solaris

Community nor the Linux Community. Just, I asked simple question and

included a simple example in it. Son, including an example related to

OpenSolaris does not mean that I want to push OpenSolaris things. That's

all.
Regards,
Tarkan

-

actually, what you said was this:
" I hope we should upgrade to GPLv3 and Sun should "Dual License"

  the OpenSolaris via GPLv3 (or at least,GPLv3 should be CDDL

  compatible.). "
and to that the answer was:
" The OpenSolaris community has already stated that they do not want to

  accept GPLv3 [...] "
in other words: your hypothetical is false today. You called us to do a

specific action, but why did you then include a factually false

'example' to underline that point of yours? Or if you simply did not

know about the OpenSolaris community's position beforehand, why dont you

just admit that and withdraw from that line of argument gracefully?
	Ingo

-

Why don't you include the last sentence I wrote: "So,we should have more

fruits (like ZFS,DTrace etc.) ;-) "

So, that's why I said it. Because, as all the time, we did it: Importing 
As I mentioned in my previous posts: This is **not** in the hands of the

"OpenSolaris Community" to make and apply such decision. Sun itself

**will decide** it. Also, there are strong indications that Sun is very

interested to make "OpenSolaris" at least "Dual-Licensed" with GPLv3.
Regards,
Tarkan

-

You might as well have said "the moon is made out of cheese" and i'd not

have quoted it either. Why? Because it's irrelevant to the fundamental

point that was raised and which you keep ignoring: that the only

"example" you cited is a hypothetical that is currently false. In any

case, speculation about what Sun might or might not do, up until the

point it actually does it, is not something i feel compelled to do

anything over, so please stop wasting my time by Cc:-ing me. Thanks,
	Ingo

-

I think, you do not want to understand what I really  mean. OK,I

stopping here. Because, you already wasted a lot of my time via always

not understanding what I really mean.
Regards,
Tarkan

-

"future steps"?  Hah.
My code is going to stay GPLv2 as the v3 license is horrible for kernel

code for all of the reasons I have said in the past, plus a few more

(what, I can make an "industrial" product but not a commercial one?

That's horrible...)
thanks,
greg k-h

-

^^^^^^^^^^^^^

What exactly in GPLv3 forbids you from making a commercial product?

-

Nothing "forbids" me, it's just the artifical distinstion of the two is,

in my opinion, stupid and foolish.  You are trying to define use-cases

to justify their notion that you must give up the hardware keys for one

type of device, yet not for another.
Even the people that feel that v2 says you need to give up the keys

think this is dumb.  But we've been through all of that before (see

previous long thread about v3 and why the kernel developers hate it, it

all still applys to the final draft.)
greg k-h

-

You mean all the misunderstandings? ;-)
--

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}

-

I see the smiley, but I hate it how the FSF thinks others are morons and

cannot read or think for themselves.
Any time you disagree with the FSF, you "misunderstand" (insert

condescending voice) the issue. 
_Please_ don't continue that idiocy. Disagreement and thinking that the

FSF is controlling and putting its fingers where they don't belong is

_not_ misunderstanding. It's just not "blind and unquestioning obedience".
			Linus

-

Look, there was room for misunderstandings in earlier drafts of the

license.  Based on the public comments, the wording was improved.  I'd

like to think the issues that arose from misunderstandings of the

earlier drafts are no longer an issue.  Is it not so?
Keeping on making false claims about the license drafts can be one of

two things: misunderstandings, out of ambiguity in the text or

preconceptions, or ill intentions.  I'd rather believe it's the

former.
Now, of course you can look at the licenses and decide that you never

agreed with the spirit of the GPL in the first place, and that GPLv2

models better your intentions than GPLv3.
Your assessment about sharing of code between Linux and OpenSolaris

very much makes it seem like that the spirit of sharing, of letting

others run, study, modify and share the code as long as they respect

others' freedoms, has never been what moved you.  Rather, you seem to

perceive the GPL as demanding some form of payback, of contribution,

rather than the respect for others' freedoms that it requires.  In

fact, you said something along these lines yourself many months ago.
With this different frame of mind, it is not surprising at all that

you don't find GPLv3 a better license.  With different goals in mind,

reasonable people can reach different conclusions.  But claiming that

GPLv3 is changing the spirit of the license, or that it prohibits

certain kinds of software, is plain false.  In fact, the spirit has

always been described in its preamble, and it didn't change at all:

it's all about respecting others' freedoms.
Sure, this evokes a number of other nice behaviors in various players,

and it's clear to me that it's in these other nice behaviors that you

seek when you choose GPLv2.  There's nothing inherently wrong in that.
However, it seems to me that GPLv3 would do an even better job at

serving these goals than GPLv2, even if the holes v3 plugs that

enabled players to disrespect others' freedoms might steer away the

participants w...
[ message continues ]

No. The anti-DRM language is still there, and no, it was never a

misunderstanding. Now it's been limited to "consumer devices" (after I

pointed out some of the _obvious_ problems with the original language),

and the only people who called anything a "misunderstanding" were the ones

that tried to point to *other* points in the license altogether (ie there

was also a "drm section", which didn't really seem to say anything much at

all).
Rms calls it "tivoization", but that's a word he has made up, and a term I

find offensive, so I don't choose to use it. It's offensive because Tivo

never did anything wrong, and the FSF even acknowledged that. The fact

that they do their hardware and have some DRM issues with the content

producers and thus want to protect the integrity of that hardware.
The kernel license covers the *kernel*. It does not cover boot loaders and

hardware, and as far as I'm concerned, people who make their own hardware

can design them any which way they want. Whether that means "booting only 
No, it was not the former. And I think the whole "the kernel developers

misunderstand the license" crap that the FSF was saying (several times)

was very trying to confuse the issue: the FSF knew damn well which part of

the license was obnoxious, they just tried to confuse the issue by

pointing to *another* part of the license.
And this is again the same *disease*. You claim that I "misunderstood" the

"spirit of the GPL".
Dammit, the GPL is a license. I understand it quite well. Probably better

than most. The fact that the FSF then noticed that there were *other*

things that they wanted to do, and that were *not* covered by the GPLv2,

does *not* mean that they can claim that others "misunderstood" the

license.
I understood it perfectly fine, and it fit my needs. So tell me: who is

the more confused one: the one who chose the license fifteen years ago,

and realized what it means legally, and still stands behind it? I don't 
I have said *exactl...
[ message continues ]

It was claimed that GPLv3 would forbid implementations of DRM.  That's

just plain false.  If you don't think so, please show what terms in

the latest draft prohibit DRM (as opposed to merely making it

ineffective, a necessary consequence of abiding by the spirit of all
Another misunderstanding.  The FSF never said TiVo didn't do anything

wrong.  It only said it didn't think there was a license violation.  I

personally disagree with that assessment, but IANAL.
Anyhow, deciding whether it's right or wrong is not the same as

deciding whether it's legal or illegal.  Law doesn't define what's
When they choose to include a copy of the kernel in their hardware

that they can modify but others can't, they're failing to comply with

the spirit of the license.  For brevity, I won't repeat the quotes

from the GPLv2 preamble, that I just included in the message I sent to

Lennart Sorensen in this same thread.  Can you justify how you came to

the conclusion (if you did) that TiVo is abiding by the spirit of the
Wow, I didn't see that coming.  Public admission of ill intentions?
Let me see if I got this right.  There was a section entitled

"3. Digital Restrictions Management" in GPLv3dd1.  Are you saying

that, when people complained about the DRM clause, they actually meant

the provisions in "1. Source Code", that established a requirement to

include the source code corresponding to functional signatures, namely
Please watch your tone.  If you find offense at the allegedly

condescending tone in which the FSF says "misunderstanding", how do

you expect me and the FSF to take this?
It is also odd that you claim the right to be entitled to your own

opinion and reading about stuff, while denying myself the same right.

Please don't do that.  I have a mind of my own, and the fact that I

reach similar conclusions doesn't make me a parrot.  Even more so when
You are definitely confused.  You're talking about the legal terms,

while I'm talking about the spirit.  The legal terms tried to reflec...
[ message continues ]

Yes. I said that multiple times. It was obvious. But people didn't listen.
It's now in Section 7, or whatever.
The section 3 never mattered.
		Linus

-

One could even add that "tit-for-tat" appears to be the best strategy

in game theory for continuous runs of the prisoners dilemma.  At times I

wonder why game theory isn't taught in schools yet - it might shorten

discussions like these.
Jörn
--

All art is but imitation of nature.

-- Lucius Annaeus Seneca

-

It is, indeed.
Now the remaining piece of the proof is to show that the GPLv2 is

tit-for-tat.
--

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}

-

[ Gmail did horrible things to the original post by giving it a base64

content transfer encoding, so majordomo@vger dropped it. It's just

an off-topic digression, but I cared enough to resend anyway, fwiw. ]
Tit-for-tat is the best *deterministic* strategy when playing

iterated prisoner's dilemma. But note that "deterministic" and

"rational" are not adjectives that go well with "humans", and

most real-world (social) situations are noisy environments --

miscommunication and misunderstandings are the usual noise.

A double-D noise perceived by any player would throw a

tit-for-tat-playing couple into a perennial spiral of D's, for example,
Yes, and no.
Yes - for teaching game theory (and its social relevance) in schools;

and add behavioral economics to this list :-)
No - it doesn't shorten discussions, however. And it shouldn't either.

Human / social situations are complex, Jörn; tit-for-tat can win

computer contests, for example, but it's not a behaviour one person

would find as entirely agreeable in another.
Satyam

-

With the sheer amount of sheeple[1] in the world (and on this list), I doubt

anything could make these discussions any shorter.
(While I hate thinking that sheeple are on this list, it is an unavoidable

fact. (I had hoped I wouldn't find any sheeple here, as my favorite theory is

that they are all "Fundamentalist Christians" like the "Creationist" fools))
DRH

1: Sheeple (n): People that act like sheep - ie: they cannot think or form

opinions for themselves and always look to someone else for their thoughts

and parrot the opinions of some "trusted" figure.
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

Not all of us agree with this for the benefit of future legal
Agreed - everyone contributed to the kernel based upon the GPLv2. Lots of

different reasons, lots of different viewpoints about GPL2 v  GPL3, DRM ,

Treacherous Computing, etc. The commonality is not political, not a

grand plan, not a grand unified social agenda but a bunch of people for

whom the GPLv2 was an acceptable license for furthering their intentions

whether that is education for all, a shared commons or just making a

quick buck
Alan

-

Well, even the FSF lawyers did, but one of the reasons I never wanted to

do the copyright assignments(*) is exactly because I think people need to

make their own judgments on what the GPLv2 means. In the end, the only

thing that really matters is what a judge says (after appeals etc), and

the fact is, any license will always have gray areas where people disagree

about interpretation.
And I actually am of the very firm opinion that a world with gray areas

(and purple, and pink, and green) is a hell of a lot better than one where

everything is black-and-white. Only lawyers want a black-and-white world.
So I would actually *encourage* other people to sue over their GPLv2

interpretations, as they have done in Germany (and as IBM has done in the

US). I'd sue based on _my_ reading of it, but hey, while my opinion is

obviously always correct, I recognize that I live in a world where not

everybody else always sees that.
[ (*) Obviously, the *biggest* reason not to do copyright assignments is

  that they are just a total pain in the ass to do, and cause tons of

  totally pointless paperwork. So "Linus is lazy and not interested in

  being a lawyer" is obviously the primary reason for the lack of

  assignments. I'm just much happier with people owning their own code

  outright. ]
Of course, I also realize that suing people over license violations is a

big pain in the ass, and in that sense while I "encourage" people to

assert their own copyrights, I would obviously also say that it's almost

certainly not worth doing if it's in a "gray" area. But that, in the end, 
Indeed. And it's _fine_ to even be in it "just to make a quick buck". We

do want all kinds of input. I think the community is much healthier having

lots of different reasons for people wanting to be involved, rather than

concentrating on just some specific reason.
For some it's the technology. For some it's the license. For some it's

just a thing to pass boredom. Others like to learn. Whatever....
[ message continues ]

Or rather they didn't think an attempt to enforce that in the US would

prevail (or so I'm told).  That's not saying what TiVo did was right,

and that's not saying that what TiVo did was permitted by the license.

Only courts of law can do 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}

-

Wrong! Anyone with half a brain can make the distinction. What TiVO did is

entirely legal - they fully complied with the GPLv2. Note that what they

*DON'T* allow people to do is run whatever version of whatever software they

want on their hardware. They have that right - its the "Free Software

Foundation" and the GPL - regardless of version - is a *SOFTWARE* license.

TiVO never stopped people from copying, modifying or distributing the code -

what they did was say "The code is GPL'd, the hardware is restricted" -

ie: "You can do what you want with the code, but you can only run compiled

version of it that we provide on our hardware". Why is that legal? Because

TiVO produces the hardware and sells it to you with a certain *LICENSE* -

because it does contain hardware covered under any number of patents. That

license grants you the right to use the patents - in this case algorithms -

provided you comply with the terms of the license. (Just like the GPL gives

you the right to copy, modify and distribute GPL'd code as long as you comply

with its terms)
If you believe otherwise then you are sadly mistaken. Now stop parroting the

FSF's worn and tired tripe.
DRH

PS: Looking at your .sig I guess maybe you can't do that without getting

kicked out of the FSF-LA
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

Are you playing Linus' sheeple and parroting his lines just to make a
Don't worry, I'm not speaking even for FSFLA, and I'm entitled to my

own opinion.
I haven't consulted other FSFLA members about this.  This is all my

own personal opinion.
It just so happens that I'm very closely involved in the process, I've

spent a lot of time thinking about it, and I happen to share a similar

moral and ethical background with others involved in the process, so I

arrive at similar conclusions.
And then, I influence the process myself, so it's not like some of the

arguments I brought up here weren't taken into account while creating

the GPLv3, and adopted by its other proponents.
--

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}

-

Read the hover text on http://xkcd.org/c202.html
I'm wondering if it's time for a "Munroe's law" concerning that word...
Rob

-

Nope. I'm just tired of giving proof after proof that you're wrong and having 
Certainly. I never said otherwise. What I stated and then *implied* was that

you are repeating the same false logic over and over again trying to make

people believe that it isn't borked and that that false logic is exactly the 
Where I am examining the facts and drawing a logical conclusion. That it 
Okay. Still doesn't explain why you have argued that the GPLv3 doesn't attempt 
This is no surprise - I had a feeling this was the truth. Not that it changes

my opinion at all. As I've said, I have never liked the GPL at all, but v2 is

the best that exists - even though I've put together custom licenses myself,

none of them have had the number of lawyers look at them that the GPLv2 has

had.
DRH
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

It doesn't cover hardware, in the same way that it doesn't cover

patents, and it doesn't cover pro-DRM laws.  It merely arranges, as

best as we've managed a copyright license to do, that they can't be

used as excuses (or tools) to disrespect the freedoms that the GPL

demands all licensees to respect for other users.
--

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}

-

Consider this scenario:

Small company A is manufacturing a new WiFi router.

They decide to have it run HURD as the OS.

In complying with the GPLv3 they supply the signing keys and everything else

needed to install a new kernel on the hardware.

User B buys the router and modifies the kernel so it drives the WiFi to an

output power twice that which it is licensed to carry.

FCC finds out and prosecutes User B for violating the regulations.

FCC then pulls the small companies license until they change their hardware so

the driver can't push it to transmit at a higher power level and levies a

fine.

Small company A loses the money paid on the fine, has to recall all the

devices that can be modified (through software) to break the law at a massive

cost *AND* has to redesign their hardware. The total cost drives the company

into bankruptcy.
Small companies C,D and E, in order to avoid the fate of small company A,

purchases a license for proprietary OS "F" to drive their new hardware.
Net loss: A lot of the users and publicity that "Free Software" used to get,

because GPLv3 contains language that opens the companies to lawsuits that

they wouldn't otherwise face.
Which is better: Growing the base of installed GPL covered software,

or "ethics and morals" that demand the language that has been added to the

GPLv3 ? Personally I'd like to see proprietary software driven into a very

small "niche" market or entirely out of existence. However much I want this

to happen, I cannot be anything *BUT* scared of the GPLv3 simply because I

see it creating massive problems - and all because of a *small* portion of

the new language it contains. It has taken almost 15 years for "Free

Software" to make a dent in the market, and, IMHO, a lot of that is both

Linux and the "holes" in GPLv2.
DRH
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

I'd say this is unfair, but if it can happen, then maybe the small

company could have been more careful about the regulations.  There are

various ways to prevent these changes that don't involve imposing

restrictions of modification on any software in the device, all the

way from hardware-constrained output power to hardware-verified
When this doesn't bring freedom to people, when people can't actually

enjoy the freedoms that the software is supposed to provide, I don't

see why this would be a good thing.  What's the merit in being able to

claim "vendor X chose my Free Software and locked it down such that

users don't get the freedoms I meant for them, and I'm happy about 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}

-

it can (at least hypothetically in the US - I do not know of any actual 
As a person pretty familiar with the hardware in these types of devices - this

just isn't practical. 
The power output goes to the air, has some to do with any external power amp,

the antenna design/connectors, the layout of the printed circuit board (PCB),

the materials of the PCB, and numerous other factors that are outside the

chip where the register sits that controls the "output power". This is why

the register is there - so many things exist in the real world that require

it to be changed to actually get desired power output in the air.
What you are asking is possible - that people who make the standard CMOS

radios add EEPROM or FLASH to their processes - or they could add an

interface to a serial EEPROM where these hardware limits could sit - and

during manufacturing could program these to add a hardware limit.
But this seems - just silly - adding extra cost/complexity to the hardware -

because you limit things in the zero-cost space?
Or run the driver in user space, and forget about it. (Like everyone is 
Sometimes joy comes from knowing that your contribution was valuable.
I would ask about two other examples:
 - medical devices - which must have their software certified by the FDA (at

least in the US) - and the manufacture can not allow non-certified software

to be loaded on it - and would be classified "designed or sold for

incorporation into a dwelling" (per the GPL3 dd1v3). Think devices like :
http://www.powerheart.com/products/ [1]
Are Linux developers "happy" knowing their contributions will never help save

a life? And this joy goes to Microsoft or VxWorks? Today it can go to Linux

developers, since the GPL2 license doesn't restrict this like the GPL3 does.
 - gambling devices - which must have their software certified by various

government agencies - to make sure that the odds are known, and there are no

backdoors, and consumers don't get screwed - the ma...
[ message continues ]

Why not go really controversial and dive straight in with "voting

machines".  There's a whole 'nother can of worms.
Bron.

-

I actually left out the most obvious one: store the program in ROM.

Is that not practical?
You're claiming that adding hardware locks and chains and bolts,

implemented with help from the loader software, is simpler than just

using ROM?
Well, then, ok: do all that loader and hardware signature-checking

dancing, sign the image, store it in the machine, and throw the

signing key away.  This should be good for the highly-regulated areas

you're talking about.  And then, since you can no longer modify the

program, you don't have to let the user do that any more.  Problem

solved.
--

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}

-

I don't think so - the GPL3 doesn't state that you must convey the same rights

to end users that you have, it says you must provide installation

information, including your keys, or you can not ship the product.
That is the way I read the following sections (let me know if I mis-read

anything):
======================

"Installation Information" for a User Product means any methods, procedures,

authorization keys, or other information required to install and execute

modified versions of a covered work in that User Product from a modified

version of its Corresponding Source. 
The information must suffice to ensure that the continued functioning of the

modified object code is in no case prevented or interfered with solely

because modification has been made.
If conditions are imposed on you (whether by court order, agreement or

otherwise) that contradict the conditions of this License, they do not excuse

you from the conditions of this License. 
If you cannot convey the Program, or other covered work, so as to satisfy

simultaneously your obligations under this License and any other pertinent

obligations, then as a consequence you may not convey it at all.
===================
I read "are imposed on you (or otherwise)" to mean "by you" as well. If so,

you throwing away the private keys are not an option.
I need to think a bit more of Rob's opinion of ROM's are illegal - but

providing the installation information of "send $1M NRE and object code to

xxx ROM vendor, and wait 16 weeks for 500k units, take one to a board shop,

pay $1k for them to re-work your BGA - if the xray says it is screwed up, you

have 499,999 other units to try." - may meet the language, but doesn't meet

the spirit of the GPL either...
-Robin

-

Unless you throw the keys away:
  this requirement does not apply if neither you nor any third party

  retains the ability to install modified object code on the User
See above ;-)
--

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}

-

As far as I know, I'm the first one who brought up the "the current GPLv3

draft forbids burning your code into ROM, you idiots" argument back before

Bruce Perens cost the BusyBox project my services over this very issue.  (Not

that I didn't lock the license of that down to v2 and chase him away before I

left, I was just too disgusted to ever again contribute to a project he'd

named.  Yeah, I hold a grudge.)
Although it's kind of amusing to watch you attempt to dictate terms to

hardware manufacturers, the answer to your question is "yes".  Having flash

is sometimes simpler and cheaper than having ROM.  It means you don't have to

burn a new mask to bump the firmware revision (especially on a low-volume

production run, where "low volume" here is tens or hundreds of thousands

instead of millions).  It makes the thing a lot more field serviceable (you

can upgrade the firmware without a chip puller).  It means one physical chip

can give you both read-only and persistent writeable storage.   And flash

chips produced in high enough unit volumes honestly can be cheaper than a 
A) Does that actually satisfy the terms of GPLv3?  If so, can't they just wait

until they get sued and destroy the keys then?
B) There are actually manufacturers who would be happy with your straw man.

Lots of companies in the far east produce products that infringe on patents

from 30 different competitors, and rather than try to license everything

(which isn't even always possible) they spin off a shell company (or nested

series thereof), design and manufacture a product, sell a production run of

them into the distribution channel, and then dissolve the shell company

before the inventory hits retailers.  But the time anybody is in a position

to take an enforcement action, the company to take the action against is

gone.  (Who are you going to sue, customers who bought the devices?  The

distributors who bought the inventory in good faith, and will then refuse to

distribute any of YOUR produc...
[ message continues ]

I think so:
  this requirement does not apply if neither you nor any third party

  retains the ability to install modified object code on the User
I don't think this woulnd't satisfy the above.
--

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}

-

This isn't just done for IPR, in fact in many fields IPR is a non-issue.

The primary reason for this practice is to render US health and safety

regulation irrelevant and to prevent class action suits if/when your

device kills someone.
Alan
-

You appear terminally confused. The purpose of the GPL as defined by its

authors is not commercial success, world domination or making zillions of

dollars - it is keeping the software protected by that license "free" in

terms of liberty as measured against the set of freedoms to

run/modify/etc they discuss in the licence document.
The fact this is a good license for making zillions of dollars, producing

good software and the like is either incidental or a logical result of the

protection of freedoms depending upon which views you believe.
-

that's fine, but the fundamental question is: where is the moral

boundary of the power that the copyright license gives? The FSF seems to

believe "nowhere, anything that copyright law allows us to achieve our

goals is a fair game" - and the GPLv3 shows that belief. I dont

subscribe to that view. I think the proper limit is the boundary where

the limit of the software is - because that's the only sane and globally

workable way to stop the power-hungry. I.e. the information we produce

is covered by the rules of the GPL. It might be used in ways

inconvenient to us, it might be put on hardware we dont like (be that a

Tivo, a landmine or an abortion instrument) but that does not change the

fundamental fact: it's outside the _moral scope_ of our power. Whether

some jurisdictions allow the control of _other_ information via our

information is immaterial. If a jurisdiction allows the control of

hardware that is associated with our software, so what? If a

jurisdiction allows the controlling of various aspects of movie theaters

that happen to play copyrighted movies, does it make it morally right?
	Ingo

-

But see, I'm not talking about getting permission to hack the

hardware.  I'm only talking about getting permission to hack the Free

Software in it.
It's your position that mingles the issues and permits people to use

the hardware to deprive users of freedom over the software that

they're entitled to have.
--

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}

-

where does this false sense of entitlement come from? The hardware maker

ows you nothing but what is written into the GPLv2. Not more, not less.
(In fact, most hardware makers that utilize free software today give

back _substantially more_ to the community than the license requires!

For example they are currently the largest employers of free software

developers - although nothing in the license forces them to do so. Why?

Because the economic rules that the GPLv2 creates are healthy.)
you are not "entitled" to dictate the hardware's design (or any other

copyrighted work's design), even if the license gives you the power to

do so. By your argument we'd have to put the following items into the

license too:
 - free on-site training for free software developers about the

   hardware's inner workings. (It is justified to teach free software

   the same know-how as in-house engineers of the hardware maker.

   Without this, users are hindered in their freedom to use and

   effectively modify (fix) the software.)
 - 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.)
 - free samples of the hardware to be sent to free software developers,

   upon request. (The hardware maker's own engineers have free access to

   samples. Otherwise free software users might not get the same level

   of driver support as the hardware maker can achieve.)
 - free access to the hardware manufacturing equipment. (If i wish to

   modify the free software in a way that requires more RAM than the

   hardware has, i need access to the manufacturing equipment to produce

   a new version of the hardware that can run that free software. The

   hardware maker has this right and flexibility to modify the software,

   so i should have that same right too.)
see how quickly your argument becomes totally ludicrous, if brought to

its ...
[ message continues ]

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.
In the cases you mentioned, the company would have to get out of its

way to put the other parties on equal grounds.
The former is bad, it's against the spirit of the license, it's a

further restriction.
The latter would be nice to have, but it would be wrong to demand it.
You're picturing the difference between blocking the way such that you

can't get there, and actually taking you there.  What the GPL seeks is

just that you don't get in the 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}

-

hey, that's progress. If you concede this single point then your

arguments about the Tivo situation all fall like domino stones. Just 
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 
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 
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 "rig...
[ message continues ]

#define Dell CFG_FAVOURITE_VENDOR
A Dell desktop machine is a piece of hardware.  The manufacturer has the

source code (hypothetically) to the BIOS.  The BIOS is required for the

machine to boot and run Linux.
Riddle me this (especially Alexandre, I'm just latching on to Ingo's

post because it has the right hook to grab) - are Dell required to give

out the source to the bios to enable people to have the same rights Dell

engineers do to modify the behaviour of the system?
Bron.

-

What is the license for the bios?  Does it say anything about 'no

further restrictions on the freedoms to modify and share the

software'?
Does it include any mechanisms to stop people from booting modified

versions of the Linux that ships with the machine?
--

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 a necessary part of the boot process, without which Linux could

not be started.  Indeed, the Linux kernel interacts with it through a

(loosely, incompletely and frequently buggy) documented interface, much

like how binary modules interact with the linux kernel (even if they do

get loaded into the sacred ring0 execution space, ooh err)
What happens if you're debugging something you think is a bug in the

Linux kernel and then you run bang into some interactions that make you

think the bug might be in the BIOS instead.  Oh unhappy day, you don't

have access to the source code to the BIOS so you can't check.  Those

cretins at Dell (does a #define still work when it's 2 levels quoted?)

have denied your freedom to modify and debug the system they sold you

which is based _in_a_large_part_ on the GPL$mumble Linux kernel and

hence needs to be interoperable.
Regardless of your sophistry, it's a slipery slope by which Dell could

be forced to exert their corporate might back up the tree to the BIOS

vendor and get the right to release that BIOS source code to you or
Maybe, and either way, a future update could, and you couldn't undo it

unless the BIOS flash system lets you "downgrade" again.
Bron.
-

If the bug is in the non-GPLed BIOS, not in the GPLed code, too bad.

One more reason to dislike non-Free Software.
The freedom the GPL defends is not the freedom to modify and debug the

system, but rather the covered software.
Now, if you find evidence that the "bug" is actually intentionally put

there to stop you from doing what you wanted with the software, then

there's clearly a violation of the spirit of the license, and you

might even have a case of copyright infringement, but IANAL.
--

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}

-

There are many interesting bugs out there.  Who is to say what was

intensional?
--

Len Sorensen

-

That might be so.  And in the US, a court might end up finding that

piece of code was taken at random, for no particular reason, from a

sample of garbage produced by code monkeys (in a very literal sense)

typing at random on computer keyboards over a large period of 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}

-

If the bug is in the non-GPLed binary module, not in the GPLed code, too

bad.  One more reason to dislike non-Free Software.
It's the same argument from the other direction.  The BIOS is linked

(inside the machine, sure) to the kernel for all intents and purposes

through a defined interface.  This doesn't affect the BIOS developers

who ship me a machine on to which I then install Linux, but it _does_

affect a hardware vendor who ships me a system with Linux pre-installed,

because it could easily be argued that they linked the BIOS with the

Linux kernel and hence produced a combined work (remember, they reserve

the right to modify the BIOS, but don't give that that right to me) and

the BIOS should now come under the GPL.
Talk about your chilling effects.  It's a strong reason for vendors not

to ship GPL3 or GPL2[your interpretation] code pre-installed while the

legal boundaries of work combination are in any way grey.
Regards,
Bron.

-

How so?
--

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}

-

(I'm going to refer to Linux as GPLix from here on since this argument

 is more general than a specific GPLed operating system)
Er, they installed it in the same piece of equipment, and the kernel

couldn't function without it in that work.  What's more 'linked' than

that.  It's a vital part of the boot process on that piece of hardware

in exactly the same way that the public-key check is a vital part of

the boot process.
If your printer^wPC isn't doing what you want and you know how to

change it to do what you want but it needs a BIOS patch.  Guess what,

you can't do it - your vendor can.  By using GPLix as part of their

boot process along with their non-GPL BIOS, they're subverting the

freedoms that the user should have in being able to control the entire

boot process.
Right?  Or are you unclear about the fact that there's a big grey area

cutting through this part of usage, and Linus sat down pretty clearly on

one side of it while you're arguing that the goalposts should be "where

I feel that my rights to make changes are being infringed".
While the vendor reserves the ability to change components of the

system (post sale, i.e. a BIOS flash update) and doesn't hand those

same rights on to you, they have partially Tivoised (hoover, kleenex,

you've got nothing on these guys for having your name associated with

a concept) the hardware.  By logical extention of your arguments over

the past few days, this denies them the ability to use any GPLed

software in 'the spirit of the licence' anyware on the machine because

they are denying you rights regarding the instance of the product

they shipped to you that they are retaining for themselves.  The very

freedoms you so vocally claim.
Now, the position I'm seeing here is that the above behaviour (every

single hardware manufacturer that has ever shipped a machine with

pre-installed Linux) violates the spirit of the GPL by the "retaining

exclusive freedoms to modify shipped product" rule, and hence their

BIOS is in the doghouse unle...
[ message continues ]

I see what you're getting at.  You're thinking of a license that

doesn't respect the idea of "mere aggregation", right?
For starters, this wouldn't evidently not qualify as an Open Source

license, and I'm pretty sure it wouldn't qualify as a Free Software
You're pushing the "freedom to change" too far.  Sure, I'd like to be

able to do that, and I prefer hardware that lets me do it, but it's

not like this BIOS in the scenario you described is being used as a

means to stop me from modifying the GPLed software.
I have never said that including a GPLed piece of software should

grant users the right to modify anything whatsoever in the system, or

grant them control over the entire system.  Others have, but it's not

true, it just shows how much mis-information is floating around.
All the GPL stands for is to defend the freedom of the users over the

particular program it applies to.  You can't impose further

restrictions on the user's ability to modify what *that* software

does.
If you wanted to change something else, but this something else is not

covered by the license, and is not being used to contradict the terms
I don't think this last sentence is true.  If you implement hardware

locks that prevent modification of the software even by yourself, then

you're in compliance with the terms of the GPLv3dd4.  But IANAL.
--

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}

-

[note: I'm writting this while offline and likely to remain so for the

next 8 hours or so, so I'll probably miss a bunch of other replies]
No, I'm arguing that it's not "mere aggregation" - the kernel is useless

on that machine unless the BIOS is present or replaced with something

else with equivalent functionality.  I suspect any decent lawyer could

make the theory that this made the kernel as compiled on to that machine

with specific chipset support selected for that hardware into a "derived

work" of the BIOS - especially if the vendor had contributed GPLed code

for drivers which interact with their hardware into said kernel.
In fact, particularly if the hardware vendor has also contributed GPL

code that interacts on one side of the software/(firmware, hardware)

boundard which worked around bugs in said firmware/hardware which they

also had the ability to change.  The two really are a combined work of

which only one part is GPLed.
Ringing any binary kernel module video card driver bells yet?  It's

really the same thing from the opposite direction - the only criteria

is where you fit in the pecking order - hardware manufacturers work

around Windows bugs, Linux kernel drivers work around hardware bugs -
Well, yeah - except this is the direction GPL3 takes us, and it's a

theory that GPL3 makes more likely to fly in court than GPL2 does -

meaning that hardware vendor lawyers lie awake at night worrying about
No, but your interactions with Linus (lazy bums 'r' us) have shown that

the logical result of what you do want includes this.  It's a lot harder

to objectively judge one of these than the other:
a) have they provided the source code to this binary to anyone who asks.
b) have any of the limitations of this piece of hardware been created

   with the intent of making it more difficult for J. Random Enduser to

   build modified binaries from said source and have them function

   correctly.
(b) has much more scope for shenanigans by bad apples on the copyright

owner ...
[ message continues ]

I don't know any law that requires tivoization.
There may be laws that require certification or limitations on the

user.  Manufacturer giving up the ability to make modifications would

address this, or *perhaps* arranging for user and manufacturer to each

hold half of the key needed to run a modification (which might comply

with the GPLv3dd4 terms, IANAL).
There may be business models that require the ability to make changes.

Then it's fair to enable the user to make changes as well, such that

they don't become dependent on the vendor, or even have their

1st-generation TiVo boxes left out in the cold for a while when the US

changes the DST rules again ;-)
--

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}

-

Let's take a certain class of medical devices into account: ones that

are absolutely definitely for medical treatment, but are not life

threatening if they fail.
Say, a dental treatment device -- if the device produces a crown or

bridge that doesn't fit properly, the dentist says "nope" and throws it

away. No harm done.
I'd say that its sensible for the manufacturer to attempt to retain this

ability in every case. You never know what's going to go wrong, so it's

a plus to have this option so that you can roll out some types of fixes

without going bankrupt.
Now, for medical devices, this is tricky stuff: medical devices require

all sorts of certifications, so modifying your product after you have

certified it has it's complications. However, despite all the

regulations it's realistic to be able to do this, and it does happen.

Hell, windows-based devices in this field download new antivirus 
Now this is where the regulations get really heavy. If the user is

offered the ability to modify the device, theres *no way* it would get

certified. Your business is dead - you do not have a product you can

sell. In such case, the license has completely excluded free software

from the market and everyone is forced to use completely closed systems.
I realise that the latest GPLv3 draft would not pose restrictions here,

as such devices would not be classified as consumer products. That said,

talking purely in terms of business models and fairness: there ARE

decent reasons for manufacturer lockdown in some industries.
Daniel

-

And even if they were, there's always ROM.
I don't know whether hardware seals that state "once you break this

seal, law prohibits the use of this device with human patients".
Then the restriction is not being imposed by the manufacturer, only by

law, and this does make lot of a difference as far as software freedom

is concerned.
But then, law might not find this to be enough.  Software patents are

not the only stupid law that harms Free Software :-(
--

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}

-

once you break the seal the device is no longer certified. an uncertified

device cannot be used.
this is very common (in some areas it's widely ignored, in others it

isn't)
this is just like the 'you void the warranty if you disrupt this sticker'

stickers that you see on just about any hardware you buy today. some

vendors are stickers for this, others don't really care.
-

Yup.  That's the law.
At which point it's not the hardware vendor imposing the restriction,

so this use is perfectly acceptable.
One could presumably implement similar seals in software.  Nothing

wrong with a signature used to indicate that the device has been

tampered with.  Even a led somewhere that reflects this status.
None of this prevents the user from enjoying the freedoms he's

entitled to, according to the laws of the place where he lives.
--

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}

-

I've done quite a bit of research, I'm not nearly done.
These regulations (from what I can tell) seemed to follow suit with the

National Electric Code (NEC) [latest] when dealing with mandatory

isolated ground devices and special cabling methods when it comes into a

device touching a patient. If that remains consistent, this won't be so

bad.
If the patient never comes in contact with it, its not regulated as much

and (from what I've seen) has no requirement for tamper proofing. I

point out again, I am not _nearly_ done with my research.
I think of nothing else, anyone with an interest should closely monitor

how these devices are being regulated by the FDA as more of them begin

to look like penguins.
I won't argue one way or another as to the presence of benevolent intent

in those laws-to-come, I'm simply pointing out the questionable

technical competency of those who will be writing them and their need

for guidance when doing so.
Best,

--Tim
-

> I don't know any law that requires tivoization.
In the USSA it is arguable that wireless might need it (if done in

software) for certain properties. (The argument being it must be

tamperproof to random end consumers). Obviously an electronics graduate

can tamper with hardware ones just as well
The USSA also has interesting rules about some other technologies

including GPS on national security grounds.
Alan

-

But this is not tivoization.
Tivoization is a manufacturer using technical measures to prevent the

user from tampering (*) with the device, *while* keeping the ability

to tamper with it changes itself.
(*) tampering brings in negative connotations that I'd rather avoid,

but since that was the term you used, and the term "modifying" might

bring in legal-based technicalities such as that replacing isn't

modification, I just went with it.
So, given a proper definition, do you know any law that requires

tivoization?
Taking it further, do you know whether any such law requires

*worldwide* tivoization, as in, applying the restrictions in the law

even outside its own jurisdiction?
--

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}

-

You're splitting those hairs might finely. So when you ask whether there's

any law that "requirse tivoization", you won't accept a law that creates a
A law that requires certaint things be tamper-proof, where engineering

realities requires that they be controlled by software and the software be

upgradable (for security reasons and for support of future protocol

revisions) isn't good enough for you?
DS
-

And I was wrong.  Please see the "mea culpa on the meaning of
I guess it amounts to what you mean by "*only* practical solution".
"I can't fit the corresponding sources in this CD, so you won't get

them." is no excuse to disrespect users' freedoms, why should this be
"engineering realities" is the weak point of your argument, see above.

Is ROM still software?  Is replaceable ROM still software?
--

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 Sun, 17 Jun 2007 15:33:33 -0300
That accurately describes the FCC wireless rules. As a vendor I am

perfectly allowed to tinker, but the product must not be "end user"

modifiable. (and some vendors take this to mean binary only, despite the

fact end users generally aren't able to modify code and EE students are

just as able to modify electronics as we are code).
Alan

-

AFAIK the FCC mandates not permitting the user to tinker.  It doesn't

mandate the vendor to retain this ability to itself.
Therefore, per the above, FCC doesn't mandate tivoization.
Is there anything else I'm missing that would show it does?
--

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}

-

In practical terms it does since a recall/replacement in the event of
I'm sure you can find a definition to sort your goals whatever.
-

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
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

disc...
[ message continues ]

Just want to point out that, when I read this, my reaction was "But... That is 
Yes, they would. They are distributing a modification - in the words of the

GPLv2 "a work based on the work" - without complying with the terms of the 
Not even the GPLv3dd4 - because they don't have the information anymore

either. If, however, they still retained the information - in any form - they

would be violating the GPLv3dd4.
The GPLv2 doesn't make the actions described above - "how to install and 
Then anyone using GPLv3'd software to drive WiFi devices, radio (HAM radio)

networks, etc - in the US, at least - isn't allowed to do such. US Law makes

some provisions of the GPLv3 illegal to comply with. Thanks to section 6 of 
Umm... making things more strict will just do more damage. As it is there are

restrictions on companies that make them unable to comply with the GPL. What

the GPLv3 has done is take away options they might otherwise have had. If one

of the goals of the FSF is to force proprietary software into a minority then

its just done damage to that goal.
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

Yes.  Anyone feels like enforcing the GPLv2 in Brazil?  I can even

recommend lawyers that speak English reasonably well and are somewhat

familiar with the GPL, and I've already tracked the distribution chain

back to the initial infringer.  Harald is aware of the issue, but
There's no reason to assume it's a modification.  They're distributing
I'm told by the authors of GPLv3dd4 that this case is not meant to be

permitted.  I suppose they're going to change the wording, or at least
This is true.  They didn't have any such duty, under the GPLv2.
However, if I figured that out by myself, but found that I was unable

to run a modified version because something in there checks for a hash

computed over the program I'd like to modify, and refuses to run it

because of the hash, then the hash is effectively part of the program,

and they haven't provided me with the corresponding sources of that

portion of the program.
I know you don't want that to be true, and a court might actually

decide your way some day.  But until then, your claim that this is

permitted by the GPL is just as good as mine that it's not.  And I

really mean "just as good", since my claim is in line with the stated

purpose of the authors of the GPL, and yours is in line with their

opinion (according to others, I don't think I've got this straight

from them) as to whether the license effectively prohibits this
Actually, this is false.  Not only because of the ROM provisions in

the GPLv3, but because the law requirements aren't anywhere as strict

as the WiFi vendors who want to disrespect your freedoms want you to
It doesn't.  Authors can always grant these options separately if they

want to.  Authors can always choose GPLv2 if they want to.
GPLv3 is an option for those who want to defend freedoms, even if they

don't share the perception that this is a moral and ethical issue.  If

they're in it only for the self benefits, that's fine, GPLv3 can get

them that, even better than GPLv2 could, in spite of the short-...
[ message continues ]

I don't know if I have the right. None of the code is mine - the fact that

they are in violation of the license is not in question (I trust your word on

this), but it is the licensor who has the right to press charges. (I will

check with the lawyers and law professionals I know, because the GPL makes no

statements about the legal jurisdiction under which violations will be tried. 
Okay. So its possible to change whats running on the hardware - but even

though nobody has the information needed to do it, it's a violation. Hrm... I

can see some valid reasoning behind this, but it'll take creative legalese to 
"Effectively" - yes, that is the perfect way to describe it. And even though

it isn't directly part, a situation like that should be covered. (In other

words, if this was the way the "tivoization" section was written to make

this "effectively part of the work" bit the focus a lot of my objections to

it would be nullified. Give me a few hours to work on some solid and 
Agreed. As Linus pointed out, we've been arguing over opinions and that's

pointless. The only thing to do when someone states an opinion is to nod and 
Perhaps. I haven't looked into the specific regulations in over a year, so my 
Okay. I think that someone pointed out a problem with the "optional grant"

idea, but I can't remember the specifics and don't feel like digging through 
If this is your opinion, then run with it. My opinion on the matter is the

opposite - that the GPLv2 does the job in a better way - but, well, that's my

opinion. (and like my mother used to say - "Opinions are like assholes. 
I didn't say it was "the goal", I said "one of the goals". I'm the first to

admit when I'm wrong, but in this case I've read interviews with RMS where he

has said that one of the reasons he founded the FSF was to marginalize

proprietary software. (No, I don't know where this was - the interview was

done several years ago)
DRH
--

Dialup is like pissing through a pipette. Slow and ex...
[ message continues ]

It would have to be some major copyright holder of core Linux code, or

the mips port (IIRC it's mips hardware), or some other driver they're
And if you look at GPLv3dd1 or dd2 IIRC, that's how it started.  For

some reason, the FSF turned it into the more lax (in some senses)

installation information for user products in dd3.  Maybe they decided

that the argument about the signature being effectively part of the

executable, and therefore the key being effectively part of the source

code, was less likely to be upheld in a court of law than this

alternate phrasing.  All in all, the effect is the same AFAICT, and
Linus claimed he would then have to refrain from accepting

contributions from anyone who removed this additional permission.
I don't see how this is different from refraining from accepting

contributions under any other license, except that you can't use

license incompatibility to reason it out as an impossibility you
I stand corrected.  Sorry.  It's been a long thread and a long week.
My objection was mainly about the "forcing".  FSF's stance is about

educating users as to the moral and ethical reasons, such that they

reject non-Free Software, while at the same time providing software

authors with means to stop others from hurting users, by depriving

them of the freedoms they're morally entitled to have.
Others often perceive FSF's tactics as forceful, and I don't deny that

this may be justified, based on past interactions with the FSF.  That

said, I think they've improved a lot, even if they're not perfect (who

is?).  But the perception and the consequent rejection unfortunately

remains as strong as ever.
--

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}

-

That's what I thought. Anyone here feel like pursuing that? It is, directly, a 
Not really. "I threw the source away" violates the license in a very clear

manner - they are distributing a "work based on the work" without complying

with the terms of the license under which they gained access to the work.

However, as I said, I can see some valid reasoning. But its more a part of

the "Hey, I paid good money for this thing and I can't use it how I want!" 
But the change has some massive problems. If dd1 or dd2 was clearly and

concisely written such that the conditions were not open to a different

interpretation without creative re-definition of words then changes would not

be needed. (I'm still working on the version I mentioned - give me a bit,

writing english in such a way that a lawyer can't twist it to mean whatever 
I think there was more to it than that, but the point doesn't matter. If the

license used on contributed code *isn't* completely compatible with the

license on the project it can't be used anyway. (doesn't the GPLv3 cover 
Hrm... When I first hit the end of this massive sentence I was really

confused. Took about five minutes for me to remember that "morally entitled" 
IMHO RMS and the FSF go about things in the wrong manner. Yes, the goal is

admirable, but the means by which they are attempting to reach them are not.

However, I have no connection to the FSF or RMS and thus cannot dictate

anything. What I can do is try to educate people as to why I have the dislike

of the FSF and RMS that I do. (and how I can *respect* RMS and the FSF while

not liking them :)
In this discussion I've tried to point out things that occur that are at odds

with the text of the GPLv3 (as it exists - the "31/5/2007 'Final Comment

Draft'). I have also tried to point out that what the FSF and RMS claim is

the "spirit" of the GPL cannot be conclusively proven to be the same "spirit"

it had when it was written. When it comes to that somewhat slippery

term "intent" ...
[ message continues ]

It's very difficult and, worse, it might turn out to be unenforceable.

You'd have to count on signing keys being copyrightable, and they are

unlikely to be, and on signatures being derived works of both, which

is a tough call.  The whole idea resonates very well with the spirit

of the license, but we need more than that, we need it to be very

likely to work.  I suspect this is why the FSF has decided to take
I'm not sure what you're asking.  GPLv3 covers additional permissions,

that are really no different from dual-licensing, so anyone can choose

to drop them when combining with works (including their own) that
Yes.  And the 'them' after the last comma refers to the users, not the
FWIW, I never felt offended by you, but I second your request and

extend it to all participants in the thread too, particularly to Ingo,

to whom I remember having directed some harsh words.
--

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}

-

I haven't looked at it, in depth, today but one of the problems I saw was the

apparent loopholes in the text. No specifics, but I remember thinking "a

lawyer would have a field day with this - dozens of ways they could sidestep 
Agreed. I'm still stuck trying to keep the language concise and understandable

without delving into the descriptive flights of fancy I enjoy. (I write a lot

more fiction than I do code, even though I started writing code a long time 
What I was getting at, here, is that the GPLv3 isn't backwards compatible with

GPLv2, because you aren't allowed to remove rights from the GPLv3. Remember,

there are rights encoded in the GPLv3 that don't appear in v2. In fact, if

you want to use GPLv3 code in a GPLv2 project you have to use GPLv3. For some 
Yes. I almost replied "-ENOPARSE" because, when I first read it, I parsed it

as "by depriving [the authors] of the freedoms they're morally entitled to

have". When my brain finally rebooted after that bought of idiocy I was able

to parse it properly.
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

*Pretty* *please* file comments about the apparent loopholes at
It couldn't possibly be.  The whole point of upgrading the GPL is such

that it complies better with its spirit of defending the freedoms, so

as to keep free software free.  This can only be accomplished with

additional restrictions that stop practices that deny users'

freedoms.
Relaxing the provisions, a necessary condition for compatibility,
I'm not sure what you mean by "rights" in the two sentences above.

You know you can grant additional permissions, so I assume that's not

what you mean, even more so because you *can* indeed take them out.

Is it "conditions", "restrictions" or some such, that in turn

translate into freedoms for downstream users, or is it about the
Impossible is a bit too strong.  I understand it would take a huge

amount of work though, so I sympathize with "it wouldn't be worth it",

even if, in my scale of moral values, I'd disagree.
--

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 do that I'd have to go back, take the time to re-read the GPLv3 *in*

*depth*, think about each paragraph of each section individually...
Like I said, I just got a general impression that a lawyer would have a 
Sorry, bad choice of words. There are "guarantees" encoded into every license.

There are some encoded into the GPLv3 that aren't encoded into the GPLv2. You

can't remove or restrict those guarantees without violating the license. And

removing those guarantees would be the only way to make the GPLv3 fully 
In this case I wasn't speaking literally. I should have been a lot more

specific there - it should say "practically impossible". 
DRH
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

Cynical Economists would argue 'legal requirements' are just changes to

the cost of the various economic options. Sometimes when I look at
That's a nice definition but one I can see being sort of abusable

depending how you read it. We head ever more into the disposable computer

era where as a vendor putting the code on ROM is cheap and upgrades don't

matter (throw it away get a new one).
I can tell you how to upgrade it ("you can't") yet I as the manufacturer

can issue new units with modified code so I still control it even though

it is meant to be "free"

-

I'm waiting for cereal boxes in the store to have a display covering the

entire front side which changes every 30 seconds, with all the circuitry to

drive it taking up a few square milimeters and a small watch battery to power

it for six months ala the blinky LEDs of today.
This should be economicaly feasible in what, 10 years?  15?  (There are all

sorts of weird problems to solve like coming up with a battery that's not

only cheap enough but which you won't get in trouble putting millions of in

landfills.  Fuel cell might be more environmentally friendly depending on

your catalysts...)
We haven't even brushed against the "disposable computer era" compared to

what's coming.  Most of us will probably live to see happy meal toys capable

of running Linux, and that's just a _start_.
Rob

--

"One of my most productive days was throwing away 1000 lines of code."

  - Ken Thompson.

-

I guess this depends to some point on the kind of penalties you face.

If they're only economic, then yes.  If you may end up going to jail

or some such, I think the picture gets different.  But yes, that's a

way to see it, and I know we're not alone in perceiving some behaviors
The GPL has never prohibited the distribution of software in ROM, just

like it's never prohibited the fixation of software in CD-ROMs.  So

explicitly permitting is not a step back in terms of defending

freedoms, even if there might be something to do that would advance

freedoms in this field.
Anyhow, AFAIK software in ROM is not non-Free Software.  That it's

impossible to modify/replace/whathaveyou it is not the result of a

restriction that someone is imposing on you.
It's the difference between "you can't fly because you don't have

wings" and "you won't fly because I've tied your wings".  With tied

wings, you're evidently not free to fly any more.  But if the problem

is that you don't have wings, if you're free and sufficiently

creative, you may be able to invent baloons, airplanes, rockets et al

and overcome the barriers that nature poses for you.
--

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}

-

So, if a manufacturer used a ROM instead of a flash memory with the

intention to make software modifications impossible, then it is bad,

and when he did it for economical reasons, then it is a "natural barrier"?
Your tied-up-wings comparison is simply not valid. Or, more precisely,

you will usually not be able to tell whether you don't have wings or

if they're tied. Hardware design decisions of a manufacturer should

never be the subject of a software license.
Hans

-

This sounds about right to me.
Intent is very significant, but then, what vendor would justify the

choice of ROM as "intent to prevent modifications", if this amounted

to copyright infringement?
Vendor would be entitled to the benefit of the doubt as to the

motivations in this case, so it would likely be unenforceable anyway.
--

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}

-

Indeed. That nicely shows how useless any licensing discussion is
Right. If GPL v3 comes out, there'll probably be a new task for

hardware development engineers: How to find excuses for hardware that

prevents software modifications and how to conceal the true intent.
Hans
-

Yup.  And then GPLv4 will have to plug whatever holes they find to

disrespect users' freedoms.  That's how I expect the game to be

played.
--

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}

-

If you were right and it turned out that way, the whole GPL would

become so ridiculous that it won't have any of its intended effects.

GPLv17 would contain so many #ifdefs that it'll simply not be readable

or understandable anymore. 
As far as the kernel is concerned, I expect the game's played by

simply keeping GPLv2. And I like it that way.
Hans
-

How so?  The intended effects are to protect users' freedoms, by

requiring them to be respected.  If we keep on plugging holes as they

appear, it will keep close to achieving its intended effects.  It's

earlier versions of the license that will get more and more distant
Just think about it...  What if, today, some law passed, or some court

decision came up, that rendered a significant defense provision of

GPLv2 or GPLv3 ineffective?
GPLv4 could plug that, and anyone using GPLvN+ would be able to switch

to it immediately.  This wouldn't revoke previous licenses, of course,

but further developments could be made under the newer license, and at

least those could still be defended, and, as time elapsed, earlier

versions of the software would become less and less relevant, to the

point that the holes in their license also become less and less

relevant, until copyright finally expires and they enter the public

domain.
The distrust for the FSF led to this very short-sighted decision of

painting the Linux community into a corner from which it is very

unlikely to be able to ever leave, no matter how badly it turns out to

be needed.  Let's just hope it never is, or that some influx of

long-sighted comes in and introduces mechanisms for the license of

Linux to be patched, should this ever be needed.  I'm not even talking

about GPLv2+, there are many other ways to accomplish this, that I've

already mentioned in another posting in another recent huge thread.
--

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}

-

No. Credible licenses should be simple like physical laws. Newton's law

is expressed in terms of a single mathematical equation. That's why it's

still valid, and you still learn it at school although meanwhile people

know that there are limitations to it.
If you come up with a new version of a license every year, you will only

weaken it. Please note that quantum mechanics is _not_ such a hole-plugging

addition to Newton's law. It's a new simple physical law, expressed in terms

of a single simple mathematical equation that contains the old law as a

border case. If that were not the case, it would have never been accepted.
If you want a GPLv3, please make it simple and make it contain GPLv2 as
No. GPLv2 is a simple set of rights and restrictions that's easy to

understand and therefore accepted by many courts all over the world.

I cannot see any danger for the code I put under it, at least none
The best way to prevent that is to make the license simple and easy to

follow. If many important open source software developers have problems
Ah, now I get the point. Yes, that's one in favor of a complicated and

confusing license. You can lengthen court proceedings until copyright
I'm neither in a corner nor do I feel the need for a different license.

I've got some code in the kernel, and I've got it under GPLv2, and I'm
You know pretty well that Linus clearly said he would change the license

when _he_ thinks it's needed. The point is that _you_ want him to change
I partly read that "recent huge thread". Linus elaborated his point of

view in detail, and I very much share his opinion.
Hans
-

Yes.  Some day you may.  And then what will you or anyone else be able
It's just stating the obvious.  The upgrade path is a nightmare.
A long-sighted decision should have established *some* means for a

quick fix should it be needed.  It didn't have to be GPLv2+.  In fact,

per the stated goals and general feelings, it probably *shouldn't* be

GPLv2+.  But cutting any reasonable possibility of fixing a legal

problem in the license is short-sighted, yes.  It's putting too much

trust in the perfection of the license *and* the worldwide legal
I would like him to, yes.  But this is besides the point.  That I see

reasons for an upgrade, and that I'd like such an upgrade, doesn't

make any difference whatsoever about the plain fact that relicensing

Linux today, to any other license and for whatever reason it was,

would be a nightmare, and that this is a consequence of the

short-sighted decision of not establishing a relicensing procedure.
At this point, the situation is very much like a kernel installed in

ROM.  Who knows that nobody will ever find security bugs in it?  How
Huh?  It looks like you're talking about something unrelated with

license patching procedures.  I don't think Linus ever responded in

that thread to my suggestions of various means to establish a license

patching procedure.
--

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}

-

A lot of awful things could happen to you or me _tomorrow_. Are you prepared

for everything? I'm not. If I'd try to be prepared for every possible

disaster, you'd rightly call me mentally ill.
Even if my code is used on a Tivo-like device, I can sleep well and don't

need a different license. These are the _normal_ grey areas that _every_
Well, maybe. Maybe this is a topic that needs further discussion.

But I don't find it very important as we're not in a situation where

we urgently need a new license.
[...]
Hans
-

Agreed.  It could have been discussed years ago, when the

clarification on GPLv2-only came up, but it's still not urgent, and

hopefully it never will be.  It wouldn't be a bad idea to think about

it, though.
Just in case it's not clear, this is in no way related with GPLv3.

It's just that GPLv3 discussions appear to get more people thinking

about relicensing, and then the "impossibilities" of doing it come up.
--

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}

-

This is an excellent example of how engineers tend to mis-analyze

legal issues.  In law, neither simple wording nor interpretation is so

simple or so mechanical as the things engineers prefer to work with.
Take an example: "Thou shalt not kill".  Very clear, but also very

problematic in that it does not address military conquests (which were

apparently approved by that law's drafter), self-defense, or a number

of other cases.
There are always grey areas between what is explicitly addressed and

what is not.  Courts interpret laws and precedent in ways that make

life (and license or contract writing) more unpredictable.  Wishing

otherwise will not make a simple license unambiguous.  If those areas

of ambiguity are exploited enough, the perceived cost of having a hole

will exceed the perceived cost of plugging it.
Michael Poole

-

Don't make fast assumptions about how _I_ think. I intentionally chose

examples from science, not from engineering. There are grey areas in
Yes, you named it: _always_ !! We have to accept these grey areas.

Tivoization (to come back to our real topic) is one of those.

Alexandre Oliva sees grey areas as holes he needs to plug. That's

wrong, and that's what I'm criticizing. You cannot get rid of grey

areas by modifying licenses. Maybe you can temporarily shift the grey

areas to some other place. But at the same time, you get negative

side effects because your license becomes more and more complicated
I completely disagree. A very important factor for the success of a license

is that people are familiar with it. Only then can they start obeying it.

Have you ever been out there in industry, trying to tell programmers what

Linux, Free Software, and the GPL is? You'd notice that they hardly know

what the GPLv2 is all about. And now, after I explained it to them, should

I tell them that there's a much more complicated license about to come, and

that it's going to be changed whenever some FSF people find a new hole?
All this hole-plugging just leads to a license that is so far away from

being useful in industrial reality that nobody will voluntarily obey it.

This Tivoization stuff is a good example. I was a hardware developer for

more than a decade. When I developed _hardware_, I made my design decisions

without having to read the licenses of the _software_ I want to run on

that hardware. And if you go today and tell a hardware developer that there

are some people in the world who want to achieve exactly that, he will

probably laugh at you and think you're joking.
Hans
-

It doesn't. The GPLv3 (dd4) makes that very clear. See the quote below.
"Installation Information" for a User Product means any methods, procedures,

authorization keys, or other information required to install and execute

modified versions of a covered work in that User Product from a modified

version of its Corresponding Source. The information must suffice to ensure

that the continued functioning of the modified object code is in no case

prevented or interfered with solely because modification has been made.
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

You left out the relevant bit:
  this requirement does not apply if neither you nor any third party

  retains the ability to install modified object code on the User

  Product (for example, the work has been installed in ROM).
--

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}

-

Ah, but giving the user half the key doesn't mean they still don't have access

to the entire key. QED: Giving people half the key won't cut it under the

GPLv3 (dd4)
DRH
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

I meant really giving, rather than giving a copy, or giving the

original and keeping a copy.
You could make it require a pair of signatures, one from the vendor,

that the vendor keeps, one from the user, that the vendor never sees,

too.  Like some bank PINs, it gets generated, used to generate some

hash (the signature for the initial installation), printed in an

envelope for you and stored in the package along with the machine.  Or

something like 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}

-

Wow, and I thought losing a microsoft "certificate of authenticity" and

associated key was a pain.  Ouch.  Talk about your paper "dongle".

-

That's *not* a valid argument!
I know, I know, it's a common one, but it is *nonsense*.
The thing is, "mere aggregation" doesn't mean what you think it means.
"Mere aggregation" doesn't mean that they cannot depend on each other. It

means that they are not *based* on each other in the sense of GPLv2.
In other words, "mere aggregation" is about two pieces that are not

derivative works under copyright law.
For example, on a Red Hat DVD, *every*single*binary* on that DVD requires

a kernel to run on. And the kernel image itself "depends" on the user

programs to actually do something _useful_. 
But it's all still "mere aggregation", because they are not related to

each other in the sense of being derived works!
So "mere aggregation" is not about intimacy. OF COURSE high-tech products

depend intimately on each other. The Linux kernel cannot boot on a PC

without a BIOS or something equivalent. You cannot run your graphical

environment without a kernel, an X server, the CPU, the memory, the

display, the BIOS, the power company (or an equivalent hand-crank) etc etc

etc, and these things are all very much dependent on each other to make a

"usable system", that has absolutely _zero_ relevance to whether they are

"mere aggregation" or not.
So the only thing the "mere aggregation" phrase in the GPLv2 means is

simply: "putting together two or more pieces that are not derived works of

each other". That's what that
	mere aggregation of another work not based on the Program

	                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
part of the license is all about.  The BIOS is "another work", and it

clearly is "not based on the Program". The "aggregation" just means

"putting them together", and the "mere" is there just to show that as far

as the license is concerned, that is not even interesting!
In other words, the sentence in section 2 about mere aggregation says one

thing only: the fact that you lump things together storage-wise does not

matter *at*...
[ message continues ]

Further to my other response on this (yeah, I know, I should think

first).
Where the BIOS author and 'work aggregator' are different organisation

with no shady backroom links (other than the usual industry cabal(TINC)

of course) then it's clear.
When they are the same organisation then the derivedness state is a lot

less clear and more "discoverable", leading to a higher risk of ambush

by litigation.
This isn't specific to any particular licence, but it's something that

the "intent" theory of hardware limitations being a GPL3 violation makes

extra dangerous, because that clause can be used as a hook to drag a

claim through summary judgement (IMHO, IANAL, etc)
Bron ( mostly arguing the same things that you are Linus, I think, but

       I didn't clarify that I was writing from a devil's advocate

       position in an alternative reality where Tivo was illegal

       purely due to "intent" )

-

Ok, can I please rewrite my argument to:
"The hardware manufacturer has built a custom BIOS and also written

Linux kernel support for said BIOS.  They have released the kernel

drivers under GPL as required, but have not released the code to the

BIOS, instead just releasing the interface documentation.  The BIOS

didn't exist before, and as they only intend to run Linux on the

device, the BIOS design was heavily influenced around working well

with Linux."
Actually, we don't know that last bit, maybe they created the BIOS

in a total vacuum and then wrote the Linux kernel driver later.

Maybe not.
Anyway, I think I've wound up arguing two sides of the same argument,

oops.
Bron.

-

Why does it matter whether the BIOS was "heavily influenced around working

well" with Linux? Your argument is arguing about things that have nothing to

do with anything. Your comparing things before you have any idea what the

right criteria for the comparison is.
Do you understand that all that matters is whether the BIOS contains

significant portions of the Linux code base? *Nothing* else matters.

Everything else will leave it an independent work and one that the authors

of Linux have nor right to claim any ownership of or control over.
I maintain a private application that has huge amounts of code that are

heavily influenced around working well with Linux. All the epoll code, for

example, in this code base meets that criteria. That doesn't mean it

*resembles* the Linux code in any way. It doesn't mean the Linux folks have

any right to tell me what I can and can't do with that code.
So you're arguing two sides of no argument at all.
DS
-

Yeah, pretty much.  I take back my arguments in the previous

couple of my posts up this thread.  They don't actually hold

together!  Sorry for wasting your time correct me.
Bron.

-

Linus,
Just take a vote and start tagging files and ignore this needless

diatribe. It is was it is, I seriously doubt you will

get all of Linux moved to GPL3 as a monolith, since you will never get

concensus. You should fork a GPL3 kernel and let people decide

whether their code goes in or not. If they don't want to move to it, new

people can contribute new code. Start a 2.8 tree or whatever that is

GPL3 only.
Jeff

-

*snicker*
Yeah, Linus - when do you finally understand that nobody WANTS

your GPL3 kernel?  :))
ROFL
--

Carlo Wood <carlo@alinoe.com>
-

This situation is a general description that actually fits what TiVO has done.

The difference in the TiVO case is that you (and everyone that thinks like

you - ie: believes that the "tivoization" language in GPLv3 is good)

equate "replace entirely" with "modification" when, in fact, the two are 
"You can't impose further restrictions on the user's ability to modify what

*that* software does."
I don't see how TiVO has done this. They have placed no restrictions on

*modification* at all. What they have done is placed a restriction on

*REPLACEMENT* of the program. If you're going to argue that "replacement ==

modification" then it is an *easy* argument to make that every time someone

*replaces* linux with a proprietary system the proprietary system magically

becomes GPL'd.
And no, this isn't a logical fallacy on my part. It's on your part - all I've

done is take the logic you have provided and extend it to cover a different

situation.
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

Technicality.  In order for the software to remain free (which is what

the GPL is all about), the user must not be stopped from adapting the

software to suit his needs and running it for any purpose.  TiVo

places restrictions on it.  It's really this simple.
And then, TiVo doesn't really prohibit replacement.  You can replace

it as much as you like; just not as conveniently as TiVo can replace

it.  And then, if you do, it won't run, because it's not signed with a

key that they omit from the source code.  And they do this in order to

prevent the user from changing the behavior of the Free Software that

they use, while they keep this ability to themselves.
If these are not restrictions on the freedoms that the GPL is designed

to protect to ensure that Free Software remains Free for all its

users, I don't know what is.
--

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}

-

Your arguments are all based on technicalities, so why are you complaining

when I do the same?
As it stands there is *NOTHING* that singular distinction makes all the

difference in the world. What you are arguing - based on your *BELIEF* that

such *REPLACEMENT* is a modification. 
By the way, Alexandre, I'm not so much of an *IDIOT* as to believe that you

don't understand the difference. You are arguing about it because you *WANT*

the difference to not exist. You are arguing about it because it makes your

argument that what TiVO did broke the "spirit" of the license. If you want

I'll go dig out the exact place where RMS said that he didn't care about

hardware. 
You want another "technicality"? How about one that you *AGREED* is valid?

That your right to configure a device ends at the point where it connects to

a network? Well, unless you want to sacrifice *ALL* the stuff that makes a

TiVO actually worth using, you *HAVE* to connect it to their network. At that

point *ALL* of its configuration details - yes, even the Operating System -

fall under their control. In the US there are laws that restrict this right

when applied to "telecommunications" companies - but TiVO *isn't* 
If your argument is that the final output binary is created by combining the

signing key and an interrim binary then you *MIGHT* have a point. The simple

fact is that that argument depends on whether the kernel itself is modified

by the signing process or if the signing process generates a separate 
"Free as in beer" is the phrasing used, I believe. I see nothing in that TiVO

has done that negates this. I do disagree with it - if I buy a TiVO box, I

own it and should be able to do what I want with it. However, this does not

negate the fact that it does connect to their network, and as a device that

does such they are allowed to configure it in *ANY* manner they choose. What

you and the FSF are trying to do is strip that right from them.
If you have such a respect for peoples free...
[ message continues ]

My arguments are based on the intent behind the license, its spirit.
You keep falling back to legal technicalities, that have zero to do

with the interpretation of the intent.
That's why.
Maybe modification is not the best word, because it carries a lot of

legal background from copyright law.
How about adaptation.  From freedom #1, freedom to study the software

and adapt it to your needs.  Do you see how tivoization imposes an
This is still true.  This is not about the hardware.  This is about

the software, and how the user is stopped from adapting it to her own
So, if you visit www.fsfla.org, I 0w|\| your computer?
If you join a bit torrent, I can replace the operating system on your

computer?
Sorry, I don't buy that.  You're leaving something out of this
Huh?  Are you implying that the Free Software foundation wrote this
Because they're disrespecting others' freedoms.  Freedoms aren't

absolute.  One's freedom ends where another's freedom starts.

Tivoization exceeds the hardware manufacturer's freedoms and

disrespects users' freedoms and disrespect some author's ethical

intent.
--

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}

-

But each of those arguments is based on a technicality. By your reasoning I

could kill everybody living in the middle east to stop the wars there and not

be wrong - after all, you say "But I'm using those technicalities to show the 
Do you know how many lawyers make a living because the "spirit" of a law has 
Nothing stopping people from doing that with the GPL'd software running on a 
Nope. Because I'm connecting the the *INTERNET*. The internet is not owned by

any one person or "legal entity" - therefore there is nobody that can demand

a certain configuration. Note that I also made it a point to mention that it

only applies to certain classes of networks - in the US there are laws that

remove the "complete control over configuration" from telecommunications

companies. But get a cable-modem in the US and your ISP has the right to

configure it in *ANY* way they choose.
The TiVO service runs as a network - and a non-public one at that. They own

the network, they control what hardware and with what configurations is

allowed to connect. Whats more is that they have the right to actively

control that configuration.
You do realize, Alexandre, that you can't make me look stupid by just cutting

out a part of a statement I've made and making silly comments about it. If

you are going to quote something I've said, make sure you quote the *ENTIRE*

effective part and not just the bit you think will make you look smart. All 
Nope. I was making sure that you understood your own propaganda. "Free as in

beer" - if I get a free beer I'm getting the beer, not the glass. If you

aren't intelligent enough to understand what I'm saying: I get the software

and *ALL* rights to it that everyone *BUT* the licensor has under the GPL.

What you are doing is saying "It is what is said, but not what is meant."
The funniest part of it is that you are claiming that the "spirit" of the GPL

is to force each licensee to give up *MORE* rights than they are asked to. In

other words... TiV...
[ message continues ]

They're based on the Free Software definition, that establishes the

four freedoms that the GPL was designed to respect and defend.
Each version of the GPL may miss the mark.  But this doesn't mean
Yes.  What's your point?
All I'm trying to show is that the tivoization provision in GPLv3 is

not a departure from the spirit of the GPL.
Is this so hard to understand?
I'm not trying to say why Linus and others chose the GPLv2.
I'm not trying to determine what their motivations were.
I'm not trying to force them to change to GPLv3.
I'm not trying to convince them that tivozation is a bad thing.
I'm only trying to show that anti-tivozation is in line with the

spirit of the GPL.
tivoization, which means to restrict a user's ability to adapt the

software to their own needs and run it for any purpose, while the

hardware manufacturer keeps this to itself, is against the spirit of

the GPL.
Not whatever reasons the Linux developers had to release their code

under GPLv2.  But the spirit that the authors of the GPL tried to

encode in it.
Is the connection with the TiVo network not through some other
As long as this doesn't violate any other laws or agreements they've
Didn't mean to, sorry if it seemed that way.  I still don't quite
No, the GPL doesn't force anything.  It can't.  All it does is to

demand respect for others' freedoms in case one decides to modify or

distribute the software.  It's only if you do modify or distribute the

software that you must respect others' freedoms.  And TiVo does

distribute the software.  But it doesn't respect the freedoms.
It's not just that.  They actively stop you from being able to do so.

They do this so as to prevent you from changing the behavior of the

program that runs on that box.  They disrespect the freedoms to adapt
And, guess what, you *can* do that.  And it's up to the hardware

manufacturer to decide whether they want to use distribute your

software along with the hardware or not.
Whether this would q...
[ message continues ]

... and anti-tivoization section shows all symptoms of going in wrong

direction, *whether* *tivo* *is* *good* *or* *not*.  It's full of

kludges exactly because it tries to carve out a notion that can only

be determined on case-to-case basis and not by generic definition.

And no, that's not a matter of bad wording in that section.
I don't _care_ whether it breaks spirit, etc. - it's a fundamentally bad

idea for completely independent reasons.  Even if one thinks that tivo

in particular ought to be sued into the ground at some point.
Besides, it's fscking *pointless* for userland stuff.  If you insist that

e.g. glibc will infect by linking, you've just created a huge problem for

any GPLv2 userland code, which will make all bad blood about kernel look

trivial in comparison.  If you do not, then you've lost all leverage anyway;

kernel won't switch, libraries are OK, toolchain is obviously OK for building

code with any license... what's left?  The glorious /bin/cp?  Sorry, it would

work as usual, subject to open(2) not returning EACCES.  Just as on any

system.  Just what is it going to prevent?  Hell, they can slap selinux on

the box, protect what they want to protect, use crypto-loop to prevent offline

modifications of filesystem and hide the key in firmware.
Either GPLv2 is sufficient in given case (and e.g. Alan decides to go

after company in question), or you've at most created a moderate amount

of work rewriting the checks they are doing into a different form (if

that).  Good job.  In the meanwhile, you've got a load of ill-defined

verbiage around installation instructions.  I.e. a lovely fodder for

potential abusers.
Sod it.  GPLv3, with your involvement in its development or not, sucks

rocks, thanks to what you call anti-tivoization section.
--

How many GPL spirits can dance on the end of a pin?

-

I agree it's a very difficult definition.  I'm not sure I'm happy with

the wording in place right now.  But I very much like and agree with

its purpose, and it is in line with the goal of respecting and

defending users' freedoms, which is what the FSF cares mostly about,
That's what I care about, and I've seen false claims that it does.
Can you please acknowledge that it doesn't, such that I can feel I've

fulfilled my goal of dispelling the myth that the GPLv3 changes the
Is it correct to say that you share Linus' opinion, that the only

problem with the GPLv3 is the anti-tivoization provision?
To make this more concrete, if there was a hypothetical GPLv2.9,

consisting of GPLv3dd4 minus the "installation information"

requirements for user products, (i) Would you consider it a better

license than GPLv2?  (ii) Better for Linux?  (iii) Enough to go

through the trouble of switching?
I'd love answers to these 3 questions from others too.
Just in case, I shall point out, one more time, that I'm speaking for

myself, not for the FSF, not for FSFLA, not for Red Hat.  The

questions above are to satisfy my personal curiosity.  I don't make

any commitment whatsoever to take the answers up to the FSF, and I

don't want to set any expectations as to whether they could or would

make any difference, at this point, about the outcome of GPLv3.
If you want your opinions to stand a chance to make a difference, the

right place to provide them is gplv3.fsf.org/comments, and time is

running short.
--

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}

-

No.  I don't do metaphysics.  This thread alone has shown that the

notion is not well-defined *at* *all*, to the point of being useless

and seriously misleading.  I.e. the phrase about similar spirit

should be replaced with something far more explicit and very, very

hard to miss.  I don't think you need more proof that people *do*
No.  If you want a basic splitup by sections compared to GPLv2,

	1	-	at least not better; attempts at being precise

			end up creating a no-common-sense-land *and*

			turn out to leave serious unanswered questions

			in that area.

	2	-	no opinion on actual changes

	3	-	more or less an improvement

	4,5	-	about on par with v2, modulo wording in (5)

	6	-	much worse

	7	-	if I want to give additional permissions, I don't

			want them stripped, for fsck sake!  There is a

			bog-standard mechanism for _that_ (dual-licensing),

			thank you very much.  I.e. that section looks like				a pile of dishonest PR games, pardon the redundance.

	8	-	on par

	9	-	on par, modulo piss-poor attempt to define "modify"

			backfiring here (e.g. prelinking constitutes

			modification according to it, so does running rdev(8),

			etc., etc.)

	10	-	no opinion on actual changes

	11	-	improvement

	12	-	on par (aside of basic bad writing, but there are

			much worse problems *not* with wording, so that's

			not interesting)

	13	-	special-case kludges are fun, aren't they (specifically

			"linking"?), but in any case, that's secondary.

			FWIW, I'm not fond of ideas behind Affero, so if

			anything, that's a point against v3.

	14	-	... and thank you very much for keeping such a lovely

			source of periodic clusterfucks in v3 as well.

			I think it's painfully obvious for everyone in this

			thread that reference to "spirit" is a recipe for

			massive disagreements down the road.  If you want the

			words you are using to be interpreted your way, use

			ones that have commonly agreed upon meaning.  The

			measure is "do other people read it differently?",

			not "how sure I am ...
[ message continues ]

This is a very good idea.  Would you please file it at
Thanks for your detailed analysis.  I wish I knew what to do with

it.  (I decline impolite suggestions, thanks ;-)
Would you like me to put you in touch with Richard Fontana, one of the

lawyers involved in GPLv3, that's regarded as a legalese compiler, to

discuss your issues about wording with him?  Or would you rather file

them (with a bit more detail) at gplv3.fsf.org/comments?
Aside from wording issues, which appear to dominate your comments, is

it fair to characterize that your objections to GPLv3 are

anti-tivoization provisions (strong) and Affero compatibility (weak?)?
I'm setting wording issues aside because these are easier to fix once

the problem is understood, rather than ideological differences, that
additional permissions are indeed a form of dual-licensing, but one

that doesn't require one to create a copy of the GPL and add the

additional permissions to that copy.  Yes, it could be accomplished

with dual-licensing terms such as "you can follow the terms of the

GPL, with the following additional permissions".
I don't quite see the point of criticizing this.  This is more

informative than anything else.
The meat here is really in the few additional restrictions, and the

provisions to combat the practice of adding restrictions on top of the

GPL and claiming the software is available under the GPL, which has

made for a lot of confusion over time.
Thanks a lot for your feedback.
--

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}

-

If you honestly think that the "anti-tivo" clause in GPLv3 will be

removed just because we start to add more comments to that page, then

you are sorely mistaken.  From the very _beginning_ of the v3 process

the kernel developers have showed their objection to that section of the

license, and we were told, to our face, with no uncertian terms, that it

was going to stay, in one form or another, no matter what we thought or

said about it.
So, why would we want to waste our time filling out web forms after

that?
greg k-h

-

In case anyone was wondering if the FSF is genuinely interested in

feedback - I went and made some comments on the draft, and they appear

to no longer be there a few days later.  Thanks for the invitation Alex.
Bernd
-

This would be very bad.  Please let me know what they were about and

I'll try to figure out what happened.
Did you by any chance file them against an earlier draft?  Those (for

obvious reasons) no longer appear against the current draft, but

they're still accessible by other means.
--

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}

-

I agree that adding comments wouldn't accomplish this.
But many objections were about the wording, about cases that perhaps
If you're adamantly favorable to permitting any form of Tivoization

whatsoever, don't bother.
Others who aren't so fundamentalist as to reject anti-tivozation on

ideological grounds, in spite of evidence that such measures would

advance the very pragmatic interests they claim to place above

ideology, might be willing to help shape these provisions so

that they don't hurt those who respect users' freedoms, but accomplish

the goal of keeping Free Software Free.
Seriously, looking only at the downside of anti-tivoization (tivoizer

might turn us down), without even acknowledging that, should the

tivoizer change practice and respect users' freedoms, you'd be able to

get far more contributions from all those users, is typical minimax

strategy.  That's the worst case for the prisoner's dilemma.  That's

not pareto optimal.  It may not be a losing strategy, but it's not the

best strategy for everyone.
Every time you enable someone to disrespect other users' freedoms WRT

your software, you cut yourself out of some contributions that user

could make.  Even if you completely disregard the moral and ethical

aspects of software freedom, the open source mentality inherently

depends on the notion of respect for others' freedoms.  You only reap

the benefits of open source when the user gets the freedoms respected.

That's why preventing people from hiding source code, from using other

technical measures, and from using copyright, patents and

anti-circumvention laws, to stop or decrease the possibility or the

incentive for a user to contribute to your community is not only a

great ethical and moral stance, it is also self-beneficial, in the

very sense that Linus and others claim.
So although I like to highlight the moral and ethical aspects, and

others like to highlight the self-beneficial mechanics of the system,

they are really two sides of the same coin.

...
[ message continues ]

For the record, I completely feel that what Tivo did was both legally

correct[1], and the correct thing to do for their system, and would

fight _very_ hard any attempt to change the Linux kernel's license that

would prevent this usage model.
So I will not bother anymore.
greg k-h
[1] The FSF lawyers also agree with this.

-

Linus has spoken, Greg K-H has spoken, many other people spoken ---

and yet Alexandre keeps on speaking, and speaking, and speaking....
It's pretty clear no one is convincing anyone, and that everyone

understands their position, and are happy with it, and so all we're

doing now is wasting bandwidth.
Can we please end this thread?  
Please?
						- Ted

-

Alexandre, while I backed you up on the whole "spirit of the GPL

hasn't changed" thing, I think you are wrong here. As Jesper, Johannes

and others have already pointed out (in a couple of the very few

cogent non-flames since this thread started), we undoubtedly get more

back in the form of software contributions from paid developers of

TiVO-like companies than from the very few end users with the skill to

hack the software or the inclination to aquire said skill. The simple

fact is that most end users of most electronic devices don't care

about the Freeness of the software, they care if their device works.
If you disregard the ethical dimension, I think it's hard to argue w/

a straight face that Linus' stance is wrong from a pragmatic

standpoint.
The problem is that the people saying "just don't buy TiVOs" know full

well that because the number of end users who care is so small, they

have _no_ economic power to change the situation, and that's why

people who do consider this an ethical issue want to leverage the

power the copyright holders have both legally and by virtue of their

expertise to force the hardware vendors to cooperate w/ end users.
Dave

-

Thank you, this is the first time someone voices a coherent argument

that doesn't completely dismiss the potential benefits of prohibiting

tivoization, and doesn't focus only on the potential downsides of such

measures.  Even though you come to a different conclusion than I did,

I thank you very much for not pretending the point does not exist at
This is also true of computer users in general.  So what is it that

makes this case different?
Why should we ask vendors to pass on the corresponding sources to

users, if most users don't care?
Why should we ask vendors to not use patents to stop a user from

modifying and sharing the software they distribute, if most users

don't care?
What is it that makes the reasoning different for the particular case

of vendors using technical tricks to stop a user from enjoying the

benefits of modifications she could make herself, which could then
Maybe I'm wrong, but I hadn't seen arguments that even pointed in this

direction, so the complete dismissal of the upsides came off as

selective attention.
Yes, your reasoning makes sense to me.  I can't speak for the FSF's

intentions, but I have no reason to disbelieve it's moved by ethics,

rather than by some plot to hurt TiVo.
--

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}

-

do you realize that redhat uses checksums or signatures to check the

validity of their CD's?
try to burn a redhat image with the -pad option which adds a chunk of 0's

to the end of the image and try to boot it.
I seriously doubt if redhat tells you how to how to generate such a

checksum/signature.
in addition to the problem that Linus points out about being unable to

change the contents of the write-only CD this would seem to conflict with

what you are claiming the GPL is supposed to allow.
David Lang

-

Mixing two different issues here.
The checksums embedded in the ISO images are implemented in anaconda

itself, provided along with the distro, so anyone can generate them,

even though I don't know the precise algorithm.  The checksums over

the ISO images themselves are implemented with sha1sum (earlier,

md5sum), so anyone can generate them too.
As for the GPG signatures in the RPMs and in the SHA1SUM file, these

are indeed generated using public algorithms but private keys.  But

these signatures are not functional, and they don't in any way stop
It looks like you read only Linus' messages, not my responses.  A

write-only CD is like ROM.  It's not the distributor who's imposing

restrictions on its modification.  Nobody can modify it because nature

says so.  It's not like the software is being recorded in a CD as a

means to prevent you from modifying 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}

-

It'll boot and run just fine.  The checksum is simply an optional

integrity check (you can bypass it by choosing "Skip" when it prompts to
You are seriously wrong then.  The tool is in the anaconda package, and

there are docs on using it both there and many places on the web.

-

And what gives you or the FSF to define what "Free Software" is? What makes

the definition you are using is the correct one?
But it doesn't matter. You're backpedalling, tossing up a smokescreen because 
Nope. As I've stated before it doesn't matter that you believe it. What

matters is that there is no single, definable "spirit" of the license.

The "spirit" is what each person who places their work under the license 
But you have done this multiple times. You may not have been trying to, but 
I'm a firm believer in letting people hang themselves, but this is a bit much.

The TiVO company didn't do that. They kept the ability to *REPLACE* the

version on the device that connects to their network to themselves. You have

access to the source code TiVO uses, complete with their modifications... You

can modify it in any way you choose *AND* you can distribute the code

yourself. Hell, you can even *RUN* it for any purpose you want. What you

can't do is replace the functional code on the device connected to their 
But your server doesn't run the internet. TiVO may use phone lines to connect

a device to their server (and this is an example - I don't know how TiVO

devices actually connect) but the network being connected to has a single

owner who can set such terms. 
I'll repeat, in full, my earlier examples of this:

The first:

I buy a cable modem. Until the second I connect the cable-line to it so I can

get a connection to the internet I can configure it in whatever manner I

please. The second the line is connected, even though I *OWN* the hardware, I

lose all control over its configuration.
The second:

I buy a DSL modem. Until I want to actually connect to the internet it can

have whatever settings I want it to have. The second I want to connect to the 
And if the license doesn't explicitly state something as being a violation of 
I agree with you. If I buy the hardware I should have control over it - 
I actually disagree with you. My feeling is that a...
[ message continues ]

Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl

orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf?
One moment, let me retune.
What in the world makes you think there is a useful analogy

between communication standards and copyright licenses?
Neither law nor common sense give much common ground to the two,

except in the general sense of two parties interacting.  One is a set

of rules so the two can interact through some information channel.

The other is a set of rules so that one can exploit a creative work

developed by the other.
I suppose that you think it is acceptable for someone to offer access

to binary and source versions of GPLed software (with or without

modifications from commonly available versions) -- but only on the

condition that people never download the source versions?  That

certainly corresponds to the idea that Tivo can keep proprietary

extensions to the kernel if Tivo's customers want to connect to Tivo's

network services.
Your reliance on counterfactual arguments severely undermines your

position -- whether the fiction is how Tivo devices connect (a quick

search on Google indicates that Tivo recommends a broadband Ethernet

connection rather than a phone line) or that we should analyze based

on DRM signatures distributed separately from the kernel (when they

are not).  We are arguing about the universe we inhabit, not some

alternative where the GPL might actually be the Groundhog Petting

License.
Michael Poole

-

I don't. I was *REPEATING* an example of how TiVO has a *RIGHT* to change the

kernel or any other facet of the device connecting to their network. That

right *ISN'T* tied to copyright - as you have stated. Since it isn't, why is 
Nope. Because that isn't a right they have that is disconnected from copyright

law. Or did you not read the entire post and just decide to try and make me 
At no point have I claimed to know how TiVO was accomplishing the "connection

to the service" or how they were handling the signing of the kernel. If the

final binary is altered by the signing process then, IMHO, the signed kernel

and everything involved in creating it constitutes a "derived work".
My argument is that, as much as people want it to be different, in mandating

that people give up rights that are (potentially) disconnected from the

copyright - in order to "Defend the Four Freedoms" and keep "all users of the

licensed work equal in their freedoms" - the GPLv3 is flawed and potentially

unenforceable. 
--

Dialup is like pissing through a pipette. Slow and excruciatingly painful.

-

Since you're talking about rights, and that's a legal term, and we've

(hopefully) already established that intent of license author, intent

of copyright holder and letter of the license are different concepts,

and only the last of the 3 has to do with legal terms, I'll excuse

myself from the plane of spirits ;-) and get down to legal terms to

shoot down your argument.
Let's see...  US law states that (paraphrasing), if you grant a

copyright license that says the person can do such and such, you can't

later turn to that person and say "oh, BTW, I have this patent, and it

means you couldn't do such and such in the first place, unless you pay

me a gazillion bucks"
Patents have nothing to do with copyrights.  Still, a copyright

license can (and does) limit the ways in which you can use the power

that patent law gives you.
You could try to argue that "you have a right to the patent, and to

use it however you like".  But the moment you accept a license such as

v1, v2, or any later version to be published by the FSF, you give up

the power to use that patent to stop users from fully enjoying the

freedoms that the license granted them and said you couldn't further

restrict.
s/patent/anti-circumvention measure/
s/patent/hardware/
See?
Now, why would we be revising the license, if it's all already there?
First of all, to make this all clear.
Second of all, because law does not operate this way.  While there is

case law that establishes that copyright law supersedes patent law in

this sense (or so I'm told, I don't have the references and IANAL),

it's not clear that the same would hold for the DMCA, or technical

measures, or even discriminatory agreements.
So, in order to provide users with a better defense against these

dangers for the freedoms, the newer revision clarifies them, such that

whoever attempts to deny users' freedoms has a weaker defense for such

attempts, in a copyright infringement lawsuit.
--

Alexandre Oliva         [ message continues ]