I didn't say they lose the right of future enforcement, or that the patent becomes invalid. There is just no penalty for the old violations. You can halt future enforcement, or amiable agree to some monies to be paid for the old use, but you can't force damages, if you sat on your rights, delayed unnecessarily, and in doing so caused harm to the infringer.
Go search the web for defense of laches, OK? Then come back and argue.
Confusion with the terminology here. A submarine patent is one where the issuance has been delayed. This patent was issued in a timely manner. It isn't a submarine patent. While submarine patents are unethical, it is true that they are (were) legal. You can not enforce a submarine patent because it hasn't even been issued, so you couldn't enforce it if you wanted to (well, if you stopped purposely slowing down issuance...).
What has happened here is that an issued patent has lied dormant, and now is being enforced. There is reason to invalidate enforcement. Lots of other posts have more detail, but it's called the defence of laches. If you know of (or, being reasonably diligent, should have known of) infringement, you delay enforcement (standard is 6 years, varies by situation), and the infringer is harmed by the unnecesary delay, then you forfeit enforcement. The patent is still valid, and can be applied to future violations (as far as I understand, the violator has to license or stop infringing, but isn't liable for the past).
M-JPEG certainly is more relevent. However, I'm pretty sure that depending on how you structure the claims, you can get away with murder as far as broadness.
The claims are very vague as far as what sorts of transforms you do, and only get specific when you reach the lossless coder. Just about any image processing would fit into the transform claims (even 4:2:2 YUV, or other equal primative methods). Also, they are very broad about how you quantize (actually, more generically throw data away), allowing several methods, including (but not limited to) comparison to older frames.
Finally, they spell out the details of a RLE-ish huffman-ish lossless coding, which is quite similar to JPEG's (although IMHO subtly different).
But if it get's thrown out because the patent does speak extensively on video, I won't argue. I just think that a clever lawyer could make it *seem* valid dispite the video aspect, and that the primary technical objection to validity isn't the video but that their lossless coder isn't really the same, but just similar. (That and that their lossless coder isn't non-obvious, unique, or especially usefull, but hey, since when did that stop the USPTO from issuance?)
Lossless JPEG is a very unusual beast, and didn't get finalized until much later than lossy JPEG. It works according to much different principles.
Lossy JPEG transform the data such that you can easily throw away unimportant parts, and then runs a lossless coder to shrink it. By removing the unimportant parts, you make lossless coding step very efficient. Lossless JPEG tries to predict what the picture will be based off of earlier pixels. Since the predictions are usually close, you can then use fairly few bits to store the difference between the prediction and actuallity, thereby saving space, although not nearly as much as lossy.
The claims verses standard JPEG are shaky. I'd think that the claims verses lossless are much shakier.
Either way, looking for prior art in the form of old JPEGs is a waste of time. The publication of the spec itself would constitute prior art, except that it isn't old enough. And prior to the spec, there were no JPEGs. So no old JPEGs are old enough.
If you do want a replacement for lossless JPEG, JPEG2000 is quite good. In lossy mode it doesn't have nearly the problems with artifacting that JPEG does. Rather than get blocky, images tend to become progressively blurier. It also has a full lossless mode that gets very good compression ratios, and unlike lossless JPEG, is sane.
Am I the only one who thinks the ISO should stand up and fight the good fight?
It isn't in any way ISO's job to fight patents.
The JPEG people (remember, JPEG is the Joint Photograpphic Experts Group, not just a compression standard) are the ones who will fight the good fight--them and their members. JPEG itself can only do inexpensive things, and probably couldn't force a lawsuit even if they had the money. What they can do is organize their members (who do have money) into working together in the pursuit of evidence that the patent claims are invalid. which is what they are doing.
What about patents not applying if the implementation is open source and not-for-profit?
There is a relatively new area of law, equitable estopple (spelling? eh, IANAL, so don't need to write it), which covers this. In this situation it more or less says that given that the owners of the patent knew (or should have known) that their tech was being incorporated into a free standard, they should have spoken up then, and can't now. Letting someone incorporate your IP into a standard, and letting them believe that they hadn't, is a no-no. Refusing to let them use it is OK, but you have to speak up quickly.
Additionally, there is the defense of laches, which more generally covers not enforcing a patent for a long time. If, given you had been reasonably diligent, you would have been aware of infringement (or you actually were aware), and you do nothing for a long time (6 years is the standard, more or less by situation), then you forfeit your enforcement rights for past infringement. A quote I saw on it went like "Those who sleep on their rights can't expect to exercise them."
They're claiming that the lossless table-based huffman coding that JPEG does *after* the DCT and quantization steps is covered by their lossless table-based huffman/RLE coding.
Not that this makes their claim valid--there is likely prior art for such use of Huffman codes, and the original patent holder was a member of JPEG in the late 80's, and therefore obligated to mention their patent then.
Please stop saying that the patent has nothing to do with JPEG. If rather than reading the crappy html claims, you read the full TIFF version, it becomes clear that their patent is somewhat relevant to JPEG. The more interesting stuff in the patent isn't applicable to JPEG, but the lossless transform they use is.
The jpeg.org page seems to indicate that the patent only affects the baseline implementation of JPEG. If this is true, then it should be possible to write a new baseline implementation that doesn't infringe on the patent.
Uhh, baseline is already supposed to be the minimal implementation. Anything that implements JPEG at all has to implement at least the same features as baseline. The only ways to redo baseline to remove the parts Forgent feels it owns would be to move to arithmatic coding. Arithmatic coding is part of the JPEG spec, but not baseline, because there's more patents surrounding arithmatic coding than slimy lawyers to sue over them.
You could change the spec to move to a totally new type of coding, but then it wouldn't be JPEG anymore.
The way these standards work (or are supposed to) is that everybody who owns IP related to them agrees to license without-fee for implementers of the "baseline". They (usually) also agree to licence on RAND (reasonable and non-descriminatory) terms any nifty extras (optional features not included in baseline).
The one catch is that it's only free if you follow the standard. Using JPEG2000 technology in something that isn't JPEG2000 can get you in trouble, because the free license is only for ppl. who follow the standard.
You can purchase a copy of the standard directly from ISO, or from various local standards bodies. In the US, that would be ANSI. You can buy from ANSI here. They recently dropped their price (it used to run ~$140), probably because of price competition from ISO and Standards Australia (note that prices from ISO and SA are *not* listed in USD, an that the Australian price includes a 10% tax that will be waved for foreigners). And electronic copy of a standards document is about as fungable as you can get.
Other than the requirement that you stick to the standard, it's totally free (barring submarine patents). You don't even have to notify anyone that you're implementing it. And the JPEG people have worked really hard (even harder than with the original) to ensure that J2K is unencumbered, so even the threat of submarine patents is small.
The reason they do this is to discriminate between people who just want a CD drive, and the person who wants the best possible. (More technically, they want to charge people with a low elasticity of demand more, and still sell to people witha high elasticity of demand).
If they produced just 1 model drive, then they can reasonably expect to sell it at 1 price. Let's suppose they can sell it for $50. Now, there are some people who must have the fastest drive, damn the price. These people will (obviously), buy it for $50. There are also some people who are willing to pay $50 for the drive, but not necessarily too much more. They will also buy. There is a 3rd class of people who would like a drive, but don't want to buy at $50. They don't buy.
Now lets introduce another, slower model. We can raise the price of the fast drive, say to $75. The performance freaks will all still fork out for it. If we price the slow drive at say, $40, we will still sell a drive to all the people who bought at $50 (but don't want to pay $75). We will also sell a bunch of drives to people who never did want to pay $50, but will fork out $40.
The end result is that we can extract more money out of the high end ($75 drive buyers) and the low end (people who buy at $40 but not at $50). We lose out some in the middle (people who are now paying $40 but would have paid $50), but if you balance the prices right, you can end up ahead.
Intel did the same thing with the 486SX. The earlier manufactured SXs were just the DX with the floating point co-processor disabled. They were actually more expensive to make, but they sold for less. Some people had to/really wanted to buy the DX, and paid the high price. Intel gained a large low-end market with the cheaper SX chip, and overall ended up ahead. Even the speed-ratings of their processors was price-discrimination. Intel's fabrication technology turned out very few parts that couldn't pass the high-clockrate tests. But if they sold them as high-clockrate parts, they'd glut the highend market, and drive the prices down. By labelling them slower, they can still charge a premium for the faster parts, while maintaining low-end marketshare.
Airplane tickets--same deal. It doesn't cost the airline more to sell you a ticket that doesn't include a weekend stay. They just want to charge the business traveller more. Business travellers have a low elasticity of demand -- they *must* fly. They are willing to pay a lot more. The tourist has a high elasticity of demand -- flying is totally optional. By including a weekend stay requirement for cheap fares, they can get more money overall.
Student/senior discounts for movie tickets. Cheaper meals during lunch than dinner at restaraunts. It's a very common practice in business.
All the AV vendors I know of have strict policies about their employees: they can never have written a virus. Ever. Even if it was harmless, or never released into the wild.
The liability it would open them up to is way too high for it to be worth it. They'd rather pass on hiring an otherwise perfect candidate than expose themselves to that sort of legal risk.
Now, that's not to say that some Norton employees haven't written a virus before, just that Norton doesn't know, and said employees are (wisely) keeping their traps shut.
I sort of intended my list to be a set of irrefutable minimums. So, it only included things that either a) there's explicit precendent for, or b) are utterly common sense. While I'd agree that your 4 are more complete and palletable to me, finding arguments to restrict them is easier.
I like to think about how the "intrinsic" license can interact with other, separate license agreements. The GPL, for example, somewhat assumes my 4. Nobody at the FSF is going to be mad at me if I use GPL software without agreeing to the GPL (although they'll be pissed if I redistribute it).
Consider some piece of commercial software with a EULA. I believe that I can refuse to accept the terms of the EULA, and use the software under the intrinsic 4. However, there may be some benefits to accepting the EULA (much as you must accept the GPL in order to copy GPLed software). Consider StarCraft. I'd be willing to admidt that use of the official BattleNet services is conditional on accepting the EULA. However, single player, LAN games, and games hosted on 3rd party sofware (bnetd) are, IMHO, fair game even without accepting the EULA.
Now, as to the validity of giving up any of the intrinsic 4 in exchange for extra rights, I don't know. That seems to me to be one of those things where the lawyers will tell you it's "very interesting" (lawyerspeak for $1000 a day plus expenses), and probably rightly so. I'd like to think that the intrinsic 4 are irrevokable and can't be signed away (just as you can't sign away the right to bring a malpractice suit against a doctor, for example). But it isn't as clear-cut to me.
I've always viewed it like this: when you get media, there is a "basic" license intrinsically and inseparably tied to that media. The basic license grants you certain rights, including but not necessarily limited to:
the right to use
the right to resell/lend
the right to backup
the right to "space-shift" (legalese for changing the format)
The official view of the courts is that if the transaction has the quality of a sale, then it isn't licensing at all (they've also pretty much said that everything that's happened in any consumer store thusfar has had the quality of a sale). Thus, if it "feels" like a sale, then you have, if nothing else, the right of resale, lending, and space shifting (these rights have all been ruled on).
The courts have not specifically ruled on any of the other rights *I* feel you have (that I know of), but (so far as I know) a pertinent case hasn't come up. It would seem pretty silly that you didn't intrinsically have the right to listen to a CD you've bought, though. And I'm also pretty sure that copying for archival purposes is protected by copyright law as well. So, 2 of my 4 are official, one is common sense, and, well, look # 4 up.
In any case, by the doctorine of first sale, the RIAA can't restrict by legal means the used CD market. Nothing has been said about technological means, though, and it sounds like Rep. Boucher wants to restrict the use of technology to limit such things.
Interesting note, but the doctorine of first sale stems from a case where a book publisher included a "EULA" in the front of their books, forbidding their sale on the secondary market. The court ruled that the interest of the publisher in that particular copy of a protected work ended after they sold it the first time, and that they couldn't limit what happened to it afterwards. So, by some stretch, there is precident for EULA's not having legal force.
Except that there are 11 split files. 10 isn't the last one. There's an 11th (~13.5 meg) which isn't linked to on the nvidia web page, but is there nonetheless.
Don't believe me--take a look at Merge.bat.
*IF* you can get through to their ftp server you can get all 11. So far I've had mixed luck with it. Right now I just need to get the tail end of 3 and I'm done, but I've been hand-coddling the connection, noting when it has totally stalled and cut it to resume, etc. Royal pain in the ass.
I'm having a helluva time downloading it. All the mirrors I can find are swamped too. I've managed to pull maybe 80 meg of it to a machine at work that's hanging off a T3, but even that's been painful. The servers keep dropping the connection, and if it wasn't for resumable downloads, I wouldn't have gotten anywhere.
Does the music industry use monopolistic practices? The question is irrelevant.
Actually, one of the standard remidies against an abusive monopolist intellectual property holder is to suspend their right to enforcement until they stop abusing their market position. So, if the music industry does use abusive monopolistic practices, they could be considered on shakey legal ground to enforce thier copywrights.
Besides being confusing, they're nonsensical, too. It is actually cheaper for me to call somebody up and tell them my short message than it is for me to use the text messaging feature ($.25 for text messages vs $.1 for 1 minute over my allotment). However, it costs my provider a lot less to send the text message than my voice message . You'd think that they'd at least price them the same, to encourage people to use the text messaging. I can get a lot said in 1 minute, and I don't have to mess with the tiny keypad. Even if the text messaging was easier, it's more expensive. Until the price drops, I'll never use the text feature.
It makes absolutely no sense at all. I'm glad I'm not a shareholder of my cell provider--it's a really stupid pricing model.
Straight CRC checks won't work, btw. You'd have to download the whole file to do the checksum. Better to sign the file in chunks. Or, use a fancier scheme:
You could do a web-of-trust type verification. Logically, divide the files into medium-sized chunks (say 32KB). Allow people to sign the chunks (w/private key), thereby endorsing the content as "valid". You can download a chunk, and see if it's been verified (preferably by someone you trust, or someone who's been signed by someone you trust). If it has, download the next, see if that's been verified, etc. (Again, if you only sign the whole file, you have to d/l the whole file to verify the sig, which is pointless).
Now, of course ppl. could falsely sign something. So, you 1) allow more than one signing of a file. 2) distribute keys with a PGP-style trust web.
So, suppose I put up a P2P host. I allow ppl. to download my public key, along with signed files. Someone will be willing to try out my files. They find it valid, so they sign my stuff, and send the signiture back to me. They also sign my key, perhaps indicating a level of trust in the signing.
As time passes, I can build a reputation in the long list of people who have signed my key and my files. You can trust the stuff I have up to be good because the stuff I've had up before was good, and this long list of people are willing to vouch. Probably, you trust at least some of these people directly (they've shared good stuff with you), so their sig. means something.
Now, an attacker can take advantage by gaining trust, and then spewing abunch of crap. BUT, they have to deliver good shit first. If they abuse it later, well, have the signatures be dated, or provide for revocation certificates.
Or we could go back to the old-fashioned way of doing it. I trust the stuff I download because I've shaken the hand of the people I'm downloading it from. Or because I've taken a risk in the past with them, and they paid off, so now I trust them enough to let them get my stuff, and they trust me enough to let me d/l theirs. Much more personable and friendly that way.
When my mother left her systems programmer job at MD, she kept all her reference materials. System manuals, assemby references, everything. Although, her shop didn't quite get to the 390 before she left (lots of nifty 360 stuff, though).
Speaking of IBM's stuff, ever try hacking AIX? Some idiot changed the root password to our webserver without telling anyone, and then forgot it. Absolute bitch to get back in. Took me 3 days, and I had the advantage of physically being at the console with an account, which was in the security, sys, audit, and system groups. Of course later some script kiddies got in through an unpatched copy of wuftpd (which I had turned off and abovementioned idiot turned back on). Oh well. At least they saw fit to mention the unusualness of the system.
In a rather ineffectual way, they already do that.
I've not been the victim of CC fraud, but I've been contacted by my fraud department before. Apparently any large purchases of computer equipment get flagged as possibly fraudulent by Capital One. When I bought a new computer last year, I ordered ~800 of parts from one merchant. The next day the fraud dept. called to verify the order.
Now, the CC companies called to verify $800 of computer parts. I think that it'd be reasonable for them to call up the cardholder to verify $3100 of gun accessories? Much larger sum, and it's probably just as easy to fence as the electronics.
Well, if you really hate JavaScript, then I guess you won't be getting my email address, then. The really good part about this is forcing computation on the client side.
The point isn't necessarily to be perfectly secure. The point is to make it expensive for the spammers.
So what if they have a signature to the code? The idea is that this will be used to obfuscate real email addresses, and (as a bonus) bogus ones too. With or without a signature, they still have to spend cycles to decrypt, and the spambot author has to add JavaScript support. There's two ways this could make it more expensive: cycles and mandpower.
Again, the signature doesn't matter. My door plainly has a lock on it. Thieves can look at my door, and they plainly see the lock. But that doesn't keep the lock from helping. So the spammers have an easy way to ID obfuscated emails: that doesn't reduce the cost of deobfuscation. Most other obfuscation schemes are trivial, and therefore impose little cost.
True, the script is really just a proof of concept, and therefore doesn't impose a lot of cost. To be truly useful, it has to force the user to expend more cycles to get the decryption. This means a set of JavaScript large-number routines would have to be written. Also, one could include the MD5 sum of the plaintext email, and fail to include all of the bits of the keys. So rather than taking a relatively few milliseconds per address, it could take any desired amount of time, as the script has to run through lots of possible keys, and check if it gets a correct output.
One certainly doesn't want the renderer to have to slug through that, though. Your onclick() suggestion has a lot of merit, in that. If it takes a minute to decode one address, the utility of a spambot plummets. Especially if one mixes a lot of fake addresses to the mix. But to real people, spending a minute to send 1 email isn't a big deal. The same idea applies to tarboxes (SMTP servers purposely configured to be reeaallyy reeaally sllooww) and hashcash. It doesn't unduly inconvienience legitimate users, but it costs a spammer lots of resources. This has the added benefit of not eating up server side resources (tarboxes) or requiring major changes to existing specs (hashcash). All the additional work is on the client (except, I suppose, for generating the script in the first place), and most everybody already has JavaScript.
So yes, the script itself, as is, isn't perfect. But the concept is very sound.
Some spambots will render that correctly. Less likely, though, is if they'll render an email that has had this done to it: it's encrypted through javascript.
It is a rather impressive piece of work. Uses honest-to-god RSA.
You could also encrypt all email addresses, and then in your spambot trap, put really really CPU intensive javascript. You'll win either way: either the spambot doesn't do javascript, and it won't get your addresses, or it does do javascript, and they've just spent an eternity wasting time. It would work the same way as a tarpit, but it wouldn't eat nearly so many resources on your end.
If you're really clever, you could have the javascript do useful work, and then have the results of that work encoded into links in the page. You could then retrieve the results when the spider follows the link.
There was an idea called hashcash floating arount a while back. The idea was that an SMPT server would refuse to deliver email if the sender didn't provide a hash collsion of so many bits to some given value. The sender has to expend way assymetrically more resources to generate the collision than it takes the reciever to check it. That way on can impose a cost on sending a lot of email. It's not so much to be a burden on ordinary users, but if you need to send thousands of emails, it will add up.
Could you post a link? I know I've seen ways to make skiplists nicely concurrently accessed, but it is nice to have a reference, rather than just saying "Is so!".
Slashdot Mirror
I didn't say they lose the right of future enforcement, or that the patent becomes invalid. There is just no penalty for the old violations. You can halt future enforcement, or amiable agree to some monies to be paid for the old use, but you can't force damages, if you sat on your rights, delayed unnecessarily, and in doing so caused harm to the infringer.
Go search the web for defense of laches, OK? Then come back and argue.
Confusion with the terminology here. A submarine patent is one where the issuance has been delayed. This patent was issued in a timely manner. It isn't a submarine patent. While submarine patents are unethical, it is true that they are (were) legal. You can not enforce a submarine patent because it hasn't even been issued, so you couldn't enforce it if you wanted to (well, if you stopped purposely slowing down issuance...).
What has happened here is that an issued patent has lied dormant, and now is being enforced. There is reason to invalidate enforcement. Lots of other posts have more detail, but it's called the defence of laches. If you know of (or, being reasonably diligent, should have known of) infringement, you delay enforcement (standard is 6 years, varies by situation), and the infringer is harmed by the unnecesary delay, then you forfeit enforcement. The patent is still valid, and can be applied to future violations (as far as I understand, the violator has to license or stop infringing, but isn't liable for the past).
M-JPEG certainly is more relevent. However, I'm pretty sure that depending on how you structure the claims, you can get away with murder as far as broadness.
The claims are very vague as far as what sorts of transforms you do, and only get specific when you reach the lossless coder. Just about any image processing would fit into the transform claims (even 4:2:2 YUV, or other equal primative methods). Also, they are very broad about how you quantize (actually, more generically throw data away), allowing several methods, including (but not limited to) comparison to older frames.
Finally, they spell out the details of a RLE-ish huffman-ish lossless coding, which is quite similar to JPEG's (although IMHO subtly different).
But if it get's thrown out because the patent does speak extensively on video, I won't argue. I just think that a clever lawyer could make it *seem* valid dispite the video aspect, and that the primary technical objection to validity isn't the video but that their lossless coder isn't really the same, but just similar. (That and that their lossless coder isn't non-obvious, unique, or especially usefull, but hey, since when did that stop the USPTO from issuance?)
Lossless JPEG is a very unusual beast, and didn't get finalized until much later than lossy JPEG. It works according to much different principles.
Lossy JPEG transform the data such that you can easily throw away unimportant parts, and then runs a lossless coder to shrink it. By removing the unimportant parts, you make lossless coding step very efficient. Lossless JPEG tries to predict what the picture will be based off of earlier pixels. Since the predictions are usually close, you can then use fairly few bits to store the difference between the prediction and actuallity, thereby saving space, although not nearly as much as lossy.
The claims verses standard JPEG are shaky. I'd think that the claims verses lossless are much shakier.
Either way, looking for prior art in the form of old JPEGs is a waste of time. The publication of the spec itself would constitute prior art, except that it isn't old enough. And prior to the spec, there were no JPEGs. So no old JPEGs are old enough.
If you do want a replacement for lossless JPEG, JPEG2000 is quite good. In lossy mode it doesn't have nearly the problems with artifacting that JPEG does. Rather than get blocky, images tend to become progressively blurier. It also has a full lossless mode that gets very good compression ratios, and unlike lossless JPEG, is sane.
Am I the only one who thinks the ISO should stand up and fight the good fight?
It isn't in any way ISO's job to fight patents.
The JPEG people (remember, JPEG is the Joint Photograpphic Experts Group, not just a compression standard) are the ones who will fight the good fight--them and their members. JPEG itself can only do inexpensive things, and probably couldn't force a lawsuit even if they had the money. What they can do is organize their members (who do have money) into working together in the pursuit of evidence that the patent claims are invalid. which is what they are doing .
What about patents not applying if the implementation is open source and not-for-profit?
There is a relatively new area of law, equitable estopple (spelling? eh, IANAL, so don't need to write it), which covers this. In this situation it more or less says that given that the owners of the patent knew (or should have known) that their tech was being incorporated into a free standard, they should have spoken up then, and can't now. Letting someone incorporate your IP into a standard, and letting them believe that they hadn't, is a no-no. Refusing to let them use it is OK, but you have to speak up quickly.
Additionally, there is the defense of laches, which more generally covers not enforcing a patent for a long time. If, given you had been reasonably diligent, you would have been aware of infringement (or you actually were aware), and you do nothing for a long time (6 years is the standard, more or less by situation), then you forfeit your enforcement rights for past infringement. A quote I saw on it went like "Those who sleep on their rights can't expect to exercise them."
They're not claiming ownership of all of JPEG.
They're claiming that the lossless table-based huffman coding that JPEG does *after* the DCT and quantization steps is covered by their lossless table-based huffman/RLE coding.
Not that this makes their claim valid--there is likely prior art for such use of Huffman codes, and the original patent holder was a member of JPEG in the late 80's, and therefore obligated to mention their patent then.
Please stop saying that the patent has nothing to do with JPEG. If rather than reading the crappy html claims, you read the full TIFF version, it becomes clear that their patent is somewhat relevant to JPEG. The more interesting stuff in the patent isn't applicable to JPEG, but the lossless transform they use is.
Uhh, baseline is already supposed to be the minimal implementation. Anything that implements JPEG at all has to implement at least the same features as baseline. The only ways to redo baseline to remove the parts Forgent feels it owns would be to move to arithmatic coding. Arithmatic coding is part of the JPEG spec, but not baseline, because there's more patents surrounding arithmatic coding than slimy lawyers to sue over them.
You could change the spec to move to a totally new type of coding, but then it wouldn't be JPEG anymore.
The way these standards work (or are supposed to) is that everybody who owns IP related to them agrees to license without-fee for implementers of the "baseline". They (usually) also agree to licence on RAND (reasonable and non-descriminatory) terms any nifty extras (optional features not included in baseline).
The one catch is that it's only free if you follow the standard. Using JPEG2000 technology in something that isn't JPEG2000 can get you in trouble, because the free license is only for ppl. who follow the standard.
You can purchase a copy of the standard directly from ISO, or from various local standards bodies. In the US, that would be ANSI. You can buy from ANSI here. They recently dropped their price (it used to run ~$140), probably because of price competition from ISO and Standards Australia (note that prices from ISO and SA are *not* listed in USD, an that the Australian price includes a 10% tax that will be waved for foreigners). And electronic copy of a standards document is about as fungable as you can get.
Other than the requirement that you stick to the standard, it's totally free (barring submarine patents). You don't even have to notify anyone that you're implementing it. And the JPEG people have worked really hard (even harder than with the original) to ensure that J2K is unencumbered, so even the threat of submarine patents is small.
The reason they do this is to discriminate between people who just want a CD drive, and the person who wants the best possible. (More technically, they want to charge people with a low elasticity of demand more, and still sell to people witha high elasticity of demand).
If they produced just 1 model drive, then they can reasonably expect to sell it at 1 price. Let's suppose they can sell it for $50. Now, there are some people who must have the fastest drive, damn the price. These people will (obviously), buy it for $50. There are also some people who are willing to pay $50 for the drive, but not necessarily too much more. They will also buy. There is a 3rd class of people who would like a drive, but don't want to buy at $50. They don't buy.
Now lets introduce another, slower model. We can raise the price of the fast drive, say to $75. The performance freaks will all still fork out for it. If we price the slow drive at say, $40, we will still sell a drive to all the people who bought at $50 (but don't want to pay $75). We will also sell a bunch of drives to people who never did want to pay $50, but will fork out $40.
The end result is that we can extract more money out of the high end ($75 drive buyers) and the low end (people who buy at $40 but not at $50). We lose out some in the middle (people who are now paying $40 but would have paid $50), but if you balance the prices right, you can end up ahead.
Intel did the same thing with the 486SX. The earlier manufactured SXs were just the DX with the floating point co-processor disabled. They were actually more expensive to make, but they sold for less. Some people had to/really wanted to buy the DX, and paid the high price. Intel gained a large low-end market with the cheaper SX chip, and overall ended up ahead. Even the speed-ratings of their processors was price-discrimination. Intel's fabrication technology turned out very few parts that couldn't pass the high-clockrate tests. But if they sold them as high-clockrate parts, they'd glut the highend market, and drive the prices down. By labelling them slower, they can still charge a premium for the faster parts, while maintaining low-end marketshare.
Airplane tickets--same deal. It doesn't cost the airline more to sell you a ticket that doesn't include a weekend stay. They just want to charge the business traveller more. Business travellers have a low elasticity of demand -- they *must* fly. They are willing to pay a lot more. The tourist has a high elasticity of demand -- flying is totally optional. By including a weekend stay requirement for cheap fares, they can get more money overall.
Student/senior discounts for movie tickets. Cheaper meals during lunch than dinner at restaraunts. It's a very common practice in business.
All the AV vendors I know of have strict policies about their employees: they can never have written a virus. Ever. Even if it was harmless, or never released into the wild.
The liability it would open them up to is way too high for it to be worth it. They'd rather pass on hiring an otherwise perfect candidate than expose themselves to that sort of legal risk.
Now, that's not to say that some Norton employees haven't written a virus before, just that Norton doesn't know, and said employees are (wisely) keeping their traps shut.
But does anybody else find it amusing that MS choose a name where the most natural shortening of it is wince?
I sort of intended my list to be a set of irrefutable minimums. So, it only included things that either a) there's explicit precendent for, or b) are utterly common sense. While I'd agree that your 4 are more complete and palletable to me, finding arguments to restrict them is easier.
I like to think about how the "intrinsic" license can interact with other, separate license agreements. The GPL, for example, somewhat assumes my 4. Nobody at the FSF is going to be mad at me if I use GPL software without agreeing to the GPL (although they'll be pissed if I redistribute it).
Consider some piece of commercial software with a EULA. I believe that I can refuse to accept the terms of the EULA, and use the software under the intrinsic 4. However, there may be some benefits to accepting the EULA (much as you must accept the GPL in order to copy GPLed software). Consider StarCraft. I'd be willing to admidt that use of the official BattleNet services is conditional on accepting the EULA. However, single player, LAN games, and games hosted on 3rd party sofware (bnetd) are, IMHO, fair game even without accepting the EULA.
Now, as to the validity of giving up any of the intrinsic 4 in exchange for extra rights, I don't know. That seems to me to be one of those things where the lawyers will tell you it's "very interesting" (lawyerspeak for $1000 a day plus expenses), and probably rightly so. I'd like to think that the intrinsic 4 are irrevokable and can't be signed away (just as you can't sign away the right to bring a malpractice suit against a doctor, for example). But it isn't as clear-cut to me.
Just some random musings.
I've always viewed it like this: when you get media, there is a "basic" license intrinsically and inseparably tied to that media. The basic license grants you certain rights, including but not necessarily limited to:
The official view of the courts is that if the transaction has the quality of a sale, then it isn't licensing at all (they've also pretty much said that everything that's happened in any consumer store thusfar has had the quality of a sale). Thus, if it "feels" like a sale, then you have, if nothing else, the right of resale, lending, and space shifting (these rights have all been ruled on).
The courts have not specifically ruled on any of the other rights *I* feel you have (that I know of), but (so far as I know) a pertinent case hasn't come up. It would seem pretty silly that you didn't intrinsically have the right to listen to a CD you've bought, though. And I'm also pretty sure that copying for archival purposes is protected by copyright law as well. So, 2 of my 4 are official, one is common sense, and, well, look # 4 up.
In any case, by the doctorine of first sale, the RIAA can't restrict by legal means the used CD market. Nothing has been said about technological means, though, and it sounds like Rep. Boucher wants to restrict the use of technology to limit such things.
Interesting note, but the doctorine of first sale stems from a case where a book publisher included a "EULA" in the front of their books, forbidding their sale on the secondary market. The court ruled that the interest of the publisher in that particular copy of a protected work ended after they sold it the first time, and that they couldn't limit what happened to it afterwards. So, by some stretch, there is precident for EULA's not having legal force.
Except that there are 11 split files. 10 isn't the last one. There's an 11th (~13.5 meg) which isn't linked to on the nvidia web page, but is there nonetheless.
Don't believe me--take a look at Merge.bat.
*IF* you can get through to their ftp server you can get all 11. So far I've had mixed luck with it. Right now I just need to get the tail end of 3 and I'm done, but I've been hand-coddling the connection, noting when it has totally stalled and cut it to resume, etc. Royal pain in the ass.
I'm having a helluva time downloading it. All the mirrors I can find are swamped too. I've managed to pull maybe 80 meg of it to a machine at work that's hanging off a T3, but even that's been painful. The servers keep dropping the connection, and if it wasn't for resumable downloads, I wouldn't have gotten anywhere.
Anybody know of a "reliable" mirror?
Does the music industry use monopolistic practices? The question is irrelevant.
Actually, one of the standard remidies against an abusive monopolist intellectual property holder is to suspend their right to enforcement until they stop abusing their market position. So, if the music industry does use abusive monopolistic practices, they could be considered on shakey legal ground to enforce thier copywrights.
Besides being confusing, they're nonsensical, too. It is actually cheaper for me to call somebody up and tell them my short message than it is for me to use the text messaging feature ($.25 for text messages vs $.1 for 1 minute over my allotment). However, it costs my provider a lot less to send the text message than my voice message . You'd think that they'd at least price them the same, to encourage people to use the text messaging. I can get a lot said in 1 minute, and I don't have to mess with the tiny keypad. Even if the text messaging was easier, it's more expensive. Until the price drops, I'll never use the text feature.
It makes absolutely no sense at all. I'm glad I'm not a shareholder of my cell provider--it's a really stupid pricing model.
Why not just put a GSM reciever on the bloody train?
Straight CRC checks won't work, btw. You'd have to download the whole file to do the checksum. Better to sign the file in chunks. Or, use a fancier scheme:
You could do a web-of-trust type verification. Logically, divide the files into medium-sized chunks (say 32KB). Allow people to sign the chunks (w/private key), thereby endorsing the content as "valid". You can download a chunk, and see if it's been verified (preferably by someone you trust, or someone who's been signed by someone you trust). If it has, download the next, see if that's been verified, etc. (Again, if you only sign the whole file, you have to d/l the whole file to verify the sig, which is pointless).
Now, of course ppl. could falsely sign something. So, you 1) allow more than one signing of a file. 2) distribute keys with a PGP-style trust web.
So, suppose I put up a P2P host. I allow ppl. to download my public key, along with signed files. Someone will be willing to try out my files. They find it valid, so they sign my stuff, and send the signiture back to me. They also sign my key, perhaps indicating a level of trust in the signing.
As time passes, I can build a reputation in the long list of people who have signed my key and my files. You can trust the stuff I have up to be good because the stuff I've had up before was good, and this long list of people are willing to vouch. Probably, you trust at least some of these people directly (they've shared good stuff with you), so their sig. means something.
Now, an attacker can take advantage by gaining trust, and then spewing abunch of crap. BUT, they have to deliver good shit first. If they abuse it later, well, have the signatures be dated, or provide for revocation certificates.
Or we could go back to the old-fashioned way of doing it. I trust the stuff I download because I've shaken the hand of the people I'm downloading it from. Or because I've taken a risk in the past with them, and they paid off, so now I trust them enough to let them get my stuff, and they trust me enough to let me d/l theirs. Much more personable and friendly that way.
Uhh, no.
Any building or landscaping visible from a public way cannot be copyrighted.
When my mother left her systems programmer job at MD, she kept all her reference materials. System manuals, assemby references, everything. Although, her shop didn't quite get to the 390 before she left (lots of nifty 360 stuff, though).
Speaking of IBM's stuff, ever try hacking AIX? Some idiot changed the root password to our webserver without telling anyone, and then forgot it. Absolute bitch to get back in. Took me 3 days, and I had the advantage of physically being at the console with an account, which was in the security, sys, audit, and system groups. Of course later some script kiddies got in through an unpatched copy of wuftpd (which I had turned off and abovementioned idiot turned back on). Oh well. At least they saw fit to mention the unusualness of the system.
In a rather ineffectual way, they already do that.
I've not been the victim of CC fraud, but I've been contacted by my fraud department before. Apparently any large purchases of computer equipment get flagged as possibly fraudulent by Capital One. When I bought a new computer last year, I ordered ~800 of parts from one merchant. The next day the fraud dept. called to verify the order.
Now, the CC companies called to verify $800 of computer parts. I think that it'd be reasonable for them to call up the cardholder to verify $3100 of gun accessories? Much larger sum, and it's probably just as easy to fence as the electronics.
Well, if you really hate JavaScript, then I guess you won't be getting my email address, then. The really good part about this is forcing computation on the client side.
The point isn't necessarily to be perfectly secure. The point is to make it expensive for the spammers.
So what if they have a signature to the code? The idea is that this will be used to obfuscate real email addresses, and (as a bonus) bogus ones too. With or without a signature, they still have to spend cycles to decrypt, and the spambot author has to add JavaScript support. There's two ways this could make it more expensive: cycles and mandpower.
Again, the signature doesn't matter. My door plainly has a lock on it. Thieves can look at my door, and they plainly see the lock. But that doesn't keep the lock from helping. So the spammers have an easy way to ID obfuscated emails: that doesn't reduce the cost of deobfuscation. Most other obfuscation schemes are trivial, and therefore impose little cost.
True, the script is really just a proof of concept, and therefore doesn't impose a lot of cost. To be truly useful, it has to force the user to expend more cycles to get the decryption. This means a set of JavaScript large-number routines would have to be written. Also, one could include the MD5 sum of the plaintext email, and fail to include all of the bits of the keys. So rather than taking a relatively few milliseconds per address, it could take any desired amount of time, as the script has to run through lots of possible keys, and check if it gets a correct output.
One certainly doesn't want the renderer to have to slug through that, though. Your onclick() suggestion has a lot of merit, in that. If it takes a minute to decode one address, the utility of a spambot plummets. Especially if one mixes a lot of fake addresses to the mix. But to real people, spending a minute to send 1 email isn't a big deal. The same idea applies to tarboxes (SMTP servers purposely configured to be reeaallyy reeaally sllooww) and hashcash. It doesn't unduly inconvienience legitimate users, but it costs a spammer lots of resources. This has the added benefit of not eating up server side resources (tarboxes) or requiring major changes to existing specs (hashcash). All the additional work is on the client (except, I suppose, for generating the script in the first place), and most everybody already has JavaScript.
So yes, the script itself, as is, isn't perfect. But the concept is very sound.
Some spambots will render that correctly. Less likely, though, is if they'll render an email that has had this done to it: it's encrypted through javascript.
It is a rather impressive piece of work. Uses honest-to-god RSA.
You could also encrypt all email addresses, and then in your spambot trap, put really really CPU intensive javascript. You'll win either way: either the spambot doesn't do javascript, and it won't get your addresses, or it does do javascript, and they've just spent an eternity wasting time. It would work the same way as a tarpit, but it wouldn't eat nearly so many resources on your end.
If you're really clever, you could have the javascript do useful work, and then have the results of that work encoded into links in the page. You could then retrieve the results when the spider follows the link.
There was an idea called hashcash floating arount a while back. The idea was that an SMPT server would refuse to deliver email if the sender didn't provide a hash collsion of so many bits to some given value. The sender has to expend way assymetrically more resources to generate the collision than it takes the reciever to check it. That way on can impose a cost on sending a lot of email. It's not so much to be a burden on ordinary users, but if you need to send thousands of emails, it will add up.
Could you post a link? I know I've seen ways to make skiplists nicely concurrently accessed, but it is nice to have a reference, rather than just saying "Is so!".