Kazaa is a decentralized filesharing network with a centralized login mechanism. But authentication is really enforced only in the client. As insurance against being shut down by a lawsuit, if the login servers disappear, the clients are supposed to just forget about authentication and join the network anyway, by trying to connect to any of a series of hardcoded supernodes. This list is also supposed to be refreshed whenever you connect to the network.
My guess is that the login servers are down and the linux binary's supernode list is out of date. (And I don't know about you, but I have to wipe out the whole.kza directory every time I run kazaa or it crashes on restart; so I surely don't have a refreshed list saved.)
I further imagine that by editing in the address of a working supernode into the binary or config file somewhere, you can get the linux version to connect.
> The main problem is if the courts go after the authentication servers. This isn't happening yet.
Actually, I have read (in the leaked RIAA memo on fasttrack) that if the authentication servers are unreachable, the software will connect to the network without authenticting. It comes with a long list of peers to try connecting to, which whenever it connects. If this is true, and kazaa etc. vanish with their servers, the software should keep working.
On the other hand, I have read (in the New York Times article on video trading yesterday) that FastTrack have the ability to shut down the software remotely. And this would seem to be borne out by the time they forced everyone to upgrade to version 1.33. (Though maybe this was accomplished in the authentication process.)
Well, this should be bad news for Redhat, since (a) it costs half as much, and (b) the Ximian client is much nicer than redhat's abominable little mess.
But on the other hand, Ximian does a terrible job of keeping up with redhat advisories; for instance last week's glibc buffer overflow finally showed up in red carpet today. What's the point of paying Ximian for an upgrade service if you're still going to have to go trawling around ftp sites (or subscribe to Redhat's prompter service) in order to make sure you're actually up to date on serious bug or security fixes in your operating system?
I somehow fail to believe that a technology that MS have spent a long time and a lot of money developing is _exactly the same thing_ as an option buried in XFree.
It's good technology, but it's a very, very simple idea and a straightforward extension of basic antialiasing; it's only the branding exercise that makes you think Microsoft spent any time or money on it. There's also a reason I suspect that it's buried in XFree86 and not trumpeted around much: Microsoft has it patented. The patent is completely spurious, of course, as subpixel sampling has been around since the Apple II era at least (NYTimes had a good article about just this when the patent was granted), but one would presume the Xfree folks don't want to go to court over it.
Also, as another poster pointed out, there's several odds and ends that go under the rubric ClearType, (though the main one having to do with fonts on LCD screens, which was the original topic of this thread, is subpixel sampling). And there's also several other reasons fonts look better in Windows than Linux. In particular, the fonts themselves are much, much better, and the font rendering engine is better as well. But yes, basically the same infrastructure *is* buried in XFree86, it's just not tweaked as nicely yet.
I hate to say it, but the ClearType technology in Windows XP blows AA fonts out of the water.
Actually, Xft has the little-known capability of doing subpixel sampling on LCD screens (which is what ClearType is).
To enable it you just have to set the X resource "Xft.rgba: rgb" though depending on the orientation of your LCD panel you may have to use "bgr" or "vrgb" or "vbgr" in place of "rgb".
Oh yeah, and another interesting tidbit was that the leaked threat letter from the SDMI to him wasn't the only one -- he said that all of the authors, all of their institutions, the conference organizers and the conference sponsors, had all received lawsuit threats from the SDMI, the RIAA, and also Verance (the makers of one of the wicked lousy watermarking systems they cracked).
Declan's article (at http://wired.com/news/politics/0,1283,43353,00.htm l) also contains the interesting assertion that the Naval Research Laboratory (a cosponsor of the conference) had ordered the conference chair to ban the paper last week, but the program commitee refused.
It's not actually that simple; if you read the threat letter from the SDMI people it mainly turns on a contract issue about the clickthrough agreement that was protecting the challenge files, not the DMCA circumvention device stuff.
At the little news conference, Felten said he honestly couldn't remember whether he actually clicked through the agreement personally or not, but pointed out that there would have been no need to since the material was widely available elsewhere.
One interesting thing Felten said in the little impromptu news conference when his paper was supposed to be read was when Declan McCullagh asked him if Princeton was not willing to back him up. Felten responded that Princeton had been very supportive of him and the other authors, but that there were lots of other people involved with the paper, and he wanted to go forward in a way that exposed fewer of them and their institutions. I took this as a hint that the real problem is that one of his coauthors is from Xerox and that a corporation is less willing than a university to expose itself to a lawsuit in the name of academic freedom.
It was originally invented as part of Karn's key exchange protocol, yes, though the general idea of having a handshake without the server having to keep state (by encoding the state as a "cookie" sent to the client and then verifying and reconstituting the state from the cookie when the client sends it back) is useful for non-encrypted TCP as well (but you need to use cryptographic methods to verify the integrity of the cookie of course). Like I said it's in the Linux kernel.
The whole reason you don't want to use an array like you describe is that it requires that the server dedicate resources -- an array entry -- to a connection before the client's location is verified by the three-way handshake. This is exactly why syn floods work, by filling up the queue with bogus connection requests that never complete.
Dan Bernstein also has an old old web page in which he describes this idea in the context of IPV4:
This idea -- invented by Phil Karn for IPV6 and known as Photuris cookies there -- was long ago implemented in IPV4 to prevent SYN floods. It's descried in several RFCs and it's available in the Linux Kernel as the "SYN cookies" option.
First, to repeat myself, watermarking is basically a tracking technique, not an access control technique. One can copy a watermarked file as much as one wants.
Actually, this is not the role that watermarking is intended to play in SDMI, at least not initially. It really is intended to play a part in access control, not tracking. The idea is that songs on all new CDs will have a generic, identical watermark saying basically "this music is copyrighted" and then SDMI-compliant mp3 players and stuff are supposed to find this watermark and refuse to play the file unless it comes packaged in one of their goofy little secure formats that implements access control and copy prevention, e.g. are keyed to the particular player or whatever. SDMI-compliant mp3 players are supposed to refuse to play watermarked music packaged in a regular unprotected mp3 file without access control.
So, actually, watermarking in SDMI is part of an access control scheme and not a scheme for tracking individual copies. Obviously this is totally hopeless access control scheme since you just need an mp3 player that doesn't implement their broken blocking mechanisms, but it's an access control scheme nonetheless.
They could patent anything they want, but only patenting their specific code or methodology would stand up in Court.
I don't know whether their patents would stand up in court. Neither -- OBVIOUSLY -- do you. The point is that the question of whether LAME will get harrassed by Fraunhoffer in the future is not settled by them expunging the ISO sources, since Fraunhoffer/Thomson claim to have patents covering any mp3 encoder. Whatever their merits, their claims are not (as you seem to think) grounded in their implementation. See
http://www.mp3.com/news/095.html
for an example.
As for "their specific methodology," well of course LAME uses their specific methodology -- it was created by slowly rewriting the ISO sources, bit by bit. It works the same.
MP3 is a publicly-usable standard, just like MPEG-1, PNG, JPEG, etc. It's not like GIF, which is patented under increasingly stupid terms.
It's a public standard. As for publicly usable, it's covered by many patents, just like -- well -- GIF. Here's one
A digital encoding process... in which scanned values of the acoustical signal are transformed... into a sequence of second scanned values, which reproduce the spectral composition of the acoustical signal
i.e., essentially any audio compression in frequency domain. Since the mp3 format just consists of a bunch of quantized frequency information it's hard to imagine what you claim -- something which produces mp3 files that isn't covered by this patent.
But the interesting thing about MPEG-3 (MP3)
mp3 is short for MPEG-1, layer III. There is no MPEG 3.
Thus, there are many ways to encode a file to the MP3 standard, not just one standard implementation, but unlike AVI you don't need the codec installed for the specific encoder--a standards-compliant MP3 decoder will decode an MP3 encoded with any of the codecs.
What's your point here? AVI is unlike mp3 in that it (like Quicktime) is just a wrapper format for multimedia files. But the particular compression algorithms it supports (including -- gasp! -- MPEG-1 layer 3) are available in many implementations and any standards-compliant decoder for some format will decode any AVI encoded to that compression format. There are also lots of implementations of GIF compressors. How does any of this support your confused ideas?
The problem is that the Fraunhoffer reference implementations were being widely used by people, without licensing fees, in many products, and Fraunhofer wanted money for its implementation.
No, that wasn't the problem at all. The problem Fraunhoffer saw had nothing to do with any particular implentation, since they claim to have patents covering any implementation. See the mp3.com URL I mentioned earlier.
That codec arguably produces better-sounding results than others, like BLADE
Christ. I'll try to use small words, okay? BLADE is a lightly modified version of the ISO sources, which is to say -- surprise! -- the Fraunhoffer reference implementation. Hard to see how it could sound better. Perhaps you're thinking of the Fraunhoffer Radium codec, their private, closed-source implementation that they license out to software vendors.
In any event, I suspect that there'll be some way to plug any codec you want into LAME, and the Fraunhoffer codec is easily obtained from the Net.
Have you ever used LAME? Do you know what it is? It's just a codec. If you plugged another codec into LAME there'd be nothing left. That's like saying I suspect there'll be some way to plug any word processor you want into Word Perfect, so you can always use MS Word.
Fraunhoffer shut down previous mp3 encoders based to patents which ostensibly apply to ANY mp3 encoder, regardless of implementation. Just the fact that the ISO sources are expunged doesn't mean LAME is in the clear.
Well, sure. This is exactly why the allegations that Netscape management pressured mozilla.org into concealing a useful feature of their software are disturbing.
I hope this is true, however there is something a bit fishy about all this -- especially considering the Netscape business model. People make it sound like this feature is just turned off by default and it's easy to turn it back on, but in fact it's not just turned off but HIDDEN by default and you need to enter a magic string into a config file somewhere in order to reveal it. There is a difference between disabling something and removing all traces of it from the UI.
Okay, just in case anybody's still confused, here's what DiVX really is: Microsoft includes a codec for MPEG 4 video compression with recent releases of Windows Media Player. I don't know how standards compliant this codec is, nor if the standard is really finalized anyway.
The problem with this codec from the perspective of your average Windows user is that it's locked to prevent it being used with even vaguely open file formats such as avi. Like the Windows Media Audio codec, you're supposed to be able to use it only with one of Microsoft's new closed file formats -- asf? -- which enforce "rights management" -- which makes it difficult to use the codecs to recompress DVDs and distribute them all over the world on GNUTELLA, which is what everyone wants to do with them.
DiVX is just a patch to the binary DLLs that relaxes this restriction, so you can create and play back avis using MPEG 4 compression. It also comes packaged with a pirated version of the fraunhoffer mp3 codec for audio, and a similarly cracked WMA audio codec in recent versions as well.
Regarding porting, it would probably be semi-easy to "port" DiVX to i386 Linux using Wine to interface with the DLL. AFAIK, Microsoft has a fairly standardized API for pluggable video codecs, and DiVX complies to this. I think a very useful and realistic project would be writing the glue to call these codecs from a linux app (Winelib has the ability to link in DLLs I think). This would give anyone using i386 Linux easy access to playback/encoding of all of the video codecs that come with Windows now and in the future, within xanim or whatever. And since the best Windows video compression program for DVD piracy -- FlaskMPEG -- is already GPL'd except for the codecs it has to link in, it would be easy to port to Linux as well. Admittedly we'd be stuck with binary codec libraries, but as all these codecs are heavily proprietary and patent-encumbered it's probably the best we can do anyway. Obviously this binary-recycling approach won't work for the contest of porting to the Mac, but frankly I think that's pretty hopeless anyway.
Make a small MP3, in it just say something like "Metallica, Leave Napster Alone!"
Now copy this MP3 over and over with different names, such as the ones below:
Metallica Sucks.mp3 [...]
The lawyers searching for people trading metallica MP3s will see that and if everyone does it, they wont be able to track down the real MP3s from ours
And what about non-lawyer Napster users who just want to download the music? How will they find it? This suggestion, just like the asinine movement to widely distribute a fake "DeCSS" program to confuse the MPAA is totally wrongheaded: both just do the censorship work of the "intellectual property" fascists for them more effectively than they could ever do by themselves, by making their "property" impossible to find amidst all the crap.
If you agree with Metallica's position and your goal is to make Napster useless, this kind of spam bombing is a great strategy. I'm sure nothing would make them happier. In fact, this very technique has actually been tried in other contexts by everyone's favorite original copyright Nazis, the Scientologists.
You people need to get a clue. Unlike the DXR2, the DXR3/Hollywood+ cards do CSS in software, which is supposedly one reason Creative/Sigma haven't released an open source driver for them yet.
So: (A) these drivers depend on the css-auth stuff from LIVID to unlock the disks and feed a *decrypted* MPEG stream to the card, (B) there is hence nothing more or new here for the MPAA to get mad about, and (C) (regarding another clueless comment farther down) these drivers do NOT demonstrate the availability of "legitimate" alternatives to the LIVID unauthorized CSS software since they depend on it.
Aha. Actually the quotes do come via the RIAA: More than a week ago they posted a FAQ on their lawsuit against napster, containing some of the same quotes from the same people.
Exactly! One of the things I found so infuriating about this article was that, for a story that purported to be about what ARTISTS think of napster, it mostly quoted artists' MANAGERS -- speaking patronizingly, and implicitly and sometimes explicitly admitting that mp3 hasn't affected the artists' lives one bit yet.
The -- deliberate -- problem with all these quotes is that, with all their foamy blather about "theft" and "artists' rights" and "property," they totally obscure the fact that copyright is not some God-given basic right, but rather a convenient, pragmatic, and somewhat unintuitive legal fiction that was created relatively recently to serve a particular purpose -- the purpose of funding the creation of art and knowledge.
Before copyright was invented, art and knowledge were created just fine, funded in many other ways such as by private patrons, governments, sales of performance tickets, and the tuition of students. Shakespeare had some problems with bootleggers, but he still made a living and created prolifically with zero copyright protection. Even today, there are many other models for funding creation: fine arts are mostly supported by the government and private charity; most basic science (and much open source software development) takes place in universities funded by government grants, private donations and the tuition of students. Even the blank-media taxes in the US and Canada (flawed though they are) represent a shift to a different payment model, one in which copyright is irrelevant but consumers pay indirectly into a common pot which is redistributed to artists. The point is not whether these models are better -- though they're all at least workable, unlike copyright. The point is that "intellectual property" rhetoric obscures the only real issue, which is how can society fund artists. And the answer need not automatically be the same way we do today.
All this talk of the audio home recording act is just an attempt to make a big loss from the RIAA's perspective sound like a win. The audio home recording act places big restrictions on the kind of copying you can do with certain kinds of components -- stereo system CD recorders, etc. -- These are required to pay royalties on blank media and incorporate "serial copy managment."
The act has NOTHING to say about what you can copy with computers; it specifically EXEMPTS them from the restrictions of the act. What's left covering computers is the traditional copyright act with traditional fair exemptions, which have been interpreted by the courts (e.g. in the RIAA vs. Diamond Rio case) as allowing quite extensive copying of music you own.
It's totally disigenuous of the RIAA to say that since the Audio Home Recording Act doesn't cover computers, then all copying of music with computers is illegal. To the contrary: since the Audio Home Recording Act doesn't cover computers, copying of music with computers is much less restricted by law than copying it in other ways.
As usual, the Slashdot summary of this story had no connection with reality. The story itself made no attempt to rank the operating systems whatsoever; it in fact seemed to be incredibly wishy-washy and careful in saying that every one of the systems had its good points. Red Hat was praised as the "most flexible" in the intro, and a good value in the conclusion.
Meanwhile, attached to the article are the actual rankings at:
http://www.nwfusion.com/reviews/2000/0124revs.ht ml
> These folks have the law on their side. Like it > or not the DeCSS software publishes a trade > secret, the CSS encryption algorithm. This is > illegal. Plain and simple.... it's just plain > against the law to publish someone else's trade > secret without their express permission.
You, sir, are completely wrong. The argument you have just made is the one that has so far FAILED in federal court in California. The argument today in New York had nothing at all to do with trade secrets -- it was a copyright action. And it's not always or even usually illegal to publish a trade secret -- in fact, if you try to keep something a trade secret rather than secure proper patent or copyright protection for it, then it's essentially your responsibility, not the law's, to keep it a secret. If the secret escapes by legitimate means -- such as reverse engineering in Norway, a country where this is explicitly legal -- then it's your problem and you should have done a better job keeping your secret. This is the whole reason we have patents -- to convince people to disclose details of their ideas IN EXCHANGE FOR legal protection of them. If you instead want to keep it a secret, good luck, because the law affords you very limited protection.
You can read much more about how trade secrets apply to this case in the filings from the California case available at http://www.eff.org. But in the meantime you can rest quietly assured that you have absolutely no grasp of the facts or the law.
The only reason they exist, IIRC, is because movies may have different copyrights in different areas of the world.
Not true. Actually region coding exists due to the fact that movie studios want to independently control the timing of releases in different markets. They don't want American Matrix DVDs available in England before it's finished the first theatrical run there, or they've sold the pay-per-view rights, or whatever. With VCRs this used to be taken care of by the serendipitous (from their perspective) incompatibility between PAL and NTSC; now that that technical brokenness has been fixed, they have built such brokenness into the system deliberately.
Slashdot Mirror
Kazaa is a decentralized filesharing network with a centralized login mechanism. But authentication is really enforced only in the client. As insurance against being shut down by a lawsuit, if the login servers disappear, the clients are supposed to just forget about authentication and join the network anyway, by trying to connect to any of a series of hardcoded supernodes. This list is also supposed to be refreshed whenever you connect to the network.
.kza directory every time I run kazaa or it crashes on restart; so I surely don't have a refreshed list saved.)
My guess is that the login servers are down and the linux binary's supernode list is out of date. (And I don't know about you, but I have to wipe out the whole
I further imagine that by editing in the address of a working supernode into the binary or config file somewhere, you can get the linux version to connect.
Are Windows people connecting okay?
> The main problem is if the courts go after the authentication servers. This isn't happening yet.
Actually, I have read (in the leaked RIAA memo on fasttrack) that if the authentication servers are unreachable, the software will connect to the network without authenticting. It comes with a long list of peers to try connecting to, which whenever it connects. If this is true, and kazaa etc. vanish with their servers, the software should keep working.
On the other hand, I have read (in the New York Times article on video trading yesterday) that FastTrack have the ability to shut down the software remotely. And this would seem to be borne out by the time they forced everyone to upgrade to version 1.33. (Though maybe this was accomplished in the authentication process.)
Well, this should be bad news for Redhat, since (a) it costs half as much, and (b) the Ximian client is much nicer than redhat's abominable little mess.
But on the other hand, Ximian does a terrible job of keeping up with redhat advisories; for instance last week's glibc buffer overflow finally showed up in red carpet today. What's the point of paying Ximian for an upgrade service if you're still going to have to go trawling around ftp sites (or subscribe to Redhat's prompter service) in order to make sure you're actually up to date on serious bug or security fixes in your operating system?
It's good technology, but it's a very, very simple idea and a straightforward extension of basic antialiasing; it's only the branding exercise that makes you think Microsoft spent any time or money on it. There's also a reason I suspect that it's buried in XFree86 and not trumpeted around much: Microsoft has it patented. The patent is completely spurious, of course, as subpixel sampling has been around since the Apple II era at least (NYTimes had a good article about just this when the patent was granted), but one would presume the Xfree folks don't want to go to court over it.
Also, as another poster pointed out, there's several odds and ends that go under the rubric ClearType, (though the main one having to do with fonts on LCD screens, which was the original topic of this thread, is subpixel sampling). And there's also several other reasons fonts look better in Windows than Linux. In particular, the fonts themselves are much, much better, and the font rendering engine is better as well. But yes, basically the same infrastructure *is* buried in XFree86, it's just not tweaked as nicely yet.
Actually, Xft has the little-known capability of doing subpixel sampling on LCD screens (which is what ClearType is).
To enable it you just have to set the X resource "Xft.rgba: rgb" though depending on the orientation of your LCD panel you may have to use "bgr" or "vrgb" or "vbgr" in place of "rgb".
Alternatively I think you can put
match edit rgba=bgr; (or rgb, or whatever)
in /etc/X11/Xftconfig
Oh yeah, and another interesting tidbit was that the leaked threat letter from the SDMI to him wasn't the only one -- he said that all of the authors, all of their institutions, the conference organizers and the conference sponsors, had all received lawsuit threats from the SDMI, the RIAA, and also Verance (the makers of one of the wicked lousy watermarking systems they cracked).
m l) also contains the interesting assertion that the Naval Research Laboratory (a cosponsor of the conference) had ordered the conference chair to ban the paper last week, but the program commitee refused.
Declan's article (at http://wired.com/news/politics/0,1283,43353,00.ht
It's not actually that simple; if you read the threat letter from the SDMI people it mainly turns on a contract issue about the clickthrough agreement that was protecting the challenge files, not the DMCA circumvention device stuff.
At the little news conference, Felten said he honestly couldn't remember whether he actually clicked through the agreement personally or not, but pointed out that there would have been no need to since the material was widely available elsewhere.
One interesting thing Felten said in the little impromptu news conference when his paper was supposed to be read was when Declan McCullagh asked him if Princeton was not willing to back him up. Felten responded that Princeton had been very supportive of him and the other authors, but that there were lots of other people involved with the paper, and he wanted to go forward in a way that exposed fewer of them and their institutions. I took this as a hint that the real problem is that one of his coauthors is from Xerox and that a corporation is less willing than a university to expose itself to a lawsuit in the name of academic freedom.
The whole reason you don't want to use an array like you describe is that it requires that the server dedicate resources -- an array entry -- to a connection before the client's location is verified by the three-way handshake. This is exactly why syn floods work, by filling up the queue with bogus connection requests that never complete.
Dan Bernstein also has an old old web page in which he describes this idea in the context of IPV4:
http://cr.yp.to/syncookies.html
This idea -- invented by Phil Karn for IPV6 and known as Photuris cookies there -- was long ago implemented in IPV4 to prevent SYN floods. It's descried in several RFCs and it's available in the Linux Kernel as the "SYN cookies" option.
Actually, this is not the role that watermarking is intended to play in SDMI, at least not initially. It really is intended to play a part in access control, not tracking. The idea is that songs on all new CDs will have a generic, identical watermark saying basically "this music is copyrighted" and then SDMI-compliant mp3 players and stuff are supposed to find this watermark and refuse to play the file unless it comes packaged in one of their goofy little secure formats that implements access control and copy prevention, e.g. are keyed to the particular player or whatever. SDMI-compliant mp3 players are supposed to refuse to play watermarked music packaged in a regular unprotected mp3 file without access control.
So, actually, watermarking in SDMI is part of an access control scheme and not a scheme for tracking individual copies. Obviously this is totally hopeless access control scheme since you just need an mp3 player that doesn't implement their broken blocking mechanisms, but it's an access control scheme nonetheless.
WMA audio with the current windows media player works fine using recent builds of WINE. Try it out.
Sir,
0 __
... in which scanned values of the acoustical signal are transformed ... into a sequence of second scanned values, which reproduce the spectral composition of the acoustical signal
How art thou full of shit? Let me count the ways.
They could patent anything they want, but only patenting their specific code or methodology would stand up in Court.
I don't know whether their patents would stand up in court. Neither -- OBVIOUSLY -- do you. The point is that the question of whether LAME will get harrassed by Fraunhoffer in the future is not settled by them expunging the ISO sources, since Fraunhoffer/Thomson claim to have patents covering any mp3 encoder. Whatever their merits, their claims are not (as you seem to think) grounded in their implementation. See
http://www.mp3.com/news/095.html
for an example.
As for "their specific methodology," well of course LAME uses their specific methodology -- it was created by slowly rewriting the ISO sources, bit by bit. It works the same.
MP3 is a publicly-usable standard, just like MPEG-1, PNG, JPEG, etc. It's not like GIF, which is patented under increasingly stupid terms.
It's a public standard. As for publicly usable, it's covered by many patents, just like -- well -- GIF. Here's one
http://www.patents.ibm.com/details?pn=US0557943
This covers:
A digital encoding process
i.e., essentially any audio compression in frequency domain. Since the mp3 format just consists of a bunch of quantized frequency information it's hard to imagine what you claim -- something which produces mp3 files that isn't covered by this patent.
But the interesting thing about MPEG-3 (MP3)
mp3 is short for MPEG-1, layer III. There is no MPEG 3.
Thus, there are many ways to encode a file to the MP3 standard, not just one standard implementation, but unlike AVI you don't need the codec installed for the specific encoder--a standards-compliant MP3 decoder will decode an MP3 encoded with any of the codecs.
What's your point here? AVI is unlike mp3 in that it (like Quicktime) is just a wrapper format for multimedia files. But the particular compression algorithms it supports (including -- gasp! -- MPEG-1 layer 3) are available in many implementations and any standards-compliant decoder for some format will decode any AVI encoded to that compression format. There are also lots of implementations of GIF compressors. How does any of this support your confused ideas?
The problem is that the Fraunhoffer reference implementations were being widely used by people, without licensing fees, in many products, and Fraunhofer wanted money for its implementation.
No, that wasn't the problem at all. The problem Fraunhoffer saw had nothing to do with any particular implentation, since they claim to have patents covering any implementation. See the mp3.com URL I mentioned earlier.
That codec arguably produces better-sounding results than others, like BLADE
Christ. I'll try to use small words, okay? BLADE is a lightly modified version of the ISO sources, which is to say -- surprise! -- the Fraunhoffer reference implementation. Hard to see how it could sound better. Perhaps you're thinking of the Fraunhoffer Radium codec, their private, closed-source implementation that they license out to software vendors.
In any event, I suspect that there'll be some way to plug any codec you want into LAME, and the Fraunhoffer codec is easily obtained from the Net.
Have you ever used LAME? Do you know what it is? It's just a codec. If you plugged another codec into LAME there'd be nothing left. That's like saying I suspect there'll be some way to plug any word processor you want into Word Perfect, so you can always use MS Word.
Think, boy, think.
Fraunhoffer shut down previous mp3 encoders based to patents which ostensibly apply to ANY mp3 encoder, regardless of implementation. Just the fact that the ISO sources are expunged doesn't mean LAME is in the clear.
> mozilla.org != Netscape.
Well, sure. This is exactly why the allegations that Netscape management pressured mozilla.org into concealing a useful feature of their software are disturbing.
I hope this is true, however there is something a bit fishy about all this -- especially considering the Netscape business model. People make it sound like this feature is just turned off by default and it's easy to turn it back on, but in fact it's not just turned off but HIDDEN by default and you need to enter a magic string into a config file somewhere in order to reveal it. There is a difference between disabling something and removing all traces of it from the UI.
But, like I said, I hope you're right.
Okay, just in case anybody's still confused, here's what DiVX really is: Microsoft includes a codec for MPEG 4 video compression with recent releases of Windows Media Player. I don't know how standards compliant this codec is, nor if the standard is really finalized anyway.
The problem with this codec from the perspective of your average Windows user is that it's locked to prevent it being used with even vaguely open file formats such as avi. Like the Windows Media Audio codec, you're supposed to be able to use it only with one of Microsoft's new closed file formats -- asf? -- which enforce "rights management" -- which makes it difficult to use the codecs to recompress DVDs and distribute them all over the world on GNUTELLA, which is what everyone wants to do with them.
DiVX is just a patch to the binary DLLs that relaxes this restriction, so you can create and play back avis using MPEG 4 compression. It also comes packaged with a pirated version of the fraunhoffer mp3 codec for audio, and a similarly cracked WMA audio codec in recent versions as well.
Regarding porting, it would probably be semi-easy to "port" DiVX to i386 Linux using Wine to interface with the DLL. AFAIK, Microsoft has a fairly standardized API for pluggable video codecs, and DiVX complies to this. I think a very useful and realistic project would be writing the glue to call these codecs from a linux app (Winelib has the ability to link in DLLs I think). This would give anyone using i386 Linux easy access to playback/encoding of all of the video codecs that come with Windows now and in the future, within xanim or whatever. And since the best Windows video compression program for DVD piracy -- FlaskMPEG -- is already GPL'd except for the codecs it has to link in, it would be easy to port to Linux as well. Admittedly we'd be stuck with binary codec libraries, but as all these codecs are heavily proprietary and patent-encumbered it's probably the best we can do anyway. Obviously this binary-recycling approach won't work for the contest of porting to the Mac, but frankly I think that's pretty hopeless anyway.
Make a point...
Make a small MP3, in it just say something like "Metallica, Leave Napster Alone!"
Now copy this MP3 over and over with different names, such as the ones below:
Metallica Sucks.mp3 [...]
The lawyers searching for people trading metallica MP3s will see that and if everyone does it, they wont be able to track down the real MP3s from ours
And what about non-lawyer Napster users who just want to download the music? How will they find it? This suggestion, just like the asinine movement to widely distribute a fake "DeCSS" program to confuse the MPAA is totally wrongheaded: both just do the censorship work of the "intellectual property" fascists for them more effectively than they could ever do by themselves, by making their "property" impossible to find amidst all the crap.
If you agree with Metallica's position and your goal is to make Napster useless, this kind of spam bombing is a great strategy. I'm sure nothing would make them happier. In fact, this very technique has actually been tried in other contexts by everyone's favorite original copyright Nazis, the Scientologists.
You people need to get a clue. Unlike the DXR2, the DXR3/Hollywood+ cards do CSS in software, which is supposedly one reason Creative/Sigma haven't released an open source driver for them yet.
So: (A) these drivers depend on the css-auth stuff from LIVID to unlock the disks and feed a *decrypted* MPEG stream to the card, (B) there is hence nothing more or new here for the MPAA to get mad about, and (C) (regarding another clueless comment farther down) these drivers do NOT demonstrate the availability of "legitimate" alternatives to the LIVID unauthorized CSS software since they depend on it.
Aha. Actually the quotes do come via the RIAA: More than a week ago they posted a FAQ on their lawsuit against napster, containing some of the same quotes from the same people.
And, of course, the quotes seem to be practically right out of the RIAA prewritten suggested quotes for artists playbook, very fishy.
The -- deliberate -- problem with all these quotes is that, with all their foamy blather about "theft" and "artists' rights" and "property," they totally obscure the fact that copyright is not some God-given basic right, but rather a convenient, pragmatic, and somewhat unintuitive legal fiction that was created relatively recently to serve a particular purpose -- the purpose of funding the creation of art and knowledge.
Before copyright was invented, art and knowledge were created just fine, funded in many other ways such as by private patrons, governments, sales of performance tickets, and the tuition of students. Shakespeare had some problems with bootleggers, but he still made a living and created prolifically with zero copyright protection. Even today, there are many other models for funding creation: fine arts are mostly supported by the government and private charity; most basic science (and much open source software development) takes place in universities funded by government grants, private donations and the tuition of students. Even the blank-media taxes in the US and Canada (flawed though they are) represent a shift to a different payment model, one in which copyright is irrelevant but consumers pay indirectly into a common pot which is redistributed to artists. The point is not whether these models are better -- though they're all at least workable, unlike copyright. The point is that "intellectual property" rhetoric obscures the only real issue, which is how can society fund artists. And the answer need not automatically be the same way we do today.
All this talk of the audio home recording act is just an attempt to make a big loss from the RIAA's perspective sound like a win. The audio home recording act places big restrictions on the kind of copying you can do with certain kinds of components -- stereo system CD recorders, etc. -- These are required to pay royalties on blank media and incorporate "serial copy managment."
The act has NOTHING to say about what you can copy with computers; it specifically EXEMPTS them from the restrictions of the act. What's left covering computers is the traditional copyright act with traditional fair exemptions, which have been interpreted by the courts (e.g. in the RIAA vs. Diamond Rio case) as allowing quite extensive copying of music you own.
It's totally disigenuous of the RIAA to say that since the Audio Home Recording Act doesn't cover computers, then all copying of music with computers is illegal. To the contrary: since the Audio Home Recording Act doesn't cover computers, copying of music with computers is much less restricted by law than copying it in other ways.
As usual, the Slashdot summary of this story had no connection with reality. The story itself made no attempt to rank the operating systems whatsoever; it in fact seemed to be incredibly wishy-washy and careful in saying that every one of the systems had its good points. Red Hat was praised as the "most flexible" in the intro, and a good value in the conclusion.
t ml
Meanwhile, attached to the article are the actual rankings at:
http://www.nwfusion.com/reviews/2000/0124revs.h
... where SCO comes in last.
> These folks have the law on their side. Like it ... it's just plain
> or not the DeCSS software publishes a trade
> secret, the CSS encryption algorithm. This is
> illegal. Plain and simple.
> against the law to publish someone else's trade
> secret without their express permission.
You, sir, are completely wrong. The argument you have just made is the one that has so far FAILED in federal court in California. The argument today in New York had nothing at all to do with trade secrets -- it was a copyright action. And it's not always or even usually illegal to publish a trade secret -- in fact, if you try to keep something a trade secret rather than secure proper patent or copyright protection for it, then it's essentially your responsibility, not the law's, to keep it a secret. If the secret escapes by legitimate means -- such as reverse engineering in Norway, a country where this is explicitly legal -- then it's your problem and you should have done a better job keeping your secret. This is the whole reason we have patents -- to convince people to disclose details of their ideas IN EXCHANGE FOR legal protection of them. If you instead want to keep it a secret, good luck, because the law affords you very limited protection.
You can read much more about how trade secrets apply to this case in the filings from the California case available at http://www.eff.org. But in the meantime you can rest quietly assured that you have absolutely no grasp of the facts or the law.
The only reason they exist, IIRC, is because movies may have different copyrights in different areas of the world.
Not true. Actually region coding exists due to the fact that movie studios want to independently control the timing of releases in different markets. They don't want American Matrix DVDs available in England before it's finished the first theatrical run there, or they've sold the pay-per-view rights, or whatever. With VCRs this used to be taken care of by the serendipitous (from their perspective) incompatibility between PAL and NTSC; now that that technical brokenness has been fixed, they have built such brokenness into the system deliberately.