The sniffing is a good point, going further than that, how was tridge _testing_ his free client, ie. against what server ?
If he was testing against servers provided by BM they probably have some legitimate cause for complaint (who would pay to sort out the mess if his experimental client caused data corruption has been raised as an issue). If he was testing against his own servers in his own isolated environment then no data damage issues - but then who provided the server setup ?
The samba team definitely test against MS clients and servers, but do they use pirate copies or test against other peoples servers or otherwise violate server license agreements to do it ? Somehow I doubt it because they want to ensure they are above board (I think I read that they won't even look at the specs MS have had to publish because of some licence issues with those specs).
He probably does what any other software manager does when he wants to cost something - add up the time spent, multiply by the person-cost and then the overheads.
It is pretty simple, standard, and something he will be doing, because he has to be able to do anyway to find out which of his commercial customers he is making or losing money on. FAIB bk will be just another customer in the accounting.
So 500k in directly billed staff costs for working on the free version is MPAA/RIAA maths, and what we should actually be doing is discounting it by some "goodwill" value which comes from it being extensively used by a bunch of people who aren't paying for it anyway.
Sorry, but the 500k is easy solid accounting, offsetting it by some "goodwill" value that you pull out the air actually _is_ MPAA/RIAA maths.
$500k was the cost put on the paid work of developing and supporting free bk for Linux, not some kind of 100% profit "license fee" cost.
Doesn't matter that it was worth nothing to _you_ - someone (Larry & his company) paid $500k of programmers wages + overheads to produce & support the free version. This is not actually a lot - probably (counting overheads, taxes etc.) only around 3 good people for a year.
Was it "worth" $500k ? - depends to whom and for what, but I would say that it was clearly a technical success, it was "worth" a large speed-up in linux kernel development, and a lot of large IT projects spend a lot more than that for a lot less technical success.
Linus had already written a generic export and is on record as saying that Larry was happy with this and in fact happy to add something similar but most likely _better_ into the standard BK build.
Where do you think the dataset that Linus is now using to build his own system came from ? Not from Tridge.
There was clearly no attempt at lock-in of the data.
Linus created a from-scratch implementation of a published standard - not reverse engineering at all.
In fact, I'm not sure Linus had access to any unix implementations to reverse engineer (with the exception of minix which was source available anyway and therefore didn't need to be).
Depends on the site. For some sites you better have the right security clearance let alone agree to a licence.
SAMBA team do lots of similar reverse engineering of protocols, often by firing data at servers, but I don't think they'd be doing it using Microsoft's actual servers.
Or look at it another way:
Firing random packets is a good test of a server - if it's your own server. On someone else's server it's a good attack.
Based on one one his posts (see here) it might just as likely be aimed at Tridge (if it is aimed at anyone).
Quote Linus:
When we were trying to figure out how to avert the BK disaster, and one of Tridges concerns (and, in my opinion, the only really valid one) was that you couldn't get the BK data in some SCM-independent way. So I wrote some very preliminary scripts [...snip...] Larry was ok with the idea to make my export format actually be natively supported by BK (ie the same way you have "bk export -tpatch"), but Tridge wanted to instead get at the native data and be difficult about it. As a result, I can now not only use BK any more, but we also don't have a nice export format from BK. Yeah, I'm a bit bitter about it.
I can't see any technical or logical difference between your examples.
No binaries are distributed in either case - which is precisely the "loophole" some people want closed.
If google uses a modified GIMP behind the scenes (eg. for some sort of image matching) then some GPL folks want those modifications published. If I put a web interface over the GIMP so you can "use" it running on my server then it is the _same_ _thing_ as google putting a web interface over it for image search. In both cases the gpl app is backing a web-service interface.
I can't see any evidence that anyone knows how to draw a clear line between what does and does not "count" when closing this "loophole" (similarly to the static/dynamic linking cases, which have been argued ad-nauseum).
What if...
I put a web interface over a modifed GPL spreadsheet ? I charge people using a modified GPL shopping cart ? I run a forum about it using a modified GPL bulletin board ? I run the site on a modified GPL web server ? I run the server on a modified GPL OS (modified specifically for this, think eg. khttpd) ?
Which sources do I have to ship ? Could add up to a hell of a hosting / bandwidth bill before you even get into other considerations. Remember, you can't just ship diffs and you can't just point to another site (see GPL FAQ). Also you can't charge for the source if you didn't charge for the binary / service - so no way to cover that bandwidth cost for free sites.
1) Bill Gates is a reasonable man--unlike RMS and all of those other philosophical kooks. He uses the right tool for the job
That would be the RMS who supported his first products only on proprietary Unix (and still gave Unix support priority in the early days of Linux) ?
Why ? Pragmatism ? Right (only) tool for the job perhaps ?
Paying the bills ? I mean, those Unix tape sales must have got the FSF a lot more money than Linux versions downloaded by peniless students who wanted everything for free (as in beer)...
[...] to the extent that the service provider goes out of their way to encourage you to use it for copyright infringement [...]
You mean like "Rip, Mix, Burn" ?
Or "The killer app for the computer industry is piracy," - Eisner
"That's like selling a crowbar and telling someone to smash, bash and steal," [quote from unamed entertainment industry ].
Make no mistake, even an "intent" ruling is dangerous because intent is difficult to disprove especially if the service/product ends up being used to infringe and it was forseeable. Remember in civil law it is "balance of probabilities" - if a device was forseeably useful for infringement and was then actually used for infringement, who is going to believe that this wasn't "probably" intentional (especially if you advertise the potentially infringing capability, ie. advertising that a device can "copy", or even calling it a "copier" - remember copying is infringing...) ?
If Betamax goes then they _will_ go after CD/DVD writers (or pcs/macs including such) etc.
Sort of like how if a cop sees a guy in a Santa Clause suit walking through a shopping district in early June, he might pay attention to what that guy's up to.
The truth is usually quite simple. Real governments exists to serve themselves as much as the people.
That would mean they serve the people as much as themselves. Nice fantasy. Closest to that would probably be a benevolent dictatorship.
Democratic governments exist to convince the people to vote for them next time. They may give the appearance of serving the people some of the time if there are votes in it. Actually serving the people is probably the hardest way to get votes, so if it happens it is probably an accidental side-effect.
In desperation, the authors turned to hot-shot programmer Eric Raymond, author of an unused Linux configuration tool. [...] Eric suggested using an "encryption" system to prevent music from being used in ways the music publishers wouldn't like.
and this gets +1 informative ?!
Well, either I've drunk too much to read properly or someone's seriously missed the satire.
Ultimately, you could sniff the data as it is transferred to a genuine client
Only if you send it clear-text over an insecure channel.
It ought to be straightforward for Apple to have blocked the hole to the point where you would have to crack encryption keys/algorithms out of the client to do this. At that point the RIAA can start throwing their favourite DMCA hammer around. Right now they probably can't, because it seems that no encryption was ever applied.
If apple really said that, and made no attempt to authenticate / validate the client in the transaction, then I think they have a problem.
I also think that there is a difference here - I believe that Apple will be contracted to deliver an encrypted track, and the user is contracting to buy an encrypted track. If the setup is such that the user can change the transaction to buy an un-encrypted track (that the seller isn't authorised to sell) then that is different to the user cracking the encrypted track later.
Also, it possibly changes the legality for the user - DMCA may not apply as there is no encryption being cracked because it is never applied. It may be a breach of site EULA or a fraudulent purchase of course - but not DMCA. The RIAA will be upset at that.
In terms of obviousness, I would put it at the same level as trusting data from a client-side shopping cart:
* some people have fallen for it * it saves work on the server * it isn't obvious to the layman why it is a bad idea ("but it's a hidden field, so the user can't see it") * but it ought to be obvious to any serious ecommerce developer
Point is their suppliers/contracts almost certainly require them to make reasonable efforts with drm.
This sounds (so far) like so obvious a flaw that the record co.s will be screaming negligence - probably not what Jobs wanted.
On the other hand, iTunes is too big to kill now, and what better way could there be to demonstrate that all DRM is intrinsically flawed because sooner of later you have to trust the client...
Slashdot Mirror
The sniffing is a good point, going further than that, how was tridge _testing_ his free client, ie. against what server ?
If he was testing against servers provided by BM they probably have some legitimate cause for complaint (who would pay to sort out the mess if his experimental client caused data corruption has been raised as an issue). If he was testing against his own servers in his own isolated environment then no data damage issues - but then who provided the server setup ?
The samba team definitely test against MS clients and servers, but do they use pirate copies or test against other peoples servers or otherwise violate server license agreements to do it ? Somehow I doubt it because they want to ensure they are above board (I think I read that they won't even look at the specs MS have had to publish because of some licence issues with those specs).
He probably does what any other software manager does when he wants to cost something - add up the time spent, multiply by the person-cost and then the overheads.
It is pretty simple, standard, and something he will be doing, because he has to be able to do anyway to find out which of his commercial customers he is making or losing money on. FAIB bk will be just another customer in the accounting.
So 500k in directly billed staff costs for working on the free version is MPAA/RIAA maths, and what we should actually be doing is discounting it by some "goodwill" value which comes from it being extensively used by a bunch of people who aren't paying for it anyway.
Sorry, but the 500k is easy solid accounting, offsetting it by some "goodwill" value that you pull out the air actually _is_ MPAA/RIAA maths.
Goodwill valuations are IMO just fiction.
$500k was the cost put on the paid work of developing and supporting free bk for Linux, not some kind of 100% profit "license fee" cost.
Doesn't matter that it was worth nothing to _you_ - someone (Larry & his company) paid $500k of programmers wages + overheads to produce & support the free version. This is not actually a lot - probably (counting overheads, taxes etc.) only around 3 good people for a year.
Was it "worth" $500k ? - depends to whom and for what, but I would say that it was clearly a technical success, it was "worth" a large speed-up in linux kernel development, and a lot of large IT projects spend a lot more than that for a lot less technical success.
Bullshit - RTFA.
Linus had already written a generic export and is on record as saying that Larry was happy with this and in fact happy to add something similar but most likely _better_ into the standard BK build.
Where do you think the dataset that Linus is now using to build his own system came from ? Not from Tridge.
There was clearly no attempt at lock-in of the data.
Linus created a from-scratch implementation of a published standard - not reverse engineering at all.
In fact, I'm not sure Linus had access to any unix implementations to reverse engineer (with the exception of minix which was source available anyway and therefore didn't need to be).
Depends on the site. For some sites you better have the right security clearance let alone agree to a licence.
SAMBA team do lots of similar reverse engineering of protocols, often by firing data at servers, but I don't think they'd be doing it using Microsoft's actual servers.
Or look at it another way:
Firing random packets is a good test of a server - if it's your own server. On someone else's server it's a good attack.
Quote Linus:
Seems clear who he is a bit bitter at.
"breasts" is a naughty word.
I can't see any technical or logical difference between your examples.
No binaries are distributed in either case - which is precisely the "loophole" some people want closed.
If google uses a modified GIMP behind the scenes (eg. for some sort of image matching) then some GPL folks want those modifications published. If I put a web interface over the GIMP so you can "use" it running on my server then it is the _same_ _thing_ as google putting a web interface over it for image search. In both cases the gpl app is backing a web-service interface.
I can't see any evidence that anyone knows how to draw a clear line between what does and does not "count" when closing this "loophole" (similarly to the static/dynamic linking cases, which have been argued ad-nauseum).
What if...
I put a web interface over a modifed GPL spreadsheet ?
I charge people using a modified GPL shopping cart ?
I run a forum about it using a modified GPL bulletin board ?
I run the site on a modified GPL web server ?
I run the server on a modified GPL OS (modified specifically for this, think eg. khttpd) ?
Which sources do I have to ship ? Could add up to a hell of a hosting / bandwidth bill before you even get into other considerations. Remember, you can't just ship diffs and you can't just point to another site (see GPL FAQ). Also you can't charge for the source if you didn't charge for the binary / service - so no way to cover that bandwidth cost for free sites.
1) Bill Gates is a reasonable man--unlike RMS and all of those other philosophical kooks. He uses the right tool for the job
That would be the RMS who supported his first products only on proprietary Unix (and still gave Unix support priority in the early days of Linux) ?
Why ? Pragmatism ? Right (only) tool for the job perhaps ?
Paying the bills ? I mean, those Unix tape sales must have got the FSF a lot more money than Linux versions downloaded by peniless students who wanted everything for free (as in beer)...
I think the GP poster was referring to conference submissions often having strict page-length limits (four pages being quite common).
That means that there may well be far far more work on this than four pages, and the conf. paper is a precis. of that work.
Add digital home video.
1x1 hour mini-dv tape -> about 12G avi.
Sure you can loosy-compress them - but then there is more loss if you want to edit them.
[...] to the extent that the service provider goes out of their way to encourage you to use it for copyright infringement [...]
You mean like "Rip, Mix, Burn" ?
Or "The killer app for the computer industry is piracy," - Eisner
"That's like selling a crowbar and telling someone to smash, bash and steal," [quote from unamed entertainment industry ].
Make no mistake, even an "intent" ruling is dangerous because intent is difficult to disprove especially if the service/product ends up being used to infringe and it was forseeable. Remember in civil law it is "balance of probabilities" - if a device was forseeably useful for infringement and was then actually used for infringement, who is going to believe that this wasn't "probably" intentional (especially if you advertise the potentially infringing capability, ie. advertising that a device can "copy", or even calling it a "copier" - remember copying is infringing...) ?
If Betamax goes then they _will_ go after CD/DVD writers (or pcs/macs including such) etc.
Sort of like how if a cop sees a guy in a Santa Clause suit walking through a shopping district in early June, he might pay attention to what that guy's up to.
Easy, he's a decoy.
The truth is usually quite simple. Real governments exists to serve themselves as much as the people.
That would mean they serve the people as much as themselves. Nice fantasy. Closest to that would probably be a benevolent dictatorship.
Democratic governments exist to convince the people to vote for them next time. They may give the appearance of serving the people some of the time if there are votes in it. Actually serving the people is probably the hardest way to get votes, so if it happens it is probably an accidental side-effect.
In desperation, the authors turned to hot-shot programmer Eric Raymond, author of an unused Linux configuration tool. [...] Eric suggested using an "encryption" system to prevent music from being used in ways the music publishers wouldn't like.
and this gets +1 informative ?!
Well, either I've drunk too much to read properly or someone's seriously missed the satire.
Certain Unis still award BA/MA for everything, simply because that is what they've been doing for hundreds of years.
Hence I actually do have BA & MA in EE.
Note that (per previous news stories, and probably on /. too) the update they are now forcing has more limits on what you can do with the music.
See eg. here.
Note the comments about no one being forced to upgrade... well, not any more.
Whether it is "right" or not, it is still the case that it is _distribution_ that typically gets you much more trouble than personal use.
Applies to binary-only mods to GPL software, music, movies, drugs, etc.
Actually he was arrested for writing the program that did that and distributing it
You really think he would have been arrested if he broke the encryption to play his dvds and never shipped that program to anyone else ?
Ultimately, you could sniff the data as it is transferred to a genuine client
Only if you send it clear-text over an insecure channel.
It ought to be straightforward for Apple to have blocked the hole to the point where you would have to crack encryption keys/algorithms out of the client to do this. At that point the RIAA can start throwing their favourite DMCA hammer around. Right now they probably can't, because it seems that no encryption was ever applied.
If apple really said that, and made no attempt to authenticate / validate the client in the transaction, then I think they have a problem.
I also think that there is a difference here - I believe that Apple will be contracted to deliver an encrypted track, and the user is contracting to buy an encrypted track. If the setup is such that the user can change the transaction to buy an un-encrypted track (that the seller isn't authorised to sell) then that is different to the user cracking the encrypted track later.
Also, it possibly changes the legality for the user - DMCA may not apply as there is no encryption being cracked because it is never applied. It may be a breach of site EULA or a fraudulent purchase of course - but not DMCA. The RIAA will be upset at that.
In terms of obviousness, I would put it at the same level as trusting data from a client-side shopping cart:
* some people have fallen for it
* it saves work on the server
* it isn't obvious to the layman why it is a bad idea ("but it's a hidden field, so the user can't see it")
* but it ought to be obvious to any serious ecommerce developer
Point is their suppliers/contracts almost certainly require them to make reasonable efforts with drm.
This sounds (so far) like so obvious a flaw that the record co.s will be screaming negligence - probably not what Jobs wanted.
On the other hand, iTunes is too big to kill now, and what better way could there be to demonstrate that all DRM is intrinsically flawed because sooner of later you have to trust the client...
So encypt them all once and trans-crypt in the client.
Securely identify the client as yours before you transmit.
Not going to be uncrackable but would have been a lot harder to get round than this.