Re:I would LOVE signed kernel support in bios!!!
on
Linus on DRM
·
· Score: 1
Imagine being able to tell your bios not to load a kernel (actually, boot loader is probably more accurate), unless it was signed by you. Then you've just guaranteed that even after a system break-in, you can at least start from a known clean kernel.
A system break-in would quite likely mean that the key you sign with was compromised.
If you want to start from "known clean kernels", then make a bootable CDR.
Re:Why signed binaries are not allowed by the GPL
on
Linus on DRM
·
· Score: 1
Criteria 1: What is the purpose and character of the use? The purpose of a hash is completely different from the purpose of a kernel.
In this case, they both have an identical purpose: "To make Linux run on the particular hardware". The end-user installing patches on his system has no way to tell which file is the kernel and which the hash (except by guessing from names or sizes). The externally visible behavior is the same- when both files are installed, Linux runs.
Criteria 4: What effect does the use have on the market for the original work?
The hash enables a new variant of DRM-enabled Linux to enter the market, becoming competition with traditional open-hardware Linux, and reduces it's sales. (This would be strengthened if the Linux variant the DRM vendor copied from had been written by an existing competitor in a market, whom had neglected to invest in DRM hardware)
Criteria 3, of course, overrides anything else. Even though it might really be as much as 256 bytes, the hash still cannot be considered a copyright infringment on Linux such that the GPL would apply to it.
Re:DirectTivo already does this.
on
Linus on DRM
·
· Score: 1
Probably he means not that you can get the hardware for free, but that you might be able to make the hardware useful without spending $20 per month on the service subscription.
Really, all the "service" provides beyond occasional feature-removing software patches is a digital list of each day's television broadcast schedule. (Which the machine uses to pick out what channels to record and when)
TVGuide.com would happily provide the same quality of data for a much lower fee, and a few Perl scripts could reformat it into whatever shape the set-top unit needs.
Thus, the hardware manufacturer is motivated to prevent users from tweaking software.
You're joking, but that's not actually a bad idea.
Open Source DRM would have the weakness that any user with a little programming skill can work around the copy protection.
However, if society was a little less focused on corporate profit, that kind of easily breakable protection would be good enough.
An Open Source DRM system might look like this: authorship, licensing, and payment metadata can be attached to any media file. When users play the song, their software logs that fact and presents a button (maybe immediately after playing, or maybe accumulated once per week) which can be pressed to deposit $0.10 - $0.75 into an account with the musician.
If the price is cheap enough (well under a long-distance phone call), then people could pay willingly, relying on self-conciousness and peer-pressure to enforce a modicum of compliance. Call it a shareware model, with added software to expedite payment (no one's willing to mail a cheque for $0.50, but an easy digital payment might be a fun way to support your favorite artist)
Fraud prevention is a concern, but I can think of a few good ways to prevent spoofing a musician.
Re:No, you missed the point...
on
Linus on DRM
·
· Score: 1
The stock reply is that
"copying media has been expensive and slow for 1000's of years... advancement of technology made it cheap and quick, meaning it needs to be encrypted"
(That reply, however, is an example of reasoning that is simple, elegant, and wrong)
Re:I think Linus Missed the Point....
on
Linus on DRM
·
· Score: 1
Nowhere in this message does Linus even begin to talk about RIAA-driven media protection schemes. Why are you even bringing it up in this post? "Digital copyright protection" IS NOT the be-all and end-all of DRM.
No, but it is the most important component of DRM. Digital=digital, rights=copyrights, and management=protection. Prehaps Linus didn't include it in the message, because he felt everyone already knew.
The reason that some people want to sign custom kernels is so that programmers, paid by the RIAA, can produce kernels which will refuse to copy files that have the DRM flag turned on. This way, they can sell devices that compete with TiVo, but forbid the buyer from doing certain activities. And the fact that the kernel's signature is checked by the hardware means that users can't go back and modify the kernel to be more cooperative, even though the GPL has entitled them to a copy of the source.
Linus's posting was his acknowledgement that he will not try to prevent those kinds of DRM features from being added to variants of Linux.
Re:DRM's not really about Linux, anyhow...
on
Linus on DRM
·
· Score: 1
It is aimed at Linux in 2 ways:
1) The RIAA and MPAA fear Linux as a gateway through which their DRM-protected files can escape. DRM may stop two Windows users from trading songs, but any single system which can ignore DRM can encode an audio CD as non-protected traditional MP3s and upload them to Kazaa. From there, the horse is out of the barn.
2) Microsoft fears Linux as a competitor. They plan to collaborate with the music and movie industry to persuade consumers that DRM is in their best interests. "Get the DRM Windows OS running on DRM Intel chips, and you can buy all these great movies at 60% off the DVD price" The fact that those DRM Intel chips would completely refuse to execute any non-DRM OS (such as all existing forms of Linux) won't be mentioned in the advertising.
Digital rights management is just that -- digital rights management.
For rhetorical purposes, I would prefer to call it "digital rights reduction". (Or "restriction", or "removal") That will emphasize the fact that the neutral word "management" actually means "taking away functionality". It'll help people understand that DRM hardware is meant to work against the wishes of it's owner.
Heck, if the box was networked, it could just download the public key from a key server somewhere, or even grab it from a web server, because they're public!
If the X-Box expects to get the public key from the network, that opens a security hole where someone can spoof the trusted remote system. Hacker creates a new binary, signs it with his own private key, then tricks the box into thinking his public key is actually Microsoft's.
Keeping the public key in hardware is much safer, because it raises the bar for altering software the X-Box accepts. Replacing hardware is more difficult than running a little spoof-server on your PC, and a faster way to get arrested too.
(If the communication between the X-Box and the keyserver were encrypted, then that's just another key stored on X-Box hardware)
Re:Some people seem to miss the point.
on
Linus on DRM
·
· Score: 1
My hope is that variations on this scenario will occur so frequently that there will be a thriving, legal market in non-DRM machines.
For a more pessimistic view, assume that as long as the non-DRM machines are on the market, makers of DRM hardware will have legions of support personnel ready to accept source code and send back signed binaries on an hour's notice. Doing this quickly is possible, as long as they err on the side of accidently permitting DRM violations to occur, rather than accidently breaking operation. (The MPAA might not like it when something insecure signed programs slip through, but if they're smart they'll shut up and wait it out)
Or the manufacturers can use other means, but they'll work very hard to ensure driver-snafus like yours never last long enough to bother many customers.
During that time, there's no visible advantage to non-DRM, but DRM-enabled boxes will have more uses (watch movies to relax after work, etc. Maybe even work-related uses: online access to copy-controlled technical documentation)
Only after the non-DRM vendors have been driven from the marketplace will the makers of DRM systems (and their taskmasters at the RIAA and MPAA) feel ready to clamp down and show how firm DRM control can really be.
That might show that there really was a market for non-DRM hardware after all- but once you've stopped production, the rapid SOTA in the computer industry means the barrier to re-entry is nearly insurmountable.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
It's interesting to consider what would happen if Linux used GPL section 2c ("If the software is interactive, it must print a message on startup instructing the user that he is allowed to make copies")
Apparently Linux doesn't print such a message, though.
But, the University can simply forbid students from dumping a boot-image to CD, if the computer in question belongs to the university and isn't distributed to the student.
Do you know if they actually bothered to issue such an edict?
Ignoring the issue of why a University would ever want to keep kernel changes secret, and heading towards different but related terrain, are we sure the person who modified the software is allowed to make that forbiddance?
3 situations:
In the case of this University, it may naturally seem they can. (It's their hardware, after all) The students signed an agreement that they wouldn't perform certain actions before getting allowed into the lab.
If a portable music player included GPL software, could the vendor forbid customers from downloading it off the ROM? This time the user owns the hardware, but maybe he was required to sign a contract agreeing to no downloads before sale.
If I send you a modified GPL program and don't want you to redistribute it, can I first require you to sign a contract promising to never copy it, regardless that the GPL license says you may?
The last case cannot possibly work, because if it did, such a giant loophole would eliminate all GPL protections. And the second case is very similar.
They are both clear violations of GPL section 6, "may not impose any further restriction on the recipient"
If the agreement to use the school computer lab might count as such a restriction is not so clear. (And I won't even get into the question of if the individual part-time employee who installed those boot images is allowed to take copies home with him)
Re:Will DRM even work in Linux?
on
Linus on DRM
·
· Score: 1
(I suspect that more people would've read and responded if that post had been, oh, 20% of it's length)
Unfortunately, DRM in hardware means buying all new sound cards (and video cards, etc).
By a "hardware model", are you proposing that key validation and decryption is done on the output hardware (videocard), rather than the computer software being allowed to view the content in the clear? (That is, encrypted file is loaded from the DVD-ROM, copied to memory as an unintelligble bag of bits, and pushed to the videocard which decrypts and sends down the VGA port)
That removed many of the advantages computer software can provide, or at least make software (and hardware) developer's lives much more difficult. Because no software can see the data in the clear, it has absolutely no chance to perform any kind of useful transformation on the data. In ordinary use, many transformations are absolutely required- which means that the videocard will need to have an interface built so it can be instructed to perform those commands.
Individually, none of those features is very hard They include repositioning, flipping, rotation, gamma correction, clipping, scaling, and the like. (Audio files would need their own set of effects) But put them all together, and the complexity of interacting with a videocard has increased substantially.
(The MacOSX feature of genielike warping a running video down into a dock icon will be completely out of there)
True, existing videocards already do most of those things in the form of accelerator functions... but those are a concern for the driver author at the hardware vendor.
As a GUI author, I'm scared to think of what these further restrictions could bring to my code- it's an enforced layer of extra redirection. Imagine writing a 3d videogame whose visual and audio resources are protected by DRM (they'll at least want to do this for the soundtrack).
As time passes, and more and more data transformations need to be performed on the trusted output device, we could reach the point (reminiscent of NVidia's Cg) where the output card has a CPU to run arbitrary programs that can manipulate the data in the clear, but have no ability to send messages back to the main OS. As a computer user, it pains me to think of sitting in front of so much processing power, and not being able to use it for running arbitrary programs.
I won't bore you with endless details of each little obstacle, so here's my upshot: The "hardware solution" would entail substantial changes to many core aspects of personal computer design. Those changes will be difficult and expensive, and are dependent on cooperation of vendors of many kinds of hardware.
Microsoft's planned DRM model, on the other hand, will use a small amount of trusted hardware to verify that all executing software is likewise trusted, and then let the software handle protected data in the same way it processes anything else. Microsoft will have big advantages in pushing this scheme forward:
A) It relies on cooperation from fewer manufacturers. B) The majority of software will need fewer changes in how it runs. C) That "trusted hardware" will made it even more difficult to install Open Source software, further marginalizing Linux and protecting MS desktop market share. (This strong financial motive can translate into willing investment from their cash reserves, pushing this plan forward)
Re:Some people seem to miss the point.
on
Linus on DRM
·
· Score: 1
Alot of hardware is made in China and Japan, most likely they don't share the same ideals as the RIAA
Japan does. So does Taiwan. Their music industries share the same goals and concerns as the US one.
Mainland China does not, yet. But the US Army has displayed a strong inclination to forcibly export their legal viewpoints around the world. (Although more likely, they'd use a gentler application of force to destroy the rouge hardware before it reaches customers in the US)
The RIAA is alone in it's battle,
They have many friends, and not just billions of dead Presidents. The bulk of the uninformed music consumers of the country are generally happy with the job the RIAA is doing, and see no reason to oppose it.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
The GPL is used in lots of places where the binaries are not distributed (eg. my university installs its own kernels on its own machines, but doesn't distribute them elsewhere).
In that situation, "distribution" has occured, in both the legal and English language definitions of the word.
The university had one copy of the kernel. They made many copies, and carried them to various computers around campus. That is undeniably "distribution" in the simplest sense- the material has been spread out.
It might not seem that way by common business usage- some people may think that if all recipients belong to the college, it hasn't gone far enough to really matter.
But the GPL lives in the realm of copyright law. Whenever someone wishes to perform an act which would violate copyright, she must first agree to the GPL, and place the products of that act under GPL. To take a legally acquired piece of software and make copies to run on second and third computers is a copyright violation. (The University obviously cannot argue that installing a single $299 Microsoft Windows disc on 35 computers is not an infringment)
In the case of this University, then by GPL section 2b, they must license it at no charge to any third parties. If a student using the computer dumps a boot-image to CD, and then wants a copy of the modified source, he is entitled to it for the nominal fee for shipping and handling.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
it should be pretty easy to make a legal argument
It might be possible, but it won't be easy. The question is sufficiently vague that the skills and endurance of the opposing legal teams will really come into play (biasing the results in favor of whichever wealthy corp pays the fattest retainers)
A few points they could contend follow:
Several videogames (Quake, etc) have been released under the GPL. That only covers the source code, though. Additional copyrighted materials (graphic and audio files) are needed to make it actually run. Yet one has objected to that practice. GPL programs are often dependent on an external resource that is non-GPL.
Of course, that situations and the kernel-signing one are non-identical. A person can produce a modified game binary that will run with the officially supplied graphics. But a modified kernel binary won't work with the officially supplied key.
A separate argument your side might but forth is that all software engineers employed by the hardware vendor have the ability to sign and run code as they perform their daily work. That key-generator is truely a preferred tool for making modifications.
But, is it part of the source code? It's not derived from any GPL work, for example (it's just a certain random number they've picked as a private key). Many publishers of GPL software have things which they prefer to use, but aren't obligated to distribute. (Internal technical documentation, commercial compilers, etc. In fact, part of Red Hat's business model is charging extra for those documents.)
Re:Torvalds muddying discussion with PERSONAL stuf
on
Linus on DRM
·
· Score: 1
The decision to not "impose your moral values" is in itself an imposition of your moral values on me. Everything we do and don't do has an effect on everyone around us.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
3) Our IT guys build a kernel that's tweaked for our company. They sign the kernel, and set the BIOS to only boot kernels with their signature.
Seems like a rather pointless example.
The IT guys should be the only people with root password access- they're the only ones able to install kernels on hard drives.
Likewise, they should be the people with BIOS passwords, which, in a controlled corporate setting, are already needed to allow a machine to boot once a case-opening has been detected (such as replacing the hard-drive).
The only purpose a signed kernel serves in that situation is to make it easier for the the IT department to enforce compliance among it's own staff. Someone who's not trusted to build kernels can still use root passwords and install them, since it's signed.
However, if you don't trust someone to sign, should you really trust him with root? (Certainly not in a modern Linux workstation environment)
This, I think, actually violates the GPL. They're distributing a Linux binary, and they're not giving you any way at all to modify it.
It does violate the intent of the GPL, but it's hard to see how the letter of the agreement is being disobeyed.
The vendor supplies you with hardware, software, and the source code to that software. You can read, modify, redistribute, and recompile that source code.
But you have no legal guarrantee that after you modify the source code, it will run on any hardware you have.
not given the "source code" you need to compile that part of the binary.
You might be. Depending on how the signatures are implemented and stored, compiling the vendor-supplied sourcecode without editing it at all might produce something that'll run and work. Change one tiny thing, of course, and it's "System corruption detected. Consult your warranty for support options"
The fixed signature ends up being an important part of the running binary,
This is the crux of the matter. If you can prove in court that the signature is a part of the program, then your argument for a GPL violation is OK.
But I don't see how the key can be considered part of the program under the definitions of the GPL. At least, I doubt it's a GPL-protected work. The GPL functions based on copyright. The core of the GPL is that "It's illegal to distribute modified versions of a copyrighted work without permission. But declare your modified version to be GPL also, and you've got permission."
Thus, GPL-protected materials are things either A) willingly declared as such by their original creator or B) based on a modification of something that's already GPL.
Since the creator of the signature (hardware vendor) doesn't want it to be GPL, it certainly won't meet point A. Does it meet point B? Only if producing a signature of a file is enough to violate the copyright on that file. It would be hard to claim that a 2048 bit signature of a 4 megabyte kernel is an infringing copy. We shall see in time.
but you can allow the end user to run a quick command to insert the keys into the binary him/herself.
Why even bother? If you ship the key separately from the binary, then just let the kernel load it from a known filename on bootup. Makes no difference.
However, if the key is shipped in a different file from the kernel (regardless of whether that file is meant to be patched onto the kernel, or just read), the key has been "made public". In one sense.
It's public in that many, many people can easily find and read the key, without having to disassemble the kernel binary and search for the exact instruction that checks the key.
It's not public in that those people aren't allowed to do some things with the key. If it were in the kernel source code, they've have a right to duplicate and redistribute it.
Yeah, but then the modified binary would fail the signature check; you've just suggested nothing.
His suggestion would work, at least for that part. However, the whole idea is fairly meaningless- it makes no difference if the key is distributed inside the binary or alongside it, except that the former case will often be a GPL violation.
He suggests a loophole to work around that violation. The signature would've been computed against the modified binary, not the one output by the C compiler.
It would be mathematically tricky (or close to impossible?) to compute a signature that accept a binary containing that same signature (since the signature wasn't known back when the signature was being computed, it's hard to keep the signature in the signed part of the binary). Easier is to just declare that the final 2048 bits of binary (the part containing the signature) is not to be checked for signing.
In that case, though, you're essentially transmitting the binary and signature in separate files (like how MD5 sums are done today), and just coincidentally storing them adjacently them upon reciept.
Either way lets hardware-manufacturing corporations (and their software-developing partners) further take power away from end users and amateur programmers.
Re:Some people seem to miss the point.
on
Linus on DRM
·
· Score: 1
Sure I understand the keys are not there, but if you have the program that does the encoding, you can understand the algorithms used can't you?
You don't necessarily have that. Yes, you get the source to the Linux kernel, but maybe it calls some modules or other programs which are opaque to you.
If you had the ability to edit the source code and run a modified kernel, you could change how it interacts with those modules to learn more about them (or simply subvert them). A lot of power has been removed from the end-user if that is impossible.
Of course, a person could grab the external modules and disassemble the binary code- but you can do this regardless of having the kernel source (it speeds the work if you know better where to look, but that's not a fundamental change)
You're giving them the keyhole, they can study it and make their own key.
To do that, they'd have to build custom hardware. If you're a giant corporation, you can build it from parts and just claim "I'm going to compete with the previous hardware manufacturer in the free market". But if a small group of individuals wants to do this, they can't start from scratch. They must modify the hardware they bought to do the new functions. Something like that will get you arrested under the DMCA, for constructing circumvention devices.
For DRM to work (do its job of protecting revenue for the entertainment industry), it doesn't have to be foolproof. No DRM can ever withstand hardware tampering- even if the source is closed, someone can reverse engineer it (often, you don't need to understand much of the code- just locate a few conditionals that can be changed to "always true"). Publishing the source code makes this step easier, but you've still got to build a modchip (something that many hackers know well how to do).
DRM is not primarily a technical defense, but a legal one. The technical aspect just has to ensure that only a tiny fraction of the population has the skill and motivation to break protection- few enough people so that jails can hold them.
Re:Some people seem to miss the point.
on
Linus on DRM
·
· Score: 2
You're missing some important cases. Yes, the OpenSource-ness of Linux makes several imaginable DRM scenarios less viable. But there are plenty of alternatives that can still work fine.
The most probable one in my opinion (and what Linus alluded to by "providing a signed kernel") is that computer hardware will be sold which looks for a particular key/checksum on the kernel before agreeing to load it up. (Similar to how the Microsoft X-Box works today)
That kernel can then go on to enforce DRM policies on software you run- either by directly blocking copy-commands, or by restricting the list of userspace applications that can be executed to an approved list. (It may very well let you run a non-approved application. But DRM-protected files will be inaccessible to those programs.)
Note that this scenario won't work if 3rd party hardware vendors are allowed to sell modchips to override which kernels the computer accepts. But laws like the DMCA make trafficing in such circumvention devices illegal.
Two (of many) potential dangers if personal computer technology goes down this path:
The GPL will be perverted, to a partial extent. Many people don't care about the GPL, so this won't bother them much (at least not initially). The perversion is that consumers will recieve source-code from hardware vendors that they can read, but can't usefully change. Sure, they can recompile it on an (increasingly rare) desktop workstation, but they can never execute their modifications on the hardware they bought. For practical purposes, it's as if they got the code under a Microsoft-like Shared Source license, instead of an Open Source one.
The "General Purpose" computer will fade away. So too might the concept of widespread software development. Computer programming will not be accessible to everyone, only those wealthy enough to build their own hardware. Everyone else will be legally barred. Open-Source development depends on re-purposing commodity hardware by writing your own software, but that could become illegal. A condition like this would take a while to fully take root- but the spread of hardware verifying signed kernels is a firm step in that direction.
Slashdot Mirror system
on
Linus on DRM
·
· Score: 3, Interesting
Will this be a permanent change, I wonder? And how did Michael get around those pesky US copyright laws? Did he actually wait for Linus's permission before duplicating his email?
You might want say how you're defining "intelligence" before you make a statement like that
The scientific definition of intelligence is "the ability to score highly on an intelligence test". It's beautifully circular, but the only fair way to discuss mental capacity across a variety of disciplines.
ignoring how modern people benefit from the vast base of existing knowledge on which to grow their own.
Of course it's ignoring it. "Base of knowledge" is not intelligence.
Your assertion is basically saying that evolution has not only stopped,
No, it says that the traits which evolution selects for aren't necessarily what you'd hope. Today, highly intelligent people are less reproductively successful.
However, for any meaningful interpretation, evolution hasn't changed humanity at all since the paleolithic days. They were less than 20,000 years ago- an "evolutionary eyeblink", as they say.
One would think that if it had some decent supporting evidence there would be lot more easily referenced material around to support it than a few "thick books".
That's an argument from popularity, there. Facts which are true but unpleasant and unhelpful will not naturally be easy to find. However, the particular volume I was mentioning has garnered enough Pultizers to ensure near-total availablity at your local library.
but I say that the Strawberry Shortcake material was the primary subject of the material
Gabe Newell disagrees with you on that point (he says so in the text he wrote to accompany the image). I'd expect the same from a judge or juror- upon learning the comic was written for a professional videogames website, they will agree that the primary subject was the one most pertinent to videogames (that is, a famous game designer, rather than a 15-year old pink doll)
Did he wake up in the morning and decide "I think I'll write about a toy I saw once in elementary school?" Of course not- he read an annoucement of "American McGee's Oz" and pondered "What other innocent, girlish fantasy-land could he plunder next?"
More accurately, the comic is making a statement how American McGee would (unintentionally) make a parody of Strawberry Shortcake if he were allowed to convert it to a videogame.
Exactly. That's the gripping hand. "making a statement how American McGee" tells us that the critical commentary is directed towards McGee primarily, not Strawberry Shortcake. You say they allude to a parody of SShortcake, suggesting that McGee would make one, but even if that's so, they aren't themselves parodying SShortcake.
I like it, but then I've been following Penny Arcade for years.
It's a good joke- somewhat esoteric, so a reader will feel satisfied if he understood it without hints. (and people who needed hints from the text to remember who AMG or SS were probably wouldn't get the joke even with help)
I agree that the material you are infringing should be the subject (or one of the subjects) of the parody
I don't agree with that, actually. Yes, that is the law. But I don't believe it should be.
I like it, but then I've been following Penny Arcade for years.
It's lasted better than Nickel Arcade, that's for sure.
Slashdot Mirror
Imagine being able to tell your bios not to load a kernel (actually, boot loader is probably more accurate), unless it was signed by you. Then you've just guaranteed that even after a system break-in, you can at least start from a known clean kernel.
A system break-in would quite likely mean that the key you sign with was compromised.
If you want to start from "known clean kernels", then make a bootable CDR.
Criteria 1: What is the purpose and character of the use?
The purpose of a hash is completely different from the purpose of a kernel.
In this case, they both have an identical purpose: "To make Linux run on the particular hardware". The end-user installing patches on his system has no way to tell which file is the kernel and which the hash (except by guessing from names or sizes). The externally visible behavior is the same- when both files are installed, Linux runs.
Criteria 4: What effect does the use have on the market for the original work?
The hash enables a new variant of DRM-enabled Linux to enter the market, becoming competition with traditional open-hardware Linux, and reduces it's sales. (This would be strengthened if the Linux variant the DRM vendor copied from had been written by an existing competitor in a market, whom had neglected to invest in DRM hardware)
Criteria 3, of course, overrides anything else. Even though it might really be as much as 256 bytes, the hash still cannot be considered a copyright infringment on Linux such that the GPL would apply to it.
Probably he means not that you can get the hardware for free, but that you might be able to make the hardware useful without spending $20 per month on the service subscription.
Really, all the "service" provides beyond occasional feature-removing software patches is a digital list of each day's television broadcast schedule. (Which the machine uses to pick out what channels to record and when)
TVGuide.com would happily provide the same quality of data for a much lower fee, and a few Perl scripts could reformat it into whatever shape the set-top unit needs.
Thus, the hardware manufacturer is motivated to prevent users from tweaking software.
You're joking, but that's not actually a bad idea.
Open Source DRM would have the weakness that any user with a little programming skill can work around the copy protection.
However, if society was a little less focused on corporate profit, that kind of easily breakable protection would be good enough.
An Open Source DRM system might look like this: authorship, licensing, and payment metadata can be attached to any media file. When users play the song, their software logs that fact and presents a button (maybe immediately after playing, or maybe accumulated once per week) which can be pressed to deposit $0.10 - $0.75 into an account with the musician.
If the price is cheap enough (well under a long-distance phone call), then people could pay willingly, relying on self-conciousness and peer-pressure to enforce a modicum of compliance. Call it a shareware model, with added software to expedite payment (no one's willing to mail a cheque for $0.50, but an easy digital payment might be a fun way to support your favorite artist)
Fraud prevention is a concern, but I can think of a few good ways to prevent spoofing a musician.
The stock reply is that
"copying media has been expensive and slow for 1000's of years... advancement of technology made it cheap and quick, meaning it needs to be encrypted"
(That reply, however, is an example of reasoning that is simple, elegant, and wrong)
Nowhere in this message does Linus even begin to talk about RIAA-driven media protection schemes. Why are you even bringing it up in this post? "Digital copyright protection" IS NOT the be-all and end-all of DRM.
No, but it is the most important component of DRM. Digital=digital, rights=copyrights, and management=protection. Prehaps Linus didn't include it in the message, because he felt everyone already knew.
The reason that some people want to sign custom kernels is so that programmers, paid by the RIAA, can produce kernels which will refuse to copy files that have the DRM flag turned on. This way, they can sell devices that compete with TiVo, but forbid the buyer from doing certain activities. And the fact that the kernel's signature is checked by the hardware means that users can't go back and modify the kernel to be more cooperative, even though the GPL has entitled them to a copy of the source.
Linus's posting was his acknowledgement that he will not try to prevent those kinds of DRM features from being added to variants of Linux.
It is aimed at Linux in 2 ways:
1) The RIAA and MPAA fear Linux as a gateway through which their DRM-protected files can escape. DRM may stop two Windows users from trading songs, but any single system which can ignore DRM can encode an audio CD as non-protected traditional MP3s and upload them to Kazaa. From there, the horse is out of the barn.
2) Microsoft fears Linux as a competitor. They plan to collaborate with the music and movie industry to persuade consumers that DRM is in their best interests. "Get the DRM Windows OS running on DRM Intel chips, and you can buy all these great movies at 60% off the DVD price" The fact that those DRM Intel chips would completely refuse to execute any non-DRM OS (such as all existing forms of Linux) won't be mentioned in the advertising.
Digital rights management is just that -- digital rights management.
For rhetorical purposes, I would prefer to call it "digital rights reduction". (Or "restriction", or "removal") That will emphasize the fact that the neutral word "management" actually means "taking away functionality". It'll help people understand that DRM hardware is meant to work against the wishes of it's owner.
It doesn't matter to this discussion at all, but
Heck, if the box was networked, it could just download the public key from a key server somewhere, or even grab it from a web server, because they're public!
If the X-Box expects to get the public key from the network, that opens a security hole where someone can spoof the trusted remote system. Hacker creates a new binary, signs it with his own private key, then tricks the box into thinking his public key is actually Microsoft's.
Keeping the public key in hardware is much safer, because it raises the bar for altering software the X-Box accepts. Replacing hardware is more difficult than running a little spoof-server on your PC, and a faster way to get arrested too.
(If the communication between the X-Box and the keyserver were encrypted, then that's just another key stored on X-Box hardware)
My hope is that variations on this scenario will occur so frequently that there will be a thriving, legal market in non-DRM machines.
For a more pessimistic view, assume that as long as the non-DRM machines are on the market, makers of DRM hardware will have legions of support personnel ready to accept source code and send back signed binaries on an hour's notice. Doing this quickly is possible, as long as they err on the side of accidently permitting DRM violations to occur, rather than accidently breaking operation. (The MPAA might not like it when something insecure signed programs slip through, but if they're smart they'll shut up and wait it out)
Or the manufacturers can use other means, but they'll work very hard to ensure driver-snafus like yours never last long enough to bother many customers.
During that time, there's no visible advantage to non-DRM, but DRM-enabled boxes will have more uses (watch movies to relax after work, etc. Maybe even work-related uses: online access to copy-controlled technical documentation)
Only after the non-DRM vendors have been driven from the marketplace will the makers of DRM systems (and their taskmasters at the RIAA and MPAA) feel ready to clamp down and show how firm DRM control can really be.
That might show that there really was a market for non-DRM hardware after all- but once you've stopped production, the rapid SOTA in the computer industry means the barrier to re-entry is nearly insurmountable.
Apparently Linux doesn't print such a message, though.
But, the University can simply forbid students from dumping a boot-image to CD, if the computer in question belongs to the university and isn't distributed to the student.
Do you know if they actually bothered to issue such an edict?
Ignoring the issue of why a University would ever want to keep kernel changes secret, and heading towards different but related terrain, are we sure the person who modified the software is allowed to make that forbiddance?
3 situations:
- In the case of this University, it may naturally seem they can. (It's their hardware, after all) The students signed an agreement that they wouldn't perform certain actions before getting allowed into the lab.
- If a portable music player included GPL software, could the vendor forbid customers from downloading it off the ROM? This time the user owns the hardware, but maybe he was required to sign a contract agreeing to no downloads before sale.
- If I send you a modified GPL program and don't want you to redistribute it, can I first require you to sign a contract promising to never copy it, regardless that the GPL license says you may?
The last case cannot possibly work, because if it did, such a giant loophole would eliminate all GPL protections. And the second case is very similar.They are both clear violations of GPL section 6, "may not impose any further restriction on the recipient"
If the agreement to use the school computer lab might count as such a restriction is not so clear. (And I won't even get into the question of if the individual part-time employee who installed those boot images is allowed to take copies home with him)
(I suspect that more people would've read and responded if that post had been, oh, 20% of it's length)
Unfortunately, DRM in hardware means buying all new sound cards (and video cards, etc).
By a "hardware model", are you proposing that key validation and decryption is done on the output hardware (videocard), rather than the computer software being allowed to view the content in the clear? (That is, encrypted file is loaded from the DVD-ROM, copied to memory as an unintelligble bag of bits, and pushed to the videocard which decrypts and sends down the VGA port)
That removed many of the advantages computer software can provide, or at least make software (and hardware) developer's lives much more difficult. Because no software can see the data in the clear, it has absolutely no chance to perform any kind of useful transformation on the data. In ordinary use, many transformations are absolutely required- which means that the videocard will need to have an interface built so it can be instructed to perform those commands.
Individually, none of those features is very hard They include repositioning, flipping, rotation, gamma correction, clipping, scaling, and the like. (Audio files would need their own set of effects) But put them all together, and the complexity of interacting with a videocard has increased substantially.
(The MacOSX feature of genielike warping a running video down into a dock icon will be completely out of there)
True, existing videocards already do most of those things in the form of accelerator functions... but those are a concern for the driver author at the hardware vendor.
As a GUI author, I'm scared to think of what these further restrictions could bring to my code- it's an enforced layer of extra redirection. Imagine writing a 3d videogame whose visual and audio resources are protected by DRM (they'll at least want to do this for the soundtrack).
As time passes, and more and more data transformations need to be performed on the trusted output device, we could reach the point (reminiscent of NVidia's Cg) where the output card has a CPU to run arbitrary programs that can manipulate the data in the clear, but have no ability to send messages back to the main OS. As a computer user, it pains me to think of sitting in front of so much processing power, and not being able to use it for running arbitrary programs.
I won't bore you with endless details of each little obstacle, so here's my upshot:
The "hardware solution" would entail substantial changes to many core aspects of personal computer design. Those changes will be difficult and expensive, and are dependent on cooperation of vendors of many kinds of hardware.
Microsoft's planned DRM model, on the other hand, will use a small amount of trusted hardware to verify that all executing software is likewise trusted, and then let the software handle protected data in the same way it processes anything else. Microsoft will have big advantages in pushing this scheme forward:
A) It relies on cooperation from fewer manufacturers.
B) The majority of software will need fewer changes in how it runs.
C) That "trusted hardware" will made it even more difficult to install Open Source software, further marginalizing Linux and protecting MS desktop market share. (This strong financial motive can translate into willing investment from their cash reserves, pushing this plan forward)
Alot of hardware is made in China and Japan, most likely they don't share the same ideals as the RIAA
Japan does. So does Taiwan. Their music industries share the same goals and concerns as the US one.
Mainland China does not, yet. But the US Army has displayed a strong inclination to forcibly export their legal viewpoints around the world. (Although more likely, they'd use a gentler application of force to destroy the rouge hardware before it reaches customers in the US)
The RIAA is alone in it's battle,
They have many friends, and not just billions of dead Presidents. The bulk of the uninformed music consumers of the country are generally happy with the job the RIAA is doing, and see no reason to oppose it.
The GPL is used in lots of places where the binaries are not distributed (eg. my university installs its own kernels on its own machines, but doesn't distribute them elsewhere).
In that situation, "distribution" has occured, in both the legal and English language definitions of the word.
The university had one copy of the kernel. They made many copies, and carried them to various computers around campus. That is undeniably "distribution" in the simplest sense- the material has been spread out.
It might not seem that way by common business usage- some people may think that if all recipients belong to the college, it hasn't gone far enough to really matter.
But the GPL lives in the realm of copyright law. Whenever someone wishes to perform an act which would violate copyright, she must first agree to the GPL, and place the products of that act under GPL. To take a legally acquired piece of software and make copies to run on second and third computers is a copyright violation. (The University obviously cannot argue that installing a single $299 Microsoft Windows disc on 35 computers is not an infringment)
In the case of this University, then by GPL section 2b, they must license it at no charge to any third parties. If a student using the computer dumps a boot-image to CD, and then wants a copy of the modified source, he is entitled to it for the nominal fee for shipping and handling.
it should be pretty easy to make a legal argument
It might be possible, but it won't be easy. The question is sufficiently vague that the skills and endurance of the opposing legal teams will really come into play (biasing the results in favor of whichever wealthy corp pays the fattest retainers)
A few points they could contend follow:
Several videogames (Quake, etc) have been released under the GPL. That only covers the source code, though. Additional copyrighted materials (graphic and audio files) are needed to make it actually run. Yet one has objected to that practice. GPL programs are often dependent on an external resource that is non-GPL.
Of course, that situations and the kernel-signing one are non-identical. A person can produce a modified game binary that will run with the officially supplied graphics. But a modified kernel binary won't work with the officially supplied key.
A separate argument your side might but forth is that all software engineers employed by the hardware vendor have the ability to sign and run code as they perform their daily work. That key-generator is truely a preferred tool for making modifications.
But, is it part of the source code? It's not derived from any GPL work, for example (it's just a certain random number they've picked as a private key). Many publishers of GPL software have things which they prefer to use, but aren't obligated to distribute. (Internal technical documentation, commercial compilers, etc. In fact, part of Red Hat's business model is charging extra for those documents.)
The decision to not "impose your moral values" is in itself an imposition of your moral values on me. Everything we do and don't do has an effect on everyone around us.
"Qui tacet, consentire videtur"
Silence gives consent
3) Our IT guys build a kernel that's tweaked for our company. They sign the kernel, and set the BIOS to only boot kernels with their signature.
Seems like a rather pointless example.
The IT guys should be the only people with root password access- they're the only ones able to install kernels on hard drives.
Likewise, they should be the people with BIOS passwords, which, in a controlled corporate setting, are already needed to allow a machine to boot once a case-opening has been detected (such as replacing the hard-drive).
The only purpose a signed kernel serves in that situation is to make it easier for the the IT department to enforce compliance among it's own staff. Someone who's not trusted to build kernels can still use root passwords and install them, since it's signed.
However, if you don't trust someone to sign, should you really trust him with root? (Certainly not in a modern Linux workstation environment)
This, I think, actually violates the GPL. They're distributing a Linux binary, and they're not giving you any way at all to modify it.
It does violate the intent of the GPL, but it's hard to see how the letter of the agreement is being disobeyed.
The vendor supplies you with hardware, software, and the source code to that software. You can read, modify, redistribute, and recompile that source code.
But you have no legal guarrantee that after you modify the source code, it will run on any hardware you have.
not given the "source code" you need to compile that part of the binary.
You might be. Depending on how the signatures are implemented and stored, compiling the vendor-supplied sourcecode without editing it at all might produce something that'll run and work. Change one tiny thing, of course, and it's "System corruption detected. Consult your warranty for support options"
The fixed signature ends up being an important part of the running binary,
This is the crux of the matter. If you can prove in court that the signature is a part of the program, then your argument for a GPL violation is OK.
But I don't see how the key can be considered part of the program under the definitions of the GPL. At least, I doubt it's a GPL-protected work. The GPL functions based on copyright. The core of the GPL is that "It's illegal to distribute modified versions of a copyrighted work without permission. But declare your modified version to be GPL also, and you've got permission."
Thus, GPL-protected materials are things either A) willingly declared as such by their original creator or B) based on a modification of something that's already GPL.
Since the creator of the signature (hardware vendor) doesn't want it to be GPL, it certainly won't meet point A. Does it meet point B? Only if producing a signature of a file is enough to violate the copyright on that file. It would be hard to claim that a 2048 bit signature of a 4 megabyte kernel is an infringing copy. We shall see in time.
but you can allow the end user to run a quick command to insert the keys into the binary him/herself.
Why even bother? If you ship the key separately from the binary, then just let the kernel load it from a known filename on bootup. Makes no difference.
However, if the key is shipped in a different file from the kernel (regardless of whether that file is meant to be patched onto the kernel, or just read), the key has been "made public". In one sense.
It's public in that many, many people can easily find and read the key, without having to disassemble the kernel binary and search for the exact instruction that checks the key.
It's not public in that those people aren't allowed to do some things with the key. If it were in the kernel source code, they've have a right to duplicate and redistribute it.
Yeah, but then the modified binary would fail the signature check; you've just suggested nothing.
His suggestion would work, at least for that part. However, the whole idea is fairly meaningless- it makes no difference if the key is distributed inside the binary or alongside it, except that the former case will often be a GPL violation.
He suggests a loophole to work around that violation. The signature would've been computed against the modified binary, not the one output by the C compiler.
It would be mathematically tricky (or close to impossible?) to compute a signature that accept a binary containing that same signature (since the signature wasn't known back when the signature was being computed, it's hard to keep the signature in the signed part of the binary). Easier is to just declare that the final 2048 bits of binary (the part containing the signature) is not to be checked for signing.
In that case, though, you're essentially transmitting the binary and signature in separate files (like how MD5 sums are done today), and just coincidentally storing them adjacently them upon reciept.
Either way lets hardware-manufacturing corporations (and their software-developing partners) further take power away from end users and amateur programmers.
Sure I understand the keys are not there, but if you have the program that does the encoding, you can understand the algorithms used can't you?
You don't necessarily have that. Yes, you get the source to the Linux kernel, but maybe it calls some modules or other programs which are opaque to you.
If you had the ability to edit the source code and run a modified kernel, you could change how it interacts with those modules to learn more about them (or simply subvert them). A lot of power has been removed from the end-user if that is impossible.
Of course, a person could grab the external modules and disassemble the binary code- but you can do this regardless of having the kernel source (it speeds the work if you know better where to look, but that's not a fundamental change)
You're giving them the keyhole, they can study it and make their own key.
To do that, they'd have to build custom hardware. If you're a giant corporation, you can build it from parts and just claim "I'm going to compete with the previous hardware manufacturer in the free market". But if a small group of individuals wants to do this, they can't start from scratch. They must modify the hardware they bought to do the new functions. Something like that will get you arrested under the DMCA, for constructing circumvention devices.
For DRM to work (do its job of protecting revenue for the entertainment industry), it doesn't have to be foolproof. No DRM can ever withstand hardware tampering- even if the source is closed, someone can reverse engineer it (often, you don't need to understand much of the code- just locate a few conditionals that can be changed to "always true"). Publishing the source code makes this step easier, but you've still got to build a modchip (something that many hackers know well how to do).
DRM is not primarily a technical defense, but a legal one. The technical aspect just has to ensure that only a tiny fraction of the population has the skill and motivation to break protection- few enough people so that jails can hold them.
The most probable one in my opinion (and what Linus alluded to by "providing a signed kernel") is that computer hardware will be sold which looks for a particular key/checksum on the kernel before agreeing to load it up. (Similar to how the Microsoft X-Box works today)
That kernel can then go on to enforce DRM policies on software you run- either by directly blocking copy-commands, or by restricting the list of userspace applications that can be executed to an approved list. (It may very well let you run a non-approved application. But DRM-protected files will be inaccessible to those programs.)
Note that this scenario won't work if 3rd party hardware vendors are allowed to sell modchips to override which kernels the computer accepts. But laws like the DMCA make trafficing in such circumvention devices illegal.
Two (of many) potential dangers if personal computer technology goes down this path:
Is this some kind of new precedent?
"Don't click through, it's reproduced below"
Apparently the Slashdot editors have changed their position on caching pages to prevent overload (the "Slashdot effect")
Will this be a permanent change, I wonder? And how did Michael get around those pesky US copyright laws? Did he actually wait for Linus's permission before duplicating his email?
You might want say how you're defining "intelligence" before you make a statement like that
The scientific definition of intelligence is "the ability to score highly on an intelligence test". It's beautifully circular, but the only fair way to discuss mental capacity across a variety of disciplines.
ignoring how modern people benefit from the vast base of existing knowledge on which to grow their own.
Of course it's ignoring it. "Base of knowledge" is not intelligence.
Your assertion is basically saying that evolution has not only stopped,
No, it says that the traits which evolution selects for aren't necessarily what you'd hope. Today, highly intelligent people are less reproductively successful.
However, for any meaningful interpretation, evolution hasn't changed humanity at all since the paleolithic days. They were less than 20,000 years ago- an "evolutionary eyeblink", as they say.
One would think that if it had some decent supporting evidence there would be lot more easily referenced material around to support it than a few "thick books".
That's an argument from popularity, there. Facts which are true but unpleasant and unhelpful will not naturally be easy to find. However, the particular volume I was mentioning has garnered enough Pultizers to ensure near-total availablity at your local library.
Give a hoot- read a book!
but I say that the Strawberry Shortcake material was the primary subject of the material
Gabe Newell disagrees with you on that point (he says so in the text he wrote to accompany the image). I'd expect the same from a judge or juror- upon learning the comic was written for a professional videogames website, they will agree that the primary subject was the one most pertinent to videogames (that is, a famous game designer, rather than a 15-year old pink doll)
Did he wake up in the morning and decide "I think I'll write about a toy I saw once in elementary school?" Of course not- he read an annoucement of "American McGee's Oz" and pondered "What other innocent, girlish fantasy-land could he plunder next?"
More accurately, the comic is making a statement how American McGee would (unintentionally) make a parody of Strawberry Shortcake if he were allowed to convert it to a videogame.
Exactly. That's the gripping hand. "making a statement how American McGee" tells us that the critical commentary is directed towards McGee primarily, not Strawberry Shortcake. You say they allude to a parody of SShortcake, suggesting that McGee would make one, but even if that's so, they aren't themselves parodying SShortcake.
I like it, but then I've been following Penny Arcade for years.
It's a good joke- somewhat esoteric, so a reader will feel satisfied if he understood it without hints. (and people who needed hints from the text to remember who AMG or SS were probably wouldn't get the joke even with help)
I agree that the material you are infringing should be the subject (or one of the subjects) of the parody
I don't agree with that, actually. Yes, that is the law. But I don't believe it should be.
I like it, but then I've been following Penny Arcade for years.
It's lasted better than Nickel Arcade, that's for sure.
It could do "harm" if, for instance, a 7 year old girl types "Strawberry Shortcake" into Google's image search and recieves images of erotic torture.
A corporation marketing to parents of young children will certainly feel they've been harmed if they get one angry letter along those lines.
A company like that might enjoy being percieved as "intolerant of fantasy sexual abuse".