LWN: Comments on "Busy busy busybox"

FSF is creating a problem that never existed!

jzbiciak — Tue, 24 Oct 2006 22:51:31 +0000

I don't think that's going any further out of your way than saying "this is GPL." If you're sloppy when you pick your license, it's clear you don't really care what the license is. The real debate should center around people who thoughtfully chose "GPL v2 or later" who are now re-evaluating that choice. And, I argue, there's not a real problem there, since you can fork and move on.

I still don't see the issue with the "or later" language. If someone writes a GPL v3-only patch to a GPL v2-or-later program, the patched program is GPL v3-only. The unpatched program still exists, though. So, if someone else didn't like GPL v3, they could continue developing the GPL v2-or-later program, perhaps making the result GPL v2 only if they so desire.

FSF is creating a problem that never existed!

landley — Tue, 24 Oct 2006 22:34:31 +0000

> Firstly, keep in mind that the "or any later" language has always been
> optional.

Actually, you have to go out of your way to opt out. The last sentence
of section 9:

> If the Program does not specify a version number of this License, you
> may choose any version ever published by the Free Software Foundation.

So if you just said "This is GPL" when GPLv2 was the law of the land, the
FSF gets to arbitrarily relicense it because you didn't go out of your
way to say they couldn't.

Tivo sucks

blujay — Fri, 20 Oct 2006 10:52:45 +0000

I know this is an old thread, but...

The answer is: Don't buy the Tivo! You keep using an argument
of, "Imagine if *your* Tivo...." If that was an issue for me, I would
simply not buy the Tivo! Vote with your wallet and give your money to
those that make better (and perhaps more open) products.

Imagine a situation where Linux went GPLv3. Can you force Tivo to start
using Linux/GPLv3? Or will they A) continue using Linux/GPLv2, or B)
switch to something not licensed under GPLvx, perhaps even a BSD?

I read a comment earlier that basically said, "I think we're important
enough now that we should flex our muscle." That strikes me as a bit
arrogant. Those that feel this way about GPL-ed software may be in for a
surprise when they find out that these device manufacturers they're
trying to coerce don't really care about Free Software at all; they're
interested in practicality, much like the kernel devs, and will quickly
ignore any GPLv3 software, and even switch to proprietary software. Then
what have you accomplished? Well, "your" Tivo will be no more hackable
than it is now, and probably less so. Free Software will become less
relevant in these industries (which I'm not sure matters anyway; again,
vote with your wallet). Microsoft will probably be happy and you might
even see some "Powered by Windows Vista technology" stickers on "your"
Tivo.

Linux and Free Software are getting some pull in enterprise systems, it
seems, but I think some people overestimate their value in these kinds of
embedded systems.

Busy busy busybox

ras — Wed, 18 Oct 2006 11:44:05 +0000

corbet said:
> the attempt to address this problem in GPLv3 carries a high
> risk of splitting the development community.

After reading the 400 or so responses to the two GPLv3 articles, you would have to say: "QED". That makes the article unique (for me at least) in one way: the response to it proved its point.

The responses also gave me an insight I didn't have before. I didn't understand why the division was so ferocious. Now I do.

One side is about sharing the end result. Eg, "You can't use my software in anything and that can't be modified like my software can". Tivo, with its DRM restrictions preventing them from changing it by modifying software they wrote and own, is an anathema to them. GPLv2 was always intended to enforce their rights over their code, and the fact that it has been circumvented now by, of all things technology, is a bug - a betrayal by the very thing they were trying to share. The whole point of the "or any later version" clause was to fix bugs like this, and that is exactly what they are going to do.

The other side is only interested in protecting the software. It is all about the software. Its about writing it, but more importantly its about having lots of useful software others have written available for them to use. The GPL created this huge software commons that just gets more valuable to them over time. Whether the software can run on device X or not doesn't effect the benefit they get from it overly - the code written by Tivo is still available, and will still work on other boxes. What is important is that it becomes ubiquitous, so that no-one can economically write software without using the commons and thus will be forced to contribute back to it. The GPLv3 will eliminate an entire class of software that can be contributed back. For better or for worse, its looking increasingly likely that content the public expects to access with their computers can only be viewed with the software that is going to be eliminated. So in one foul swoop the GPLv3 may remove the bulk of the users of the software commons the public, thereby reducing its value considerably. To rub salt into the wound, the "or any later version" means that their code, code that they put their own blood and tears into, will be hi-jacked by this miss-guided enterprise.

Two view points. Both valid. Both protecting something almost sacred to their holders. Yet diametrically opposed.

GPLv2 or, at your option, any later version

malor — Sat, 14 Oct 2006 22:51:43 +0000

Yes, I realize that key kernel developers don't like this. However, in watching their verbal gyrations on the issue, I have come to the belief that this is not because of any particular ideal of free software. Rather, it appears to be because the GPLv3 will slow the adoption of their pet project and, thus, the spreading of their fame and future employability.

The whole point of the GPL is that I can't use your code, distribute it to others, and keep rights to myself that I don't give to my end users. If I load it onto a device, but retain the right to modify software in the device, they must also have that right. And your assertion that I can only install modified software with their permission is incorrect. The fact that most manufacturers have been polite and done so, does not mean that they are required to. If I'm the manufacturer of a Tivo-esque device, I do not have to ask for any permission from anyone to update 'my' device.

And no, calling it stealing isn't wrong. Copyright infringement is not theft, because the producer of music/movies/whatever isn't deprived of anything, except possibly a potential sale. But in the case of software, part of the original agreement is to allow end users (including the original author of the code) full rights to any distribution of that code.

Distributing it in a locked hardware device does indeed deprive the original developer of something, the ability to use the device in the way he or she wants. 'Stealing' is perfectly appropriate; they have taken something from you and not fulfilled their primary responsiblity, which is to give end users the exact rights that they have. You have a clear and demonstrable loss.

If the FSF bends to the pressure of the loud kernel devs, they are trading away the future of their entire movement for a little near-term success for one project. They permanently relegate software developers to second-class citizenship behind hardware manufacturers.

I think they know that, and I hope they will refuse to bend on this issue.

GPLv2 or, at your option, any later version

sepreece — Sat, 14 Oct 2006 20:22:06 +0000

As you must know, if you've been paying any attention to this issue, many key kernel developers, among others, disagree with you that this is even unfair, let alone illegal. Note also that the manufacturers, in your example, are NOT witholding the code, only the right to modify the device by installing new software. Note also that they generally do NOT retain the right to modify the software in the device, since they generally no longer have access to the device. The only way they can install modified software is if you let them, either by asking them to ("run iPod updater") or by subscribing to a service that may load new firmware (like Tivo service). Since they are then acting as the owner's agent, I'm not sure there's really an issue here at all...

Referring to it as "stealing", in any case, is just wrong. Copyright infringement is not theft, regardless of what the RIAA and MPAA would have you believe.

GPLv2 or, at your option, any later version

malor — Fri, 13 Oct 2006 19:21:52 +0000

Of course I describe it as stealing. The whole point of copyleft/GPLv2 is that the original author of the code maintains full rights, but gives up some of those rights voluntarily. In exchange, all other users of the code cannot reserve more rights for themselves than people they give it to.

That's really it. That's the contract. If you write Neato Program A, and kindly give it away under the GPL, I can build on that and make it into Neato Program B. But I can't distribute it in such a way that my downstream users can't add on to make it Neato Program C. And none of us can distribute it in such a way that YOU can't take our changes, incorporate all of them into Super Neato Program D, and then freely distribute that as well.

If I, as a device manufacturer, want to make a non-modifiable device that I can't change, I can use GPL code to do that. But I can't reserve rights for myself that my end-users don't have. If I can modify the device, they must be able to also.

Tivo, in other words, is stealing code. They are taking the kernel code and releasing a locked device with it; they are using GPLed code with a hardware addition to reserve rights for themselves that their end users don't have. If they want to release a locked device, that's fine, but then they can't piggyback on the work of thousands of volunteers. They have to create the device themselves, with their own code, or buy it from someone that has the right to release it under a non-GPL license.

If you argue to the contrary, you're in favor of giving hardware manufacturers special powers to enslave those who write software. You're relegating the software guys to second-class citizenship.

WOW! Community soap opera - and then some!

sepreece — Fri, 13 Oct 2006 02:25:20 +0000

"Not leaving with slamming doors" doesn't necessarily imply "comfortable", "satisfied", or "believing they have been listened to". Nor are the interests of all businesses necessarily aligned.

It could be that some are continuing to participate because they believe they can get small improvements (removing ambiguities in the license is a benefit even if the unambiguous answer is not the one you would have preferred) and don't want to burn their bridges.

It could be that some are continuing to participate because they favor non-free software options and want to make it harder for others to benefit from using free software.

GPLv2 or, at your option, any later version

sepreece — Fri, 13 Oct 2006 02:13:11 +0000

You describe it as "stealing" when a manufacturer uses your code in a device, but doesn't give you the right to modify it in the device. How is that any more "stealing" than, for instance, using it inside a company, embedding it in a device you can't afford or just don't want, or putting it in a device in ROM so that it can't be modified?

If you choose to consider it unfair, that's a choice that I think you should be free to make, but it's no more "stealing" than unauthorized copying of content is "stealing" or "piracy".

WOW! Community soap opera - and then some!

Zack — Thu, 12 Oct 2006 23:06:08 +0000

>>They don't see the value that business brings to the table and they have a deep and entrenched distust of people of influence or people of wealth.

They invited major "shareholders" of Free Software to the table for discussing the upcoming GPLv3. So far none of them has left with slamming doors.

The FSF has always seen the importance of commercial endeavours regarding Free Software. In the spirit of the four software freedoms, it is the task of the FSF to safeguard "the right to make a profit" against "the right to make a profit by trampling users rights"

The large shareholders who hold considerable economic assets regarding Free Software are expecting the FSF to listen to their concerns that none of their competitors gains an unfair advantage by unifying on a common ground. In return the FSF wants to define a level playing field where denying users rights cannot be used as leverage.

Basically what you mean by "They don't see the value that business" is "They refuse to cater to the advantage the business I am in gains by supressing the four software freedoms."

>>Business has invested too much in open source to walk away now. Business is not evil,

No, evil business is evil. Good business is good.

>>Many in the world believe that people starving to death in the Sudan is an issue worth getting worked up about, whereas hacking in to a Tivo box may be fun, it is not an issue that has any real bearing on mankind.

Most people aren't in a position to charter a flight and drop food packages over a starving population. However, some are in a position to close the digital divide and create a low-treshold perspective for people wanting to improve their lives.
Countries suffering from hunger are not in a position to take advantage of such technologies yet. But should they reach that stage the opportunity to succeed on technical merit guaranteed by the four software freedoms should be available to them.

Software (and software freedom) has a real bearing on mankind, and this will only increase as time goes by.

>>Thus, a giant fork between those of us who are mainstream and earn a living from Open Source and those of us who are fringe and want to impose their views of society through Free software is inevitable.

This is disingenuous at best; to label those who support Free Software as "fringe" and imply they do not earn their living with it.

GPLv2 or, at your option, any later version

malor — Thu, 12 Oct 2006 08:04:10 +0000

Right, but with Trusted Computing, you will not be able to do that anymore. If the kernel isn't signed with Tivo's private key, it won't run on that hardware, period.

Is it okay if they put chains on stuff if you know how to break them? What happens when you don't know how to break them anymore? You can go from A to B almost overnight, and if you don't have any legal protections in place, don't you think they've stolen your code?

It strikes me that just the ATTEMPT to steal your code, even though they may not succeed, is highly noxious, and something to be prevented.

Think of the DRM provisions in GPL3 as a life preserver. The real things are a little awkward to wear on a boat, and make your day a little less fun. But if you need one, you REALLY need one, and you'd better have put it on ahead of time.

GPLv2 or, at your option, any later version

dlang — Thu, 12 Oct 2006 03:26:47 +0000

tivo gave us their code (it turns out that not much of it is wanted, but that's not a requirement)

as a result tivo boxes are extremely hackable, once you jump through the initial hoops to defeat the encryption

Baldrick, have you no idea what irony is?

robilad — Tue, 10 Oct 2006 16:35:40 +0000

"Yeah! Its like goldy and bronzy, only its made of iron."

I think it's very funny to hear Linux kernel devs calling GPLd forks of existing code bases 'parasitic', when the Linux kernel itself contains a not so insignificant amount of BSD licensed code.

I guess one man's 'parasite' is the same man's 'liberator of too liberally licensed code', depending on which end of the leaching^W merging chain he stands.

Who is doing harm here?

malor — Mon, 09 Oct 2006 17:01:59 +0000

In my opinion, the difference is that the FSF is thinking about freedom in a multi-generational timeframe, and the kernel devs want success/market dominance *right now*. And they appear willing to trade off freedom to get it.

If you think about it from the perspective of tens or hundreds of years, Linux is not that important; it's essentially the early scaffolding for a great cathedral of code. But, unlike the real multi-hundred-year cathedral projects, I don't think these scaffold builders are even aware that a cathedral will ever exist.

The FSF is right not to bend on this issue; if we want truly free computers, it's incredibly important. Eventually, GPLv3 code will be such an overwhelming presence that it would be insane to try to compete with it in any but the smallest niches.

If, however, the foundation is flawed, the cathedral may collapse. The architect has identified flaws in the design, and is redrawing the blueprints. The scaffold builders are upset about this. Either the cathedral won't look quite how they thought, or they think their project IS the cathedral.

The most popular free kernel, a hundred years from now, may even be called Linux, but it will be related to today's kernel only in the sense that modern man is related to the chimpanzee. But the GPLv3 may very well still be in force. Law, especially good law, lasts a LOT longer than code.

GPLv2 or, at your option, any later version

malor — Mon, 09 Oct 2006 14:48:46 +0000

If they don't use Linux, so what? Does Tivo give you anything?

Some customers are bad. Some market share is share you don't want. What benefit is there for you in having DRM-locked Linux kernels on the market? From this perspective, it looks like they just stole your code and locked everyone out of their device. They're bad customers, market share that costs more than it's worth. For a few more share points, you trade away your freedom to fully use any device that uses your code.

The GPL code base gets bigger every year, and harder to compete with. Success is absolutely inevitable, if you are willing to be patient enough. At some point, the base of GPL code will be so enormous and so *good* that it will be economic suicide to try to compete with it. That may take another generation, maybe two. But eventually, there will simply not be room for closed licenses on mainstream products anymore.

The problem is that you're not thinking big enough. If you think in a multigenerational timeframe, the Linux kernel is not *that* critical. Code can be replaced, but lost freedoms are damnably hard to get back. Changing the GPL to suit any one project, even one as large and important in the present day as Linux, will have unpleasant ripple effects for decades.

It appears that you want the project you've put your whole life into to be wildly successful. And maybe you were never one who particularly cared about this particular issue... maybe it's okay, from your perspective, for someone to sell you a device running your own code that you're not allowed to change. Or maybe you're willing to overlook that if it means your project becomes dominant in the marketplace.

But for the FSF, whose goal is software freedom, not the success of any particular project, it would be very foolish to do what what you want. Their goal is freedom for generations; yours appears to be success over the next few years.

I wish you both well, but IMO, the FSF's goal is important to the entire world, where yours is important primarily only to Linux kernel devs.

Why would they care if you change the code?

malor — Mon, 09 Oct 2006 14:18:21 +0000

I'm not sure whether or not this was sarcastic, but if a company doesn't choose Linux in its DRM-locked product, what does Linux lose, exactly?

You are willing to sacrifice your freedom for a few points of *market share*? WTF are you thinking? The whole point of an open source operating system is to be free, except when freedom would result in a few less locked-down systems running it?

Yes, requiring DRM keys will reduce Linux's market share. But the whole point of a free-software operating system is that market share doesn't matter. It's irrelevant. You're giving away the one thing in the whole deal that really matters for a shiny but meaningless bauble.

I'll give you three beads and a blanket for Manhattan. Deal?

Re: the beef

nim-nim — Sun, 08 Oct 2006 09:12:08 +0000

> As noted elsewhere, there are disadvantages to using ROM.

But are the disadvantages sufficient to refuse using GPLv3 software if it implies ROM?

> And it's usually sufficient to make it difficult to modify, so the user
> clearly has to jump over intended barriers (and thereby demonstrate that
> it's their fault, and not the manufacturers).

This part is easily done without blocking GPLv3 by making the update process interactive and spewing big red warnings if the updating binary is not signed by the manufacturer

Re: the beef

sepreece — Sun, 08 Oct 2006 01:44:36 +0000

If the TC is good enough, there's no need to go to ROM. As noted elsewhere, there are disadvantages to using ROM. And it's usually sufficient to make it difficult to modify, so the user clearly has to jump over intended barriers (and thereby demonstrate that it's their fault, and not the manufacturers).

I'm neither a lawyer nor on the business side; I don't know what factors they use in deciding how hard to make it to crack the security.

Bruce following ESR

mjg59 — Sat, 07 Oct 2006 15:01:14 +0000

Bruce claimed that Userlinux was ready to ship the moment Debian did. It turned out that this wasn't actually true - even if Debian had released six months or a year earlier, there's no evidence to suggest that Userlinux would actually have appeared anyway. Ubuntu ended up being many of the things that Userlinux was intended to be, and had successfully generated a technical community even before releasing the first version of their software. If you go back and look at the Userlinux mailing list archives, it's pretty clear that that wasn't happening for them.

Why would they care if you change the code?

nim-nim — Sat, 07 Oct 2006 14:35:01 +0000

Think it will fare any better if DRM is generalized?

Hint:
1. any general-purpose computer nowadays is multimedia-capable
2. media companies want to control all the devices able to play their stuff

Re: the beef

nim-nim — Sat, 07 Oct 2006 12:44:44 +0000

> "But, yerhonnor, we used GPLv3ed code because it was cheaper, and the
> plaintif modified said code and our so modified device cut off her feet"
> can very easily be answered by "Then it was reckless design to leave it
> open to modification"

But was the reckless design to use GPLv3 or DRM instead of ROM? If you have this kind of liability hanging over your head, you can certainly afford ROM, or protected hardware jumper, or whatever

Busy busy busybox

vonbrand — Sat, 07 Oct 2006 04:50:27 +0000

If the Linux kernel developers are right on these technical issues and all these hippy 'GNU/OpenSolaris' users will find that Linux-based systems will far outstrip them in capabilities, usability, and performance. The Linux devs are then heralded as technical wondermen that they are and will garner a lot more support.

No need. Linux had outstripped Solaris by Linux 2.2 or thereabouts. I know, we ran boxen with Solaris (they crawled along), and migrating over to Red Hat got them to fly.

FSF is creating a problem that never existed!

mikov — Sat, 07 Oct 2006 02:53:36 +0000

I have to say that while until now I was hesitant on the GPLv3 issue, after reading your excellent posts on LWN, you have managed to convince at least one person -> me.

It is obvious to me now that even if hypothetically the world would be a better placee with GPLv3's additional restrictions, the FSF has no right to introduce them, because those restrictions are not what many developers agreed to when they were accepting the GPLv2 license. Even if those developers were foolish for not considering and fully understanding what they were accepting, the FSF has no moral right to take advantage of that.

Practically speaking, even if the GPLv3 really IS universally better (obviously many people think that it is), it should not automatically apply to GPLv2-licensed projects who happen to have the "or any later version" text.

All problems will be solved by renaming the GPLv3 to "NGPLv1" so that it isn't covered by the "later version" text. Projects are completely free to adopt it deliberately and knowingly.

Re: the beef

vonbrand — Sat, 07 Oct 2006 01:38:20 +0000

The intended end result is to make the device somewhat harder to modify as long as it does not cost too much. Shock! DRM is only about saving a few bucks! One could easily argue the costs of having to forgo DRM are largely couterbalanced by free access to the GPL software pool.

One could also easily argue that the costs of other software alternatives is not significantly higher, and moreover the GPLv3 (and possibly even more agressive GPLv4 to follow, and...) creates a high potential liability cost ("But, yerhonnor, we used GPLv3ed code because it was cheaper, and the plaintif modified said code and our so modified device cut off her feet" can very easily be answered by "Then it was reckless design to leave it open to modification").

Nothing forbids repairing devices in a GPLv3 world. It only forbids repair accesses closed to the device owner. That screwdrivers are widely available never stopped an appliance manufacturer from using standard screws, precisely because lowering lifecycle costs has priority over keeping the owner out at all costs.

You'd be surprised then by the strange screws I've had to deal with... plus swabs of paint over screws, etc. Point of most of them was clearly making it harder to get inside, or making modifications visually obvious to whoever is handling the device. What if the "handling" of the device is remotely, over a network?

Licence text and fabs

petetron — Fri, 06 Oct 2006 21:51:33 +0000

So how does this differ from the situation of old-fashioned ROMs that contain GPL-ed code? Do you get an EEPROM burner with every toaster that includes a ROM? Do you get free training to be able to use that burner? If the write pins of the ROM were burned out, but it's still easily replaceable by the manufacturer, do you get free ROM chips to replace them with? If the ROM is in a disposable cartridge that has some weird physical form factor, do you get free access to the cartridge manufacturing process, to be able to "modify" the ROM and produce new cartridges?

You are being obtuse. In the case of something like Tivo, the company can push new software updates to the device over the internet without the consent of the user. As another example, if a device is tied to a particular service, the company could compel the user to upgrade the firmware by making the service incompatible with older versions. In either case where GPL software is involved, the user should have the choice as to whether to accept the new version of the software, and if not, to still be able to use the hardware they BOUGHT and PAID FOR in the way they see fit (by patching the GPL'd code). That requires being able to change the source code.

If you distribute GPL software in ROM, you still need to distribute the source code. That's just as much the case with the GPLv2 now as it would be with GPLv3. However, unless the company sends men in black to your house to replace the ROM chip in the dead of night, with ROM there simply doesn't exist the same ability to force unwelcome upgrades on your device. That's a key difference and why your argument about EEPROM is absurd.

What this new language in the GPLv3 does is what the GPL never did and never purported to do: it limits the ability of end users to use GPL-ed code.

What are you talking about? In the most literal sense, requiring people redistribute source code is a limitation on their rights to keep their modifications to the code hidden. But it is through this mechanism that the essential goal of the GPL is asserted, which is that software which is placed under the GPL remains free to be used, modified and redistributed by anyone.

And as i said it before: there will always be freeloaders that only use our works and dont give back. /We cannot force them to give back/.

But we can force them to give it back, that is where copyright and contract law comes into play enforcing the text of the GPL. It is evident that you completely misunderstand the legal and social contracts that the GPL is built on. Perhaps you read the BSD license and are just confused?

Why would they care if you change the code?

sepreece — Fri, 06 Oct 2006 19:01:16 +0000

Most companies are willing to go to significant lengths to lower the probabilities. Juries do sometimes do things you would not expect. The cost of going to law are substantial, even if you win.

I can say that I know of design decisions taken specifically to avoid liability potential, over things with much less potential impact that replacing major parts of the operating software.

Why would they care if you change the code?

spitzak — Fri, 06 Oct 2006 17:37:51 +0000

That's nonsense. Caterpillar would win the case, as you modified their device without their authorization!

GPLv2 or, at your option, any later version

nim-nim — Fri, 06 Oct 2006 07:32:03 +0000

> > which will cause legislators to think,

> What planet are you on?

A planet were I do actually read reports of the parliament debates on subjects I'm interested in.

The GPLv3 may seems strange and surprising to some. For people who followed the DADVSI/EUCD debate in France (of which the FSF was one actor BTW) it's a very logical development.

Why would they care if you change the code?

svkelley — Thu, 05 Oct 2006 23:11:20 +0000

Well said. And when companies go elsewhere, Linux loses.

GPLv2 or, at your option, any later version

AJWM — Thu, 05 Oct 2006 20:24:46 +0000

> which will cause legislators to think,

What planet are you on? Sounds nice, legislators that might actually think, even if it does take some force.

If (hypothetically) Tivo were to die because a GPLv3 Linux was no longer allowed on it, that would NOT be seen as "a clear victim of DRM laws", but as "a victim of the capriciousness of those leftist hippies in the free software community", and held up as a cautionary tale against using GPL'd software.

Re: the beef

AJWM — Thu, 05 Oct 2006 19:48:51 +0000

> If you want to maximize the number of users and contributors to your code, use BSD.

Okay, I'll bite. How does the BSD maximize contributers?

Licence text and fabs

espeer — Thu, 05 Oct 2006 18:44:22 +0000

stevenj wrote:

> The only problem comes if the manufacturer wants the ability to modify
> the software while denying this ability to users.

No, by not providing keys, hashes or whatever, the manufacturer is not
denying the user's ability to modify the software at all. The GPLv2
guarantees access to the source - so you can modify it all you want. You
may not be able to run your modified version on that particular
manufacturer's hardware, but you are most welcome to develop your own
hardware to run it on (or run in on a suitable open hardware platform).

The question here is, should we be dictating requirements on the openness
of hardware in GPLv3?

Licence text and fabs

nim-nim — Thu, 05 Oct 2006 15:22:39 +0000

The answer is simple :

1. hardware maker uses GPLvx code -> he's now bound by the license requirement

2. here comes content provider, asking something incompatible with the hardware maker licensing obligations :
A. hardware maker can refuse
B. hardware maker can accept to breach his legal obligations, and be sued
C. hardware maker can accept, replacing the GPLed code with something compatible with the content provider demands. He won't be sued. If he's smart, he'll make the content provider pay for the change

No judge will defend someone promising to do foo to A and not-foo to B.

Licence text and fabs

mingo — Thu, 05 Oct 2006 14:25:15 +0000

As the GPLv2 enforcements efforts have shown, a judge will tend to consider someone availing himself of some provisions of a licence (free code access) has no legs to stand on contesting the obligations part later (as long as the obligations are clearly expressed).

Oh, the GPLv2 enforcements so far were mostly about clear-cut violations like "not giving out the source code", or trying to hide the origin of the code and copyright ownership by modifying binaries.

I believe you are over-simplifying the picture. A more realistic case would be like this:

- hardware maker fully living up to all provisions of the GPL. Source code made available on their website, etc.

- separate content provider (provider of expensive GPS maps, movies, pay-per-view events, etc.) insists on copy protection of their content.

- hardware maker use of DRM to restrict the extraction of that content from the hardware, by only allowing trusted installs approved by the hardware maker.

GPLv3 copyright owner sues. The judge will weigh: on the one side, the legitimate interests of the content owner, and the trade secret of the hardware maker, and the contractual obligation of the hardware maker to not make the content copiable, against the interest of the GPL owner, who gets his modified source code. The hardware maker even contributed back to the copyright owner's project.

But besides the source code (which was the main object of trade in a previous version of the same license, which was "similar in spirit"), the GPL work owner now also insists on a new-found and pretty far-fetched "right to tweak the hardware".

The hardware does not look all that tweakable to the judge, it's a sealed pink plastic cube. The copyright holder insists on the defendant either ceasing distribution (which likely bankrups the defendant) or requires the giveout of the trade-secret crypto key (which likely bankrupts the defendant too, because he was contractually obligated to the content owner to protect stuff and to not give out the key).

Furthermore, the judge will look who the people with this "right to tweak the hardware" are. They describe themselves as certain "hackers", and they want to "hack on the hardware". To do good stuff, amongst them, as the defendant will point out, "to enable pay-per-view piracy".

On the other hand, the judge will weigh the "harm" that the denial of this request for keys causes the copyright owner, but that harm seems rather remote: the copyright owner has only a personal interest in modifying the hardware. Out of curiosity. No matter how difficult technically. And he could run the manufacturer's code on his home PC. No, of course he does not want to watch pirated content.

Do you think the decision is so clear-cut against the defendant, especially if the defendant insists on a jury trial?

WOW! Community soap opera - and then some!

wookey — Thu, 05 Oct 2006 14:15:56 +0000

I make a living from embedded device/software development too, but I'm afraid I can't agree with your or Sombrio's characterisation of the situation. Once I understood the difference I found that I was a 'Free Software' person and not an 'Open Source' person. So there are embedded developers on both side of this argument.

I don't believe the entire embedded industry will stop using Linux even if it can't 'tivoise'. Hackability (aka user feedback, improvements and involvement) is a benefit as well as a potential cost. We live in interesting times, certainly, but calling the FSF names as Sombiro does above and claiming that they are looney zealots and he is the mainstream is certainly simplistic, and probably wrong. There probably _are_ now more 'Open Source' developers than 'Free Software' ones - but it is not a static division, indeed most of the time it is not a division at all. I suppose if GPLv3 retains the anti-DRM clauses then perhaps it will become clearer just how the numbers stack up.

And saying that DRM has 'nothing to do with Digital Restrictions Management' is just bollocks. It _is_ enforcement of restrictions. That's how it's implemented, that's how it works. I'm reasonably confident that it will lose out to free/open content in the long term, but it's going to be an ugly fight. I agree that manufacturers have the right to make DRM-enabled devices, but I don't agree that they can use GPLed code in such a way that end users lose the freedom to modify that code. I'm happy if GPLv3 makes that clearer.

Who is doing harm here?

wookey — Thu, 05 Oct 2006 12:58:30 +0000

Indeed. I would like to commend Ingo and stevenj for their contributions to this thread, which have clarified a number of things for me at least. The whole thing has been pretty civil as these things go. I do now at least understand a bit of why the kernel devs are so grumpy.

But I do not find myself convinced by their arguments, and agree with stevenj that the fears of forking, 'legal strongarming', and 'acting with legal but not moral authority' are overblown.

Nevertheless, Jon Corbet put it well (as ever) in the original article. This debate _is_ causing strife, and there is thus quite a lot to be said for a v3 that only has the uncontentious stuff in it. That would be a pity - the FSF are the ones who are being consistent and 'in the spirit of', and the kernel devs who are being awkward (IMHO), but it is quite finely balanced as to which course would be better in the long term.

We certainly won't be able to say that the issues have not been discussed fully at the end of it all, whatever happens - and that of course, is a good thing - tiresome as it might seem right now.

So, to re-iterate. Thank you for those making an effort to dicuss the substnative issues (which is nearly everyone here). It is appreciated.

Licence text and fabs

nim-nim — Thu, 05 Oct 2006 11:33:02 +0000

> How do you know that it's "defendant laughed out of court" instead of "GPLv3
> plaintiff's copyrights being judged unenforceable, due to misuse of
> copyright"?

Nobody forces anyone to use copyrighted/trade secrets/trademarks as DRM keys.
Nobody forces anyone to use GPLv3 software.

Licence text and fabs

nim-nim — Thu, 05 Oct 2006 11:19:50 +0000

> And you are still missing the larger point as well. This portion of the
> GPLv3 is a seemingly small but dramatic departure from the spirit of the
> GPLv2,

To be honest, I didn't feel I needed this portion of your argument needed to be rebuted, as better people than me (Alan Cox for example) already stated they didn't feel it was the case.

I happen to agree with them.

Licence text and fabs

nim-nim — Thu, 05 Oct 2006 11:16:48 +0000

> So where does the GPLv2+DRM combination create the "BSD on GPL code"
> situation in the Tivo case

Very easily, you only need to make DRMed PCs the cheap norm and open PCs the expensive exception.

for every-market-without-GPLv3-software ; do
{
// Get MS/Hollywood money and help
release (spec-mandating-DRM-on-next-hardware-gen);

// Making exceptions costs money and the majors don't like hairies
apply (DRM-on-GPLv2-software);

// Need some GPLv2 devs with access to DRMed hardware
// Or the FLOSS ecosystem will collapse brutaly, regulators notice
// and floss users not buy the new hardware generation
hire (some-gplv2-devs-to-do-life-support);

// This only takes a few years with modern lifecycles
wait (DRM-hardware-is-the-norm);

// This takes a tad longuer, as hairies will hoard previous gen hardware
// However without hardware access they're bound to disappear and find
// a cheaper hobby
wait (floss-hobbyists-have-disappeared);

// Without hobbyists there are less floss devs on the job market
// All the new software contributions come from competitors
// May as well make a consortium and work together
// Denying entry to new would-be competitors
replace (GPLv2-software,consortium-software);

note (floss-in-market-nonexistent);
}

This is the usual BSD pattern of hire key community people, stop contributing downstream, redeploy once the community is anemic

Licence text and fabs

nim-nim — Thu, 05 Oct 2006 10:51:14 +0000

> How would that happen in practice?

Very easily.

Mr V. goes to his local MP to make DRM mandatory and protected by law on all media processing boxes. The MP asks if it will hurt someone. Mr V says "of course not, it will only catch evil pirates".

Mr F can then come saying "But this will ban use of FLOSSTV, which is licensed under the GPLvx which is uncompatible with the proposal" competition and free market is good, you can't do that. This is a strong argument.

Right now M F can only say "But this will harm FLOSSTV, which is licensed under the GPLvx which intent/spirit is uncompatible with the proposal" competition and free market is good, you can't do that. This is a weak argument, spirit and intent count for zip.

In case you think I'm making all this up, I'm only repeating from memory some of the arguments used in the French Parliament when the EUCD directive was translated in local law this year.

Some of the articles proposed by the majors were clearly uncompatible with existing Free Software license terms and could be amended. For others the uncompatibility was not so clear cut and unfortunately opposing them proved impossible.

The harm BTW was not only FLOSS-side. The law hurt numerous actors, but they all found out nothing but the most blatant problems (such as law/license uncompatibilities) had any weight against the majors' money.