For anyone looking for GPLv3 explanations:

Posted Sep 23, 2006 14:59 UTC (Sat) by ibukanov (subscriber, #3942)
In reply to: For anyone looking for GPLv3 explanations: by coriordan
Parent article: Kernel developers' position on GPLv3

> DRM - because the GPL was never meant to let Tivo insert unremovable spyware or to let them ban adding certain features from modified versions

But GPLv3 does not fix this. Tivo uses Linux because it is cost-effetive for them. Moreover, they can get away with unremovable spyware because their users want to buy boxes with spyware and do not care about their freedom.

With GPLv3 Tivo could either use ROM chips or proprietary OS. Yes, that would be more expensive for them, but if from a business point of view having spiware and GPLv3-Linux in ROM would be more profitable, then just GPLv3 Linux in re-writable memory, they would choose ROM.

Or consider another possibility. Tivo can provide you with GPL-v3 derived sources and all the build keys, but would not provide you with a compiler. That is, their build process may require to use a particular physical box where you suppose to type the key manually to unlock the the real key. GPLv3 does not cover this AFAICS.

So GPLv3 has very narrow view on technical measures that prevent boxes from hacking. That demonstrates IMHO that it does not fully grasp the realities of embedded world. Thus FSF should really wait with touching GPL until a better picture emerges or take a different approach.

to post comments

For anyone looking for GPLv3 explanations:

Posted Sep 23, 2006 17:22 UTC (Sat) by k8to (guest, #15413) [Link] (5 responses)

I think the point of the "anti DRM" clause is not to prevent
freedom-limiting technical measures from existing, or to prevent
freedom-limiting technical measures to be used in systems that include
GPLv3 code. It is simply to prevent freedom-limiting technical measures
to remove the freedoms intended in GPLv3 code.

Thus, in a TIVO, GPLv3 components should be modifiable and replacable,
is the goal. TIVO could simply implement their logic they do not intend
to be replaced in a non-GPLv3 body of code, and apply technical measures
to prevent this code from being changed, even if the box is running GPLv3
code in other portions.

I think your argument about the ROM question in the embedded environment
is a good one, and that the idea of waiting for further understanding is
a good suggestion. However, I do think that devices with non-updatable
firmware is going to approach 0% over time.

For anyone looking for GPLv3 explanations:

Posted Sep 23, 2006 19:20 UTC (Sat) by sepreece (guest, #19270) [Link] (4 responses)

Since the kernel presumably isn't going to change, this is all pretty academic, but...

Changing to ROM would (as I understand it) be cheaper than flash. It would be interesting to think about whether you could put the kernel in ROM but provide a flash-based patch block for any needed updates. Lots of systems used to work that way. Not sure what the license impact would be, but it would probably be doable.

The problem with the idea of locking down the app code and leaving the kernel replaceable is that the kernel is privileged, making it hard to control what it could do to the rest of the system. It would probably be necessary to move some current kernel functionality (some of the device drivers) out of the kernel, to protect data paths from sniffing. Should be doable.

There are lots of interesting questions left around the current GPLv3 language. It talks to making keys available, but, of course, keys are not the only way you could assure that the software in the device is the software you put there...

For anyone looking for GPLv3 explanations:

Posted Sep 23, 2006 19:48 UTC (Sat) by Tester (guest, #40675) [Link] (3 responses)

The license would still apply, because the code in the Flash would still most likely be derivative from the GPL code and you'd have to provide the key for the flash. The only reason to do that was that flash was much much more expensive than rom.

For anyone looking for GPLv3 explanations:

Posted Sep 24, 2006 1:56 UTC (Sun) by sepreece (guest, #19270) [Link] (2 responses)

First off, whether the code was derivative of the GPLed work would depend on the particular patch and, possibly, on the way the patch facility was implemented.

As to the viability of ROM vs flash, for some kinds of device (like music players) ROM might be just fine. It's unlikely a manufacturer would want to reflash them in the field. For a phone or a DVR, however, I agree that some kind of update capability is probably a necessity.

For anyone looking for GPLv3 explanations:

Posted Sep 24, 2006 23:10 UTC (Sun) by k8to (guest, #15413) [Link] (1 responses)

For the record, music players do regularly flash-upgrade the firmware.

One of the reasons flash was created was because to be able to create
high density programmable rom, which is not achivable via other methods
with the levels of density flash has achieved. It maybe possible to
create traditional roms with the density required, but there are massive
logistical problems that go along with non-programmable ROM in terms of
wasted parts, large runs being required, the cost of bugs, and so on.

I believe that the day of non-programmable rom has passed, and that this
is why free software ethics are now being applied to firmware, because
there is no longer the unchangeability issue that made the argument moot.

For anyone looking for GPLv3 explanations:

Posted Sep 25, 2006 15:08 UTC (Mon) by sepreece (guest, #19270) [Link]

You're right about music players - I forgot the various times I have updated my iPod's software. I do htink there are some devices small and narrowly purposed enough to be ROM-suitable, but I agree that mainstream music players were a poor example.

GPLv3 not going far enough?

Posted Sep 24, 2006 2:14 UTC (Sun) by coriordan (guest, #7544) [Link] (3 responses)

You are right that there will still be ways in which the freedom of GPL'd software users can be restricted. GPLv3 could go further, but each condition has to be considered in terms of how much inconvenience it adds and how effective it will be.

The clauses that are in draft 2 of GPLv3 are judged to be the minimum required in order to prevent large scale abuse of GPL'd software. They are fairly minimal and are focused on protecting developers and distributors and on reducing bureaucratic incompatibilities, and look at the number of complaints?

Stallman probably wants more freedom protecting clauses to be added, but the GPL has to be a licence that people want to use. (At the same time, the goal of protecting share-and-share-alike will not be compromised for popularity, even if Linux developers ask for it.)

GPLv3 not going far enough?

Posted Sep 24, 2006 2:44 UTC (Sun) by ibukanov (subscriber, #3942) [Link] (2 responses)

> The clauses that are in draft 2 of GPLv3 are judged to be the minimum required in order to prevent large scale abuse of GPL'd software.

My problem with the clause is that it would not prevent anything in the embedded world. I.e. it is possible to defeat it completely AFAICS with simple tricks that would not add any cost to the hardware. As such the clause is dangerous as it give people an illusion of anti-DRM provisions for their free software while adding extra legal complexity for already non-trivial text with unclear consequences.

Here is one detailed possibility of abusing GPLv3. A company can make a device that can run either a signed or unsigned kernel. For unsigned kernel the device would require to enter a private key, which it would then use to sign the kernel and make the kernel available for access so it can be extracted and distributed if necessary. Now the trick is that to enter the key, you would have to use an extra hardware that the company would not sell. So you would get the source, the complete build system and all the encryption keys, but still you would not be able to change the software.

theory and practice

Posted Sep 24, 2006 3:15 UTC (Sun) by coriordan (guest, #7544) [Link] (1 responses)

The problem tackled by GPLv3 is worth tackling because someone is already doing it (Tivo). Other cases might be being ignored either because they are not yet being exploited by anyone, or because no one has suggested a good way to prevent them.

Hopefully, no company will find a commercially viable way to do what you've suggested is possible. If it becomes a problem, hopefully someone will suggest a way to fix it in the licence.

It might happen that something cannot be addressed by the licence. In the future, we might have to lobby our legislators or the hardware manufacturers. But, for whatever problems can be solved or reduced by the licence, we should figure them out the solutions this year.

theory and practice

Posted Sep 27, 2006 9:36 UTC (Wed) by RayCromwell (guest, #40771) [Link]

I'm not sure if the loopholes could be closed. Consider for example, a device which uses virtualization to run a GPLv3 kernel. The user can replace it all they want, but it will be run inside of a protected domain without full access to the underlying hardware. So no one stops you from hacks, but they do stop you from accessing 100% of your hardware.

This is probably going to be the way the Playstation 3 runs Linux for example, so that homebrew software can be written unsigned by Sony, or signed by Sony for a small fee, and the kernel may be freely upgraded and replaced, but total access to the full power of the PS3 hardware will be blocked, especially BluRay Video access, access to all of CELL and RSX hardware features.

I'm also not sure as a user, but hacker, I would even wish Sony be forced to completely open the device, since Sony is heavily subsidizing an $800-1000 device which is nearly bankrupting them for me to play games on, and selling it for $400-500. The benefits of full access for me, as well as a vast library of high-definition movies, probably outweigh the costs of not having it hackable at all.

What if Tivo "tivo-ized" their boxes with virtualization by allowing you to upload and run whatever kernel you want, except that the components of the system which capture video systems and store them to disk, as well as dump them into the framebuffer of the display chip, were run outside the Linux kernel in a trusted module. The kernel and user applications could view information about the show database, channel guide, and could control media functions like play, rewind, fastforward, but all aspects of video decoding were delegated to special proprietary chips and protected code running in another domain?

Seems to me that there are routes for DRM devices to take where they can leverage GPL software while still locking down the media content on the device so that it cannot be circumvented by modifications to the kernel and userspace programs. As an extreme example, for a video player, they can simply stick a sufficiently powerful co-processor/media decoder chip that runs a mini-OS that does nothing but decrypt and decompress media streams. This will increase the cost of the HW, but their business model may include subsidizing hardware anyway.

This would not satisfy those clamoring for user freedom because your usage of content you purchased would still be managed on lease/rent/copy restricted rights management.

-Ray Cromwell

p.s. one other comment, is there are a number of people acting like licenses with non-viral clauses aren't successful because people make private changes and don't give back. But I use a large amount of code licensed under Apache, and I would argue strenuously with anyone who claims the Apache projects are failures or that corporate interests aren't giving back code. Perhaps it is possible to have freedom and benefits of open source without force, as long as there is a critical mass of fair minded people willing to work. The "Prisonner's Dilemma" keeps getting brought up, but this is really the "Volunteer's Dilemma". Much of our civil society rests on the fact that an astonishingly high number of people are honest and fair. Yes, there are plenty of leeches in the system, we here about abuses of government services and charity all the time, but IMHO, true freedom is also the ability to tolerate some level of failure, that some people will cheat, and some projects will fail.

Ironically, GPLv3 (and to a lesser extent, GPL overall) seems like "DRM for developers and device manufacturers". Content producers don't want to tolerate that a small percentage of people will be software pirates and take without paying authors, and it seems the GPL doesn't want to take the chance that a small number of people will be code leeches.

For anyone looking for GPLv3 explanations:

Posted Sep 24, 2006 9:26 UTC (Sun) by petegn (guest, #847) [Link] (1 responses)

I am not a developer apart from a minor hack of the floppy driver for my perticular Mother board (an old 386 baseed bord some years ago) but it strikes me this whole thing needs looking at in a slightly different direction

The question of the Tivo'ised software quite simple in reality

You choose to use open sourced software in your device (the maker this is to ) therefore you are not allowed to encode , encrypt or other such methods ANY part of the code or systems used no keys to do this that or other .

As for DRM well if enough people could be bothered to act on the problem it would be dealt with in short order but too many people are of the "SHEEP" breed and blindly follow ,If the "SHEEP" would remove the BLINKERS the the content providers would soon be wetting there collective nappies because there would be NO income for them because no one would be buying ther vcrap to start with .

but alas we live in a world dominated by "SHEEP" and "SHEEP SH*****S" that contine to milk said "SHEEP"

For anyone looking for GPLv3 explanations:

Posted Sep 25, 2006 16:01 UTC (Mon) by sepreece (guest, #19270) [Link]

Most users are just that - users. They don't particularly care about using content in ways that the DRM systems prevent (though some of the proposed next-gen systems will probably irritate more of them). But, by all means, educate the users and try to get them to push back on the content providers.

The trade off you are asking for (if you use free software, you cannot keep people from modifying it in the device) is not generally agreed to be part of GPLv2 (though some people do believe it was in the spirit or intention of v2, many others do not). The kernel developers' letter expressed their opinion that it should not be part of the mainstream GPL in the future, either.

So, the choice you posit in your third paragraph is not a fact, it is a question to be resolved in the debate over GPLv3...