Oh, and I forgot to mention, GPG doesn't use IDEA because it requires a hefty license for commercial use.
It doesn't include it by default because of patent issues, but if you need it, it's available. (There's even a precompiled Windows DLL.) Of course, depending on where you live, it may be against the law for you to use this code. You may even care. You might even be able to negotiate a license from the patent-holders to use the code, and still save money compared to what a commercial IDEA-based system might cost. And that might even help you begin a gradual migration away from IDEA and it's associated licensing fees, if an abrupt transition isn't possible. Just a thought.
I'm not particularly happy living under our current operating system monopoly, but this article only bolsters my concern that we're on the brink of creating a new one.
A monopoly, in and of itself, is not a bad thing.; in fact, in many cases, it can be a good thing. What's bad is when a company abuses its monopoly position to lock out competition, lock in customers, and leverage new markets. None of this is really possible with Linux, since it's an open system, and anyone can create their own derivative products to compete with the existing ones.
I think, that the products of our success at programmers are in the position to undermine our ability to survive in our careers.
If your survival as a programmer is based on reinventing the wheel over and over, then maybe you don't deserve success. I know that as a programmer myself, I relish the opportunity to focus on the needs of my customers, rather than reinventing wheels because the existing wheels on the market a) can't legally be modified to work the way they're needed in a certain case, or b) have license restrictions that prevent them from being as fully deployed as they need to be.
Many years ago, I got a contract to write a quicksort routine. Now quicksort is part of the standard C library. Does it bother me that I no longer have the opportunity to write and sell quicksorts? Hardly! In fact, I'm overjoyed.
All the GPL says you can't do is to use the code in your own work without also making your own work available under the GPL.
Not exactly. It's more correct to say that the GPL fails to grant that privilege. Which is not a privilege you would have by default under normal copyright law.
The GPL doesn't forbid anything. All of the forbidding comes from copyright law. The GPL simply grants you permission to do some things you couldn't do otherwise. Using the code in your own GPL'd app is one; using the code in your own proprietary app is not.
But isn't the GPL more or less the same thing? [as an EULA]
No. This should be (and probably is, somewhere) a FAQ.
A typical EULA tries to remove rights that you would normally have as the purchaser of a copyrighted work. (For example, the right to reverse-engineer, or resell your copy of the work). Since these restrictions are above and beyond the legal default, the company offering the software must try to force you to accept these restrictions, by, e.g. clicking on an "Accept" button.
The GPL, on the other hand, simply grants you rights you would not have otherwise. You do not have to accept the GPL (and no attempt is made to force you to do so), but if you don't accept it, you simply fail to gain the privileges it grants, and are bound by standard copyright law.
It's trying to control what you do with something after it is in your possession?
No, that's copyright law that does that. The GPL is simply a limited grant of exception from the normal restrictions of copyright law. You can't use someone else's GPL'd code in your proprietary app because of copyright law. You can use someone else's GPL'd code in your GPL'd app because the GPL specifically grants you that right as an exception to the normal restrictions of copyright law.
a case like this could provide a precedent that would prove that the GPL is legally enforceable - something that has not occurred to date,
That's right, it hasn't. And violations are regular and frequent (dozens of times a year, according to Eben Moglen, the FSF General Counsel). But so far, no one has been stupid enough to take it to court. But Eben keeps hoping someone will. From an essay on his website: "'Look,' I say, 'at how many people all over the world are pressuring me to enforce the GPL in court, just to prove I can. I really need to make an example of someone. Would you like to volunteer?'"
Maybe this will finally be the time. But I'm not going to hold my breath. No one has had the proper combination of balls and stupidity yet. Frankly, I find that as persuasive, if not more so, than an actual court ruling on the matter.
But what it can't do is be a drop in replacements for PGP-- in terms of command syntax and output file format.
It probably could be, but it's true that it isn't. However, the former problem can be mostly solved with pgpgpg, and the latter problem is pretty rare in my experience.
Anyway, all the tools I use have been updated to work with GPG. I think some of them may have even dropped PGP support.:)
Actually, in my experience (20+ years general programming, a dozen or so with unix and unix-like systems), Linux is generally closer to Unix(TM) than BSD is in most respects, and porting programs from Unix to Linx is usually easier than porting to the BSDs from Unix. (Which probably has a lot to do with why a lot of companies that have supported Unix(TM) are now supporting Linux.)
For that matter, porting between Linux and BSD is usually easier than porting between Unix and BSD. Linux really does a good job, IMO, of offering the best of all worlds, and looking pretty close to what you'd expect, no matter what sort of unixlike system you expect.
I would correct your statement to "BSD is for people that enjoy the way BSD works, while Linux is for people that enjoy the way Linux works." Stated like that, though, it doesn't seem like much of a revelation.:)
1983. Billy Joel was singing this before Metallica existed.
Since the fellow was quoting Iron Maiden (who released their first album in 1980), that seems a spectacularly irrelevent piece of information.
Until you get a few more years under you belt, I would suggest you keep in mind the old adage "Children should be seen and not heard".
Irony, thy name is slashdot! I invite you to contemplate your own words, when I point out that the phrase was in common use when I was a kid -- over a decade before the Billy Joel crap^Wsong you mention. A quick google search reveals a British movie with that title released in 1954 (actually predating me, though by less than a decade). There's also a climbing trail in Nevada by that name, though I can't say how long ago it was named.
[A little more googling later:] The phrase was parodied as "only the young die good" by Oliver Herford (1863-1935). So it was in common usage at least half a century before the 1983 date you so ignorantly offered. I suspect that if I actually managed to trace it back, it would turn out to be from Cicero or Ovid or someone like that. The guy who attributed it to Iron Maiden was obviously pretty ignorant, but relatively speaking, no more ignorant than you, and at least he didn't follow up by bragging about how old and wise he was. So, I'd like to add another quote: "Dumbass!" -- Red Foreman.
(And yes, I'm grotesquely off-topic by now, but what good is karma if you can't waste it every now and then?:)
The really strange thing (to me) is that back when I first met ChrisD (back when he was involved with SVLUG), he was as intelligent and insightful as the next fellow. Now he joins the/. editorial staff, and he suddenly seems to have lost the ability to read or comprehend. Is it possible that working as a slashdot editor can actually cause physical brain damage?:)
Indeed, the jury is still out (as it were) on Rambus. They have won a decision, but not the case. The case is going back to the lower court.
To me, it seems strange to question mplayer about libavcodec while Xine already includes libavcodec.
Strange or not, it happened. People are welcome to question any of the licenses (or license combos) whenever they want. If we discover that we've made a mistake, we'll take steps to correct that mistake.
I would assume glibc isn't discussed on debian-legal every time a deb is made?
Every time? No, but if someone has an issue with the licensing of something, they're welcome to raise it at any time. A better example would be openssl, which is licensed with BSD+advertising-clause, which makes it incompatible with the GPL. Nobody noticed this at first, but once someone did notice it, we took steps to fix the problem, even removing SSL support from some programs.
> But that's not how people with integrity act.
Why this troll? The mplayer developers might be more direct that most people are used to, but this doesn't mean you should threat them with hostility
No, no, not talking about the mplayer folks at all. I have no problems with their complaints; that's fine, they're welcome to complain. And heck, even if the mplayer folks have been playing fast-and-loose with licenses, I wouldn't call that a lack of integrity. They're programmers, and programmers are more interested in technical matters than legal ones. As far as I'm concerned the integrity of the mplayer folks is just fine, they're doing what they want on the terms they want to do it on.
What I was saying is that if the mplayer folks expect Debian to say, "whoops, we accidentally broke our own rules, so I guess we can just ignore those rules now", then they're going to be disappointed. That would show a lack of integrity on Debian's part.
Why question the use of a changelog for libmpeg2
Now there I have to agree with you, I think that argument is ridiculous, and I hope it dies the horrible death it so richly deserves.
The issue, as pointed out by the Mplayer developers, is that Debian isn't consistent in the enforcement of their rules
Debian makes mistakes -- everyone makes mistakes. But Debian usually tries to correct those mistakes. Back when Qt was GPL-incompatible, Debian briefly had KDE in the archives, which was a mistake. When someone pointed out the licensing problems, KDE was removed. At which point, the KDE folks went ballistic, and started shouting about how Debian was inconsistent and hypocritical because they had GPL'd packages using libForms (another GPL-incompatible library), and that proved that Debian had it in for the KDE folks, and it was all some evil plot. Unfortunately for this theory, Debian simply agreed that they'd made another mistake by accepting those packages, removed them, and that was the end of that.
Debian can be a little slow-moving at times (a common problem with all-volunteer groups), but if the complaints about Xine are valid, then I have no doubt that Xine will be gone (or fixed) soon enough.
Why does debian-legal think they know what is GPL and what is not better than Mplayer and XAnim authors.
Well, gee, I don't know, why would a bunch of people who study licensing issue on a regular basis think they understand licensing issues better than a bunch of people who are focused on writing code?
Having programmers look for legal problems makes about as much sense as having lawyers review your code for possible bugs.
FYI this list consists of possible legal problems in Xine.
Then the fellow should file a bug report against Xine. If his complaint is valid, then I have no doubt that Xine will be fixed or removed.
Saying, "you made a mistake here, so you should just go ahead and make another mistake" is silly. The KDE developers tried this strategy (back when KDE had license problems), and they successfully managed to get several programs based on a gui toolkit called libForms removed from Debian. Of course, that wasn't actualy what they were trying to do. What they really wanted was for Debian to say, "ok, we allowed those GPL'd libForms-based programs in, so we'll allow your GPL'd qt-based programs in too." But that's not how people with integrity act.
And before you know it, you're arguing over what policy is appropriate, thinking as an individual and removing the illusion of a united front. Activists of any stripe just hate that.
Well, except for the activists for the Think For Yourself Front.:)
Ms. Biggs seems to be confusing TCPA and Palladium, and her analysis flatly contradicts what the IBM white paper says. In particular, things like: "All approved software must be signed and must have an approved serial number" are features of Palladium (if anything), not TCPA, at least according to IBM.
Since IBM released open-source drivers for Linux, I'd expect that the Linux kernel folks will be able to tell soon enough what the situation is. I seriously doubt if IBM thinks they can get away with lying about the capabilities of their drivers to the folks who maintain the kernel; I find it implausible that they'd even try.
If 20 years in this biz has taught me anything, it's that the opinions of so-called "pundits" are rarely worth the time it takes to read them. I'm much more interested in the opinion of the techies who actually know something. So, if Linus, Alan and friends, after analysing the drivers, come out and say, "this is evil, avoid at all costs," then I'll start to worry. If (as I find more likely at this point) they instead say, "this is interesting and potentially useful", then I think we'll be fine.
Another solution might be to have the original key match to an internal OS version ID, which would stay the same for mere SP upgrades, but not for version upgrades. Likewise spoofable (there is a util available to fool biased webservers into believing Win3.1 is Win9*, so..) but would certainly defeat the average user, and corporate accounts (where the real money is) couldn't get away with doing it, or they'd lose their support contract that they've already paid for.
But if it doesn't defeat hackers, then there's no additional advantage to having the public-key chip (TCPA). The vendors can already do this without a public key chip, and it'll already lock-in the average user and the corporate accounts just as firmly, and be just as ineffective against the hackers. So I don't think this can really be called a danger of the TCPA chip.
One thing that recently occurred to me is that if the Linux drivers really do allow full control of the chip (which early indications suggest is the case), then it would be possible to build a proxy into an emulator like bochs, which would forward any requests to the actual chip (so the proper signatures would be obtained/verified), but would allow scraping all the incoming/outgoing data without any need for hardware sniffers. This would pretty much put the ability to defeat any TCPA-based DRM schemes back into the hands of even impoverished students who can't afford fancy hardware to monitor the TCPA bus.
I think it'll be interesting to see how this all plays out.
1. American Football really should have geek appeal. It's a complex and interesting game that involves a whole lot more than just big, hairy guys hitting each other. I never realized this until I tried playing some of the computer simulations, and discovered worlds of fascinating strategy that I'd never realized were there when watching big hairy guys hit each other on TV (or, rather, when not really watching, but being annoyed because my friends were watching). Video games made this geek into an American Football fan.
2: as a resident of Oakland, current home of the Raiders (one of the teams playing in the big game today), I have to say: Al Davis (the team owner) is a complete scumbag who deserves to die! He has ripped off and or sued the city of Oakland more times that I can count, he screws over his fans, as a result of which, the local games are almost always blacked out (not shown on local TV), and as long as he is the owner of my home team, all I can say is: GO WHATEVER TEAM THAT IS THAT ISN'T THE RAIDERS! YAY WHOEVER-YOU-ARE! Oakland is pulling for you!:)
The private key part of the "endorsement" key cannot be read.
Well, that's definitely a little odd, but hardly a deal-breaker. I've been using public-key encryption on a regular basis for years now, and not once in that time have I had the slightest desire or interest in reading my own private key. As long as GPG can read it, everything works fine.
Actually, it occurs to me that M$ and hardware vendors could collectively use this to force more simultanous hardware and OS upgrades.
That's an interesting idea. However, unless MS improves their QA and security testing, they're going to continue to need to release service packs which would seem to break this scheme.
But, it's definitely something they could try if they were determined enough, and it sounds like it might be worth keeping an eye out for. You deserve a +1 insightful mod (though at this late date in this thread, I doubt you'll get one).
Yes, that the TCPA chip is NOT under your control.
Evidence? IBM just released open source Linux drivers for the chip, which would appear to place it under my control. In light of that, you make a bold claim, which, without evidence, I'm going to dismiss as paranoid ravings.
That is the entire purpose of it - it will not decrypt the DRM data unless running under the same operating system where it was created.
The white paper IBM published lists many purposes for the chip. You are welcome to claim that DRM is the original and maybe even the primary purpose, but when you claim it's the entire purpose, you are simply and clearly wrong.
it will not decrypt the DRM data unless running under the same operating system where it was created
This is the assertion I have been questioning all along. Re-asserting it does not further the discussion. How is the chip supposed to tell that I'm not subverting the system by scraping the data that it's going to use to generate the signature from elsewhere? This thing isn't magic, nor can it read my mind. I'm not interested in dogma, I'm interested in facts.
Furthermore, if it is trying to use the OS signature as a decryption key, then it's going to fail every time the OS is patched or upgraded, so people won't upgrade their OSes, which is a development that MS will fight tooth-and-nail. Their livelihood depends on people making regular upgrades to the latest-and-greatest flavor of Windows. Not to mention the fact that they have to release service packs now and again to address issues like the vulnerability that resulted in the recent netstorm.
No, I think the scheme you describe, while it might provide poor, easily bypassed DRM in theory will fail badly in practice.
Yes, where does it say that you'll have access to the endorsement keys in the TCPA Hardware?
I can't find that specifically, but it does say that the initialization and management functions "provide strong separation of what can be done at BIOS (boot) time, and what can be done at normal run-time, so that sensitive operations (like reading the edorsement key) can't be performed by malicious applications trying to compromise one's privacy."
The fact that reading the endorsement key is considered a "sensitive operation" strongly suggests to me that it IS AN OPERATION.
The DRM program is going to request something from the Palladium chip. This will be a number that it needs in order to decypt itself.
So, I've installed windows under bochs, so I know what the boot track is supposed to look like, and since I have control over the TCPA chip, I use it to generate the hash, and get the signature of the hash, and return that to the app running under wine, in place of the data it thinks it's getting from the chip, and the program decrypts itself, and I save the decrypted version, and go merrily on my way.
The trick is that you cannot modify the OS software, because each layer of it that is loaded verifies the next, down to the boot loader, which the TCPA chip takes the hash of. So a modified OS means a modified boot loader, and the DRM service will ask for the current boot loader hash signed by the TCPA chips "endorsement key"
Which is fine until I run the DRM service under Wine, and single-step through it to find out where it does the signature check, and patch it to bypass that check completely. Now I've got an application that will run under my emulator, and I've got the data, encrypted with the TCPA chip which is under my control, so I can decrypt it, and I would seem to be happy as a clam. Or, at least, no worse off than I am with any other proprietary format that needs to be reverse-engineered, like ra or wmv or whatever.
Slashdot Mirror
Oh, and I forgot to mention, GPG doesn't use IDEA because it requires a hefty license for commercial use.
It doesn't include it by default because of patent issues, but if you need it, it's available. (There's even a precompiled Windows DLL.) Of course, depending on where you live, it may be against the law for you to use this code. You may even care. You might even be able to negotiate a license from the patent-holders to use the code, and still save money compared to what a commercial IDEA-based system might cost. And that might even help you begin a gradual migration away from IDEA and it's associated licensing fees, if an abrupt transition isn't possible. Just a thought.
I'm not particularly happy living under our current operating system monopoly, but this article only bolsters my concern that we're on the brink of creating a new one.
A monopoly, in and of itself, is not a bad thing.; in fact, in many cases, it can be a good thing. What's bad is when a company abuses its monopoly position to lock out competition, lock in customers, and leverage new markets. None of this is really possible with Linux, since it's an open system, and anyone can create their own derivative products to compete with the existing ones.
I think, that the products of our success at programmers are in the position to undermine our ability to survive in our careers.
If your survival as a programmer is based on reinventing the wheel over and over, then maybe you don't deserve success. I know that as a programmer myself, I relish the opportunity to focus on the needs of my customers, rather than reinventing wheels because the existing wheels on the market a) can't legally be modified to work the way they're needed in a certain case, or b) have license restrictions that prevent them from being as fully deployed as they need to be.
Many years ago, I got a contract to write a quicksort routine. Now quicksort is part of the standard C library. Does it bother me that I no longer have the opportunity to write and sell quicksorts? Hardly! In fact, I'm overjoyed.
All the GPL says you can't do is to use the code in your own work without also making your own work available under the GPL.
Not exactly. It's more correct to say that the GPL fails to grant that privilege. Which is not a privilege you would have by default under normal copyright law.
The GPL doesn't forbid anything. All of the forbidding comes from copyright law. The GPL simply grants you permission to do some things you couldn't do otherwise. Using the code in your own GPL'd app is one; using the code in your own proprietary app is not.
But isn't the GPL more or less the same thing? [as an EULA]
No. This should be (and probably is, somewhere) a FAQ.
A typical EULA tries to remove rights that you would normally have as the purchaser of a copyrighted work. (For example, the right to reverse-engineer, or resell your copy of the work). Since these restrictions are above and beyond the legal default, the company offering the software must try to force you to accept these restrictions, by, e.g. clicking on an "Accept" button.
The GPL, on the other hand, simply grants you rights you would not have otherwise. You do not have to accept the GPL (and no attempt is made to force you to do so), but if you don't accept it, you simply fail to gain the privileges it grants, and are bound by standard copyright law.
It's trying to control what you do with something after it is in your possession?
No, that's copyright law that does that. The GPL is simply a limited grant of exception from the normal restrictions of copyright law. You can't use someone else's GPL'd code in your proprietary app because of copyright law. You can use someone else's GPL'd code in your GPL'd app because the GPL specifically grants you that right as an exception to the normal restrictions of copyright law.
a case like this could provide a precedent that would prove that the GPL is legally enforceable - something that has not occurred to date,
That's right, it hasn't. And violations are regular and frequent (dozens of times a year, according to Eben Moglen, the FSF General Counsel). But so far, no one has been stupid enough to take it to court. But Eben keeps hoping someone will. From an essay on his website: "'Look,' I say, 'at how many people all over the world are pressuring me to enforce the GPL in court, just to prove I can. I really need to make an example of someone. Would you like to volunteer?'"
Maybe this will finally be the time. But I'm not going to hold my breath. No one has had the proper combination of balls and stupidity yet. Frankly, I find that as persuasive, if not more so, than an actual court ruling on the matter.
But what it can't do is be a drop in replacements for PGP-- in terms of command syntax and output file format.
:)
It probably could be, but it's true that it isn't. However, the former problem can be mostly solved with pgpgpg, and the latter problem is pretty rare in my experience.
Anyway, all the tools I use have been updated to work with GPG. I think some of them may have even dropped PGP support.
I just had to take this opportunity to point out what I consider to be one of the most amazing pieces of ASCII art ever done -- from the Church of the Subgenius website, a 3d stereogram picture of JR "Bob" Dobbs, by Mike Jittlov, director of the low-budget cult classic, The Wizard of Speed and Time.
Actually, in my experience (20+ years general programming, a dozen or so with unix and unix-like systems), Linux is generally closer to Unix(TM) than BSD is in most respects, and porting programs from Unix to Linx is usually easier than porting to the BSDs from Unix. (Which probably has a lot to do with why a lot of companies that have supported Unix(TM) are now supporting Linux.)
:)
For that matter, porting between Linux and BSD is usually easier than porting between Unix and BSD. Linux really does a good job, IMO, of offering the best of all worlds, and looking pretty close to what you'd expect, no matter what sort of unixlike system you expect.
I would correct your statement to "BSD is for people that enjoy the way BSD works, while Linux is for people that enjoy the way Linux works." Stated like that, though, it doesn't seem like much of a revelation.
1983. Billy Joel was singing this before Metallica existed.
Since the fellow was quoting Iron Maiden (who released their first album in 1980), that seems a spectacularly irrelevent piece of information.
Until you get a few more years under you belt, I would suggest you keep in mind the old adage "Children should be seen and not heard".
Irony, thy name is slashdot! I invite you to contemplate your own words, when I point out that the phrase was in common use when I was a kid -- over a decade before the Billy Joel crap^Wsong you mention. A quick google search reveals a British movie with that title released in 1954 (actually predating me, though by less than a decade). There's also a climbing trail in Nevada by that name, though I can't say how long ago it was named.
[A little more googling later:] The phrase was parodied as "only the young die good" by Oliver Herford (1863-1935). So it was in common usage at least half a century before the 1983 date you so ignorantly offered. I suspect that if I actually managed to trace it back, it would turn out to be from Cicero or Ovid or someone like that. The guy who attributed it to Iron Maiden was obviously pretty ignorant, but relatively speaking, no more ignorant than you, and at least he didn't follow up by bragging about how old and wise he was. So, I'd like to add another quote: "Dumbass!" -- Red Foreman.
(And yes, I'm grotesquely off-topic by now, but what good is karma if you can't waste it every now and then?:)
The really strange thing (to me) is that back when I first met ChrisD (back when he was involved with SVLUG), he was as intelligent and insightful as the next fellow. Now he joins the /. editorial staff, and he suddenly seems to have lost the ability to read or comprehend. Is it possible that working as a slashdot editor can actually cause physical brain damage? :)
Indeed, the jury is still out (as it were) on Rambus. They have won a decision, but not the case. The case is going back to the lower court.
To me, it seems strange to question mplayer about libavcodec while Xine already includes libavcodec.
Strange or not, it happened. People are welcome to question any of the licenses (or license combos) whenever they want. If we discover that we've made a mistake, we'll take steps to correct that mistake.
I would assume glibc isn't discussed on debian-legal every time a deb is made?
Every time? No, but if someone has an issue with the licensing of something, they're welcome to raise it at any time. A better example would be openssl, which is licensed with BSD+advertising-clause, which makes it incompatible with the GPL. Nobody noticed this at first, but once someone did notice it, we took steps to fix the problem, even removing SSL support from some programs.
> But that's not how people with integrity act.
Why this troll? The mplayer developers might be more direct that most people are used to, but this doesn't mean you should threat them with hostility
No, no, not talking about the mplayer folks at all. I have no problems with their complaints; that's fine, they're welcome to complain. And heck, even if the mplayer folks have been playing fast-and-loose with licenses, I wouldn't call that a lack of integrity. They're programmers, and programmers are more interested in technical matters than legal ones. As far as I'm concerned the integrity of the mplayer folks is just fine, they're doing what they want on the terms they want to do it on.
What I was saying is that if the mplayer folks expect Debian to say, "whoops, we accidentally broke our own rules, so I guess we can just ignore those rules now", then they're going to be disappointed. That would show a lack of integrity on Debian's part.
Why question the use of a changelog for libmpeg2
Now there I have to agree with you, I think that argument is ridiculous, and I hope it dies the horrible death it so richly deserves.
The issue, as pointed out by the Mplayer developers, is that Debian isn't consistent in the enforcement of their rules
Debian makes mistakes -- everyone makes mistakes. But Debian usually tries to correct those mistakes. Back when Qt was GPL-incompatible, Debian briefly had KDE in the archives, which was a mistake. When someone pointed out the licensing problems, KDE was removed. At which point, the KDE folks went ballistic, and started shouting about how Debian was inconsistent and hypocritical because they had GPL'd packages using libForms (another GPL-incompatible library), and that proved that Debian had it in for the KDE folks, and it was all some evil plot. Unfortunately for this theory, Debian simply agreed that they'd made another mistake by accepting those packages, removed them, and that was the end of that.
Debian can be a little slow-moving at times (a common problem with all-volunteer groups), but if the complaints about Xine are valid, then I have no doubt that Xine will be gone (or fixed) soon enough.
From the MPlayer home page:
Why does debian-legal think they know what is GPL and what is not better than Mplayer and XAnim authors.
Well, gee, I don't know, why would a bunch of people who study licensing issue on a regular basis think they understand licensing issues better than a bunch of people who are focused on writing code?
Having programmers look for legal problems makes about as much sense as having lawyers review your code for possible bugs.
FYI this list consists of possible legal problems in Xine.
Then the fellow should file a bug report against Xine. If his complaint is valid, then I have no doubt that Xine will be fixed or removed.
Saying, "you made a mistake here, so you should just go ahead and make another mistake" is silly. The KDE developers tried this strategy (back when KDE had license problems), and they successfully managed to get several programs based on a gui toolkit called libForms removed from Debian. Of course, that wasn't actualy what they were trying to do. What they really wanted was for Debian to say, "ok, we allowed those GPL'd libForms-based programs in, so we'll allow your GPL'd qt-based programs in too." But that's not how people with integrity act.
And before you know it, you're arguing over what policy is appropriate, thinking as an individual and removing the illusion of a united front. Activists of any stripe just hate that.
:)
Well, except for the activists for the Think For Yourself Front.
Ms. Biggs seems to be confusing TCPA and Palladium, and her analysis flatly contradicts what the IBM white paper says. In particular, things like: "All approved software must be signed and must have an approved serial number" are features of Palladium (if anything), not TCPA, at least according to IBM.
Since IBM released open-source drivers for Linux, I'd expect that the Linux kernel folks will be able to tell soon enough what the situation is. I seriously doubt if IBM thinks they can get away with lying about the capabilities of their drivers to the folks who maintain the kernel; I find it implausible that they'd even try.
If 20 years in this biz has taught me anything, it's that the opinions of so-called "pundits" are rarely worth the time it takes to read them. I'm much more interested in the opinion of the techies who actually know something. So, if Linus, Alan and friends, after analysing the drivers, come out and say, "this is evil, avoid at all costs," then I'll start to worry. If (as I find more likely at this point) they instead say, "this is interesting and potentially useful", then I think we'll be fine.
Another solution might be to have the original key match to an internal OS version ID, which would stay the same for mere SP upgrades, but not for version upgrades. Likewise spoofable (there is a util available to fool biased webservers into believing Win3.1 is Win9*, so..) but would certainly defeat the average user, and corporate accounts (where the real money is) couldn't get away with doing it, or they'd lose their support contract that they've already paid for.
But if it doesn't defeat hackers, then there's no additional advantage to having the public-key chip (TCPA). The vendors can already do this without a public key chip, and it'll already lock-in the average user and the corporate accounts just as firmly, and be just as ineffective against the hackers. So I don't think this can really be called a danger of the TCPA chip.
One thing that recently occurred to me is that if the Linux drivers really do allow full control of the chip (which early indications suggest is the case), then it would be possible to build a proxy into an emulator like bochs, which would forward any requests to the actual chip (so the proper signatures would be obtained/verified), but would allow scraping all the incoming/outgoing data without any need for hardware sniffers. This would pretty much put the ability to defeat any TCPA-based DRM schemes back into the hands of even impoverished students who can't afford fancy hardware to monitor the TCPA bus.
I think it'll be interesting to see how this all plays out.
1. American Football really should have geek appeal. It's a complex and interesting game that involves a whole lot more than just big, hairy guys hitting each other. I never realized this until I tried playing some of the computer simulations, and discovered worlds of fascinating strategy that I'd never realized were there when watching big hairy guys hit each other on TV (or, rather, when not really watching, but being annoyed because my friends were watching). Video games made this geek into an American Football fan.
:)
2: as a resident of Oakland, current home of the Raiders (one of the teams playing in the big game today), I have to say: Al Davis (the team owner) is a complete scumbag who deserves to die! He has ripped off and or sued the city of Oakland more times that I can count, he screws over his fans, as a result of which, the local games are almost always blacked out (not shown on local TV), and as long as he is the owner of my home team, all I can say is: GO WHATEVER TEAM THAT IS THAT ISN'T THE RAIDERS! YAY WHOEVER-YOU-ARE! Oakland is pulling for you!
The private key part of the "endorsement" key cannot be read.
Well, that's definitely a little odd, but hardly a deal-breaker. I've been using public-key encryption on a regular basis for years now, and not once in that time have I had the slightest desire or interest in reading my own private key. As long as GPG can read it, everything works fine.
Actually, it occurs to me that M$ and hardware vendors could collectively use this to force more simultanous hardware and OS upgrades.
That's an interesting idea. However, unless MS improves their QA and security testing, they're going to continue to need to release service packs which would seem to break this scheme.
But, it's definitely something they could try if they were determined enough, and it sounds like it might be worth keeping an eye out for. You deserve a +1 insightful mod (though at this late date in this thread, I doubt you'll get one).
Yes, that the TCPA chip is NOT under your control.
Evidence? IBM just released open source Linux drivers for the chip, which would appear to place it under my control. In light of that, you make a bold claim, which, without evidence, I'm going to dismiss as paranoid ravings.
That is the entire purpose of it - it will not decrypt the DRM data unless running under the same operating system where it was created.
The white paper IBM published lists many purposes for the chip. You are welcome to claim that DRM is the original and maybe even the primary purpose, but when you claim it's the entire purpose, you are simply and clearly wrong.
it will not decrypt the DRM data unless running under the same operating system where it was created
This is the assertion I have been questioning all along. Re-asserting it does not further the discussion. How is the chip supposed to tell that I'm not subverting the system by scraping the data that it's going to use to generate the signature from elsewhere? This thing isn't magic, nor can it read my mind. I'm not interested in dogma, I'm interested in facts.
Furthermore, if it is trying to use the OS signature as a decryption key, then it's going to fail every time the OS is patched or upgraded, so people won't upgrade their OSes, which is a development that MS will fight tooth-and-nail. Their livelihood depends on people making regular upgrades to the latest-and-greatest flavor of Windows. Not to mention the fact that they have to release service packs now and again to address issues like the vulnerability that resulted in the recent netstorm.
No, I think the scheme you describe, while it might provide poor, easily bypassed DRM in theory will fail badly in practice.
Yes, where does it say that you'll have access to the endorsement keys in the TCPA Hardware?
I can't find that specifically, but it does say that the initialization and management functions "provide strong separation of what can be done at BIOS (boot) time, and what can be done at normal run-time, so that sensitive operations (like reading the edorsement key) can't be performed by malicious applications trying to compromise one's privacy."
The fact that reading the endorsement key is considered a "sensitive operation" strongly suggests to me that it IS AN OPERATION.
The DRM program is going to request something from the Palladium chip. This will be a number that it needs in order to decypt itself.
So, I've installed windows under bochs, so I know what the boot track is supposed to look like, and since I have control over the TCPA chip, I use it to generate the hash, and get the signature of the hash, and return that to the app running under wine, in place of the data it thinks it's getting from the chip, and the program decrypts itself, and I save the decrypted version, and go merrily on my way.
The trick is that you cannot modify the OS software, because each layer of it that is loaded verifies the next, down to the boot loader, which the TCPA chip takes the hash of. So a modified OS means a modified boot loader, and the DRM service will ask for the current boot loader hash signed by the TCPA chips "endorsement key"
Which is fine until I run the DRM service under Wine, and single-step through it to find out where it does the signature check, and patch it to bypass that check completely. Now I've got an application that will run under my emulator, and I've got the data, encrypted with the TCPA chip which is under my control, so I can decrypt it, and I would seem to be happy as a clam. Or, at least, no worse off than I am with any other proprietary format that needs to be reverse-engineered, like ra or wmv or whatever.
Am I missing something?