"Ours is Ours, Yours is Yours" is gone from the GPLv3 ...

"Ours is Ours, Yours is Yours" is gone from the GPLv3 ...

Ingo,

Thanks for the response. To continue:

> The contention that this somehow turns into a "right to tweak the
> hardware" is false.

Well, let's be careful about what we're talking about here. I agree with
you and others when you mention that some devices already put software
into ROM. If the FSF were trying to ensure a right to tweak hardware,
there would probably be language prohibiting putting GPL code into ROM.

By contrast, the anti-DRM provisions say "don't use technological means
to circumvent the license". I read that to say "if your design includes
the ability to change the software on the fly, since changing the
software is a part of the rights needed for free software, don't take
those rights away from the users of the code that is passing through
you".

So it's really not about the right to tweak the hardware at all. It's
very much about the right to tweak the _software_.

> The term "right to tweak" has been invented well after the GPLv2 was
> released, well after Linus released Linux under the GPLv2, and well
> after i chose to contribute under the GPLv2. I reject such a
> retroactive interpretation of a pretty clear license.

Well, I'm not using "right to tweak" as the language and I don't think
the new GPL is either. This is about defending freedoms 0-3:

- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and adapt it to your needs
(freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor
(freedom 2).
- The freedom to improve the program, and release your improvements to
the public, so that the whole community benefits (freedom 3). Access to
the source code is a precondition for this.

We are talking about freedom #1. The Tivo device (sort of) adheres to #0,
does _not_ provide #1, does provide #2 and basically provides #3. You
can't adapt the program to your needs or the device will refuse to start!

And if you're thinking "ROMs don't provide #1 either", you're right. But
the FSF doesn't want to make hardware design decisions for manufacturers.
There are plenty of /other/ reasons for ROMs. But DRM chips that refuse
to run modified versions of the free software exist for no reason other
than to prevent the running of modified versions of the free software! In
other words, the denial of freedom #1 isn't incidental -- it's straight
up _intentional_.

> No-one in their right mind, neither i nor Linus ever understood that
> plain langugage to mean: "you have to allow to make binaries in ROM's
> modifiable". IMO that interpretation is often just wishful, revisionist
> thinking, possibly created by "oh what should we do about this DRM
> thing" thoughts.

I don't think "you have to allow to make binaries in ROM's modifiable" is
a fair or correct interpretation of the license. Is this what you think
GPLv3 actually does - require manufacturers not to put their binaries in
ROM's?

> But note that the section you cited talks about source code (i
> highlighted that in the quote above). Tivo gives out their modified
> kernel source code (a derivation of the kernel), and gives you the
> rights to use, modify and derive Tivo's added work freely. Tivo also
> gives you the right to distribute copies. Tivo completely lives up both
> to the moral and to the legal deal. What it does not give you is a
> totally separate piece of work: the hardware's keys.

As stated, Tivo doesn't respect freedom #1. Putting in a crypto
bootloader chip isn't "whoops, I incidentally failed to uphold Freedoms
0-3" -- it's "I'm going out of my way to design the device in such a way
as to lock up users and disengage freedom #1". You're right that they
post source code and whatnot, and I'm glad -- glad that they have chosen
not to violate the spirit of the GPL further.

> (That is, by the way, also a conflict in the position of the FSF: for
> decades they insisted that the GPL is a license, not a contract. But
> only a contract can affect works that are not covered by copyright law!
> So what is the GPLv3 now, a license or a contract?)

It's still absolutely a license. It doesn't affect hardware where the
covered free software does not exist. The reason there was always a
disctinction drawn between "license" and "contract" is because the GPL
has no requirements at all for a mere end-user. The only time the GPL
activates is when you voluntarily activate it in order to obtain
permission to redistribute the covered work.

> The contention that DRM and using crypto keys to protect hardware
> integrity is somehow new is false too. Intel has been using DRM since
> ~1996, ever since they made their microcode uploadable. RMS has been
> using it probably every day in the past 10 years or so, and he probably
> didnt even realize it. Would you want to run CPU microcode "modified"
> by a friendly virus writer?

I suppose you're right about the microcode example; thanks for the
history lesson (I've never read that part of the Intel docs before). Of
course, I'd like to point out that Intel doesn't run GPL microcode. I
think if they used someone else's work to implement the ISA, and then did
something specifically to artificially restrict people from changing it,
there would be great disappointment.

The virus writer example goes too far. My reason is an analogy on free
society - it would be like the police asking for us to give up our rights
so that we don't get stabbed by burglars or something.

> IMO this whole thing that to me appears to be a vendetta against DRM is
> largely misplaced and wastes our resources. And i'm asking, if it is
> this hard to make such a relatively simple issue understood by the FSF,
> if it's so easy to turn it into a nasty emotional and political issue,
> how will we be able to deal with more complex issues?

Vendetta against DRM? That's absolutely true. But I guess what is hard
for some people is seeing the line between the software license and, say,
Defective By Design. Regardless of any vendetta, the license adds the
terms "don't violate the license" out of necessity.

> I believe that in the light of this debacle the only sane and morally
> correct solution would be for the FSF to voluntarily give up power
> (which power is quite similar to unilateral relicensing power over a
> huge codebase)

I don't see why. I know you don't agree with them now, but you agreed to
this power of theirs whenever you contributed to any "or later" work. "I
was too lazy to take off that term" or "I didn't know" isn't a very valid
defense in the real world and it shouldn't be here.

And I also think that your "sane and morally correct solution" assumes
that the FSF is actively hurting you in some way. Really? Is it _really_
going to be a problem if some downstream recipient of some pieces of code
you've written under GPLv2 "or any other version" wakes up on January
15th and incorporates it into a derived work that goes on to say "and you
may not require encryption keys that only you have to run it"?

The FSF is not releasing a new GPLv3 that says "You may have this code to
do whatever you like with if you donate $50,000 to the FSF" or "You know,
you BSD guys were right... Copyleft was a silly idea anyway".

Or are you worried that the GPLv3 is going to catch on, and you
desperately want it stopped any way you can? (Sorry if I'm not being fair
with that remark, but based on some of your other comments I have to
wonder...)

> and to remove the "or later" language from the default
> COPYING file. Leave it up for authors to explicitly chose this if they
> trust them on it.

But that language is there for a reason, as a utility! It _is_ and has
always _been_ up to the authors to explicitly choose that.

I resent this notion that programmers are so lazy as to ignore the
standard GPL boilerplate. The damn thing is a few paragraphs long, and
the FSF advises you to attach it to the top of every source code file!
Don't you think you would at least reasonably read that before doing so?
Do you really think people would just blindly cut and paste away the
permissions to their code without ever giving it a second thought?

Perhaps there are some developers, in a minority, that did so and are now
surprised. But you want us to cede a very important utility we explicitly
designed and made no attempt to cover up, just because a minority of
developers was _irresponsible_ enough to totally ignore it?

> In fact: the FSF, just like Linus, should reject blanket authorizations
> of trust, like an open-ended "or later version" language.

Well, I trust the FSF, but that's a philosophical argument for another
time and place.

> Dont let inertia and laziness drive an important decision like that.

Ingo, if people are that prone to inertia and laziness, we're all
screwed, and that is their problem anyway - not the FSF's.

> That way authors of new code can judge the licenses on their merits
> once they are released

They can do that today. They can do as Linus has done, and state "GPLv2
only", then talk about the new license as it is developed and released,
or they can do as some people might do and strip "GPLv2 or later" off
after the fact if they don't agree.

And that is absolutely letting the authors decide. At that point if
someone wants to take the last "or later" version and derive off it a
GPLv3 branch, they are voting with their code, which in no way derives
the primary author from voting with their code too! (And I agree that
such forks are unfortunate, but sometimes they are a fact of life.)

> and the FSF can release new licenses at a much
> faster pace. "Release early, release often" applies here too.

If the FSF releases licenses at a faster pace, that is a sign that
something is _wrong_. The GPL is so beautiful because it has gone on so
long without revision. The current version will be 16 years old when
GPLv3 is born. And this one better damn well last a while longer, because
licensing changes are _painful_. Just look at how much pain this change
is causing us.

You might be tempted to speak as Linus has here - "The GPLv2 has no
problem. It works well in court. Don't touch it unless it's broken" but
then I don't think that is right either. Eben Moglen is doing what
lawyers do - proactively trying to prevent disaster. And I support him in
the fullest.

You mention "release early, release often". One of the big reasons for
that mantra is to get people _involved_. And pardon me if I missed your
reply to this question of mine, but I think you are still dodging what I
consider to be the very most important point I've been trying to raise
over the course of our discussion:

Why, Ingo, aren't you getting involved?

(sorry if that grates on your nerves, but I do think it's a fair
question...)