robots.txt is the moral (and in some cases, legal) equivalent of an "authorized persons only" or "no soliciting sign". It states a condition for accessing the owner's property. HTTP authentication, conversely, is like a lock; trying to prevent rather than prohibit access.
Accessing a computer system in a way specifically prohibited by the owner is illegal in most jurisdictions, and a good thing too.
If Salzenberg's letter is correct then there can be little doubt that HMS knew their access was unauthorized and illegal.
Suppose 55% of the parents are people (=most), and 55% of people are stupid (=most), then you know that at least 30.25% of the parents are stupid.
Since you're being pedantic... you know no such thing, unless you assume zero correlation.
It might be that there are only 10% of all beings are both stupid and parents, 45% are non-stupid parents and 45% are stupid non-parents. (A total of 55% stupid and 55% parents.) Then only 18.2% of the parents are stupid.
There's a whole damned revolution waiting on opensource.apple.com and nobody's paying attention to it. Why?
Because opensource.apple.com has no DNS entry?
That aside, why? To start with, because the page you linked to gives a "username/password" form and nothing else! So does practically everything else on that site. To get any code, or even to find out details of what is available, I need to give apple not just a username and password but also my street address.
I can see Apple are trying to do the right thing but they really need to learn how things are done if they want positive feedback. Sticking some dusty code up on a password-protected web site doesn't do anyone much good. Dumping out enormous patches at the end of a year's development doesn't help much either.
I guess they're turning in the right direction, and it's just that big and (historically) secretive companies take a long time to change.
This tool is at a different level to pkgsrc or emerge. Distribution developers (for example) sometimes apply patches to packages that have not yet been merged upstream. emerge has a way to fetch them at compile time, as does rpm and dpkg-build and I suppose BSD does too. This tool has nothing to do with that. What it *does* do is help them find the right patches to apply, perhaps borrowing them from another distribution.
(Whether it is really a good idea for distributions to ship software that varies very much from the upstream source is another and complex question, but it is a fact of life at the moment.)
Lisp needs a new incompatible dialect like it needs another hole in its foot. The problem with more widespread adoption of lisp is the lack of a good, free, widely standardized implementation. Practically every Lisp text begins with an apology for the fact that your implementation probably won't work exactly the same as the one the author used.
But then Paul knows far more about the problem than I do, and if it turns out he's right I'll be delighted.
By the way, you'll note it doesn't ask you for a licence key, doesn't say you must be a licenced user, doesn't make you promise not to piss off larry, etc. Ask for help and get help.
OSDL should have recognized that Linux is a more important project than reverse-engineering BitKeeper and told their employees not to do that on company time/servers or get fired.
tridge didn't do it on OSDL time/servers.
Please acquaint yourself with the history before flaming.
The problem is that many people, like the GP, own a car and incur most of those fixed costs anyhow: initial purchase, time-base maintenance, depreciation, registration, tax, insurance, garaging, road construction. These are fixed, or at least partially fixed costs: insurance costs the same (to me) regardless of whether I drive 100km or 100,000km in a year. (Which is probably an insurance market inefficiency, but anyhow.)
People can only avoid these costs if they can do without a car altogether. For many places in the world you're going to want one at least sometimes (e.g. if working late, or travelling out of town.) To get people not to own a car at all, public transport needs to be a compelling alternative even when it's raining at 11pm on Sunday.
Given that people have spent a large fixed amount to have a car available it's understandable they would want to get a lot of use out of it. Driving an extra 100km has a relatively small monetary cost.
One prong is to encourage people who have cars not to use them. Another is to encourage people not to buy cars: so, have good scooter/bike/motorbike parking, have clean safe and reliable taxis, etc.
Surprisingly enough, people roasting coffee do not just set the oven at random in the hope that it will turn out well. I don't just write invoices randomly in the hope that clients will overpay and not care.
Of course it's possible to have lucky accidents but I wouldn't bet that way.
Economies are not zero sum, except in a reductionist sense that we are eventually all dead. I had a cup of coffee this morning which was produced from less valuable things, rather than being taken from someone who previously had it. The cup of coffee was produced because of intentional effort by a whole chain of people, and likely would not have been made if their decisions were randomized.
Leaving aside pricing, suppose a spreadsheet error caused them to roast the coffee at too high of a temperature, ruining the batch. In what way does that possibly benefit someone? Possibly it creates more demand from the grower but to suggest randomly destroying things so they can be replaced is mere nihilism.
If you consider this too hand-wavey, try playing a computer game with random decisions compared to trying to make good decisions.
I think book-keeping errors really do have a cost. If you unintentionally undercharge then you've inserted a market inefficiency. Suppose because you undercharged, you have a cashflow problem, which then causes a rippling disruption through your suppliers and employees. Suppose you go broke because of spreadsheet errors, and then all your customers can't buy your stuff anymore.
I had a quick look through and can't spot it, but I remember seeing it and having just the same feeling as with the Register: "he really said that? oh, i see."
Yes, that's a very clear way to look at it, and your categorizations are correct.
Larry asserts that's it's impossible to do #2 without doing #3. But then he asserts lots of outrageous things, such as that the existence of this tool will cause damage costing $35k to other people's repositories. (Which to me makes bk sounds really dodgy...)
Sometimes there is a fuzzy line but it seems pretty clear that what tridge was doing #1 and 2. And I think that's morally fine.
Of course it's pretty common for monopolists to get upset with #2.
Linus believes that reverse-engineering of proprietary binaries is not the right way to do things.
That fine, but also irrelevant.
I don't think tridge ever saw the bitkeeper binaries. All he did was look at data files containing open source code.
The principle proposed is that you should not interoperate with someone else's product if they don't want you to. Considering Linux runs on a lot of hardware where it was unwelcome by the manufacturer this is inconsistent with his own actions. Why did he support the sun port when Sun hated Linux?
BitKeeper has no monopoly. It may in fact be THE best of breed implementation, but that's irrelevant. Samba had to be done. A reverse-engineering of the BitKeeper protocol just to save time on developing a good approach using OSS is an endeavor with questionable ethical status and really isn't necessary. Also, reverse engineering BitKeeper just so people can access the data is obviated by the fact that they can (someone correct me here if I'm wrong as I haven't tried this myself) use CVS instead to access that data. BitKeeper doesn't need to be reverse engineered to get to the data. Right?
Wrong.
Firstly, Bitkeeper really does have a monopoly. If you want the current version of some kernel trees, the only way to get it was through Bitkeeper. Larry doesn't own the copyright in those trees, but he did control access to them.
Secondly, CVS can't be used to access the data. BKCVS is only available for one tree out of thousands in the world, is often down, corrupt or out of date, and loses a lot of useful information. You can (sometimes) get linus's tree from bkcvs, but not the head of the ppc port or mysql or e2fsprogs or whatever else.
The same goes for the recent "bkclient", except that people report it's even more flaky. One kernel developer said it took a week of trying to get a checkout, so clearly it's not a viable alternative.
For people whose licence has just been cancelled tridge's tool may be the only way to get their work back out.
I agree that *if* the reverse engineering had been merely to take ideas then it might be ethically questionable but that's not what happened.
Larry could have avoided this by providing a decent export command in the first place, but he's refused to do that because he wanted the monopoly. OK, I can see why he wanted that but eventually someone's going to route around the damage.
So, on the whole, I think the comparison to OpenOffice is pretty exact: given that people's own information is locked in a proprietary format it's entirely reasonable to work out how to get it out.
Linux runs on a lot of different hardware. Not every hardware vendor is so enlightened as to contribute open source drivers, and some actively oppose it.
And yet Linux supports at least some of that hardware. How? By reverse engineering it. By poking at it, trying things out, seeing what works, seeing what doesn't. Basically the same techniques tridge would have used on Bitkeeper repositories.
Sun was no friend of Linux in the 90s. They could have made just the same argument: that Linux is stealing their valuable IP by discovering enough about Sun hardware to run there.
But, y'know, that argument is bullshit. Reverse engineering for interoperability is legally protected and morally right.
Remember the very first filesystem supported by Linux was the minix filesystem, which was based on the non-free design of Minix.
Now, perhaps you can say that Linus never wrote any of those drivers himself, but he certainly accepted them into his tree and encouraged people to write them.
Journalists have a rule that anything between quotation marks has to be an exact quote.
Mediocre journalism undergrads, maybe.
Last week's Economist uses almost exactly the same tactic -- to show how hypocritical or inconsistent someone's position is. (I wouldn't be surprised if that was what put Orlowski in mind of it.)
Whether you agree with the Economist's moderate-libertarian politics or not, their journalism and sub-editing is of the highest rank.
The real fault here is not with the Register having a mock-quote, but with Slashdot quoting the Register out of context (which really is a sin.)
How would this be any different if a open-source project died and one needed to transfer files?
Well, the difference would be that open source projects never suddenly cancel everybody's licence. You can always at least use the code to export the data out again. That's why they call it open source.
Slashdot Mirror
robots.txt is the moral (and in some cases, legal) equivalent of an "authorized persons only" or "no soliciting sign". It states a condition for accessing the owner's property. HTTP authentication, conversely, is like a lock; trying to prevent rather than prohibit access.
Accessing a computer system in a way specifically prohibited by the owner is illegal in most jurisdictions, and a good thing too.
If Salzenberg's letter is correct then there can be little doubt that HMS knew their access was unauthorized and illegal.
5. Do not allow attachments into your life.
That can be fairly easily done with a Postfix header check (see other story) or MimeDefang.
Thanks for that image
You can't talk, with a username like that!
Suppose 55% of the parents are people (=most), and 55% of people are stupid (=most), then you know that at least 30.25% of the parents are stupid.
Since you're being pedantic... you know no such thing, unless you assume zero correlation.
It might be that there are only 10% of all beings are both stupid and parents, 45% are non-stupid parents and 45% are stupid non-parents. (A total of 55% stupid and 55% parents.) Then only 18.2% of the parents are stupid.
Before replying pedantically, dig two graves.
There's a whole damned revolution waiting on opensource.apple.com and nobody's paying attention to it. Why?
Because opensource.apple.com has no DNS entry?
That aside, why? To start with, because the page you linked to gives a "username/password" form and nothing else! So does practically everything else on that site. To get any code, or even to find out details of what is available, I need to give apple not just a username and password but also my street address.
I can see Apple are trying to do the right thing but they really need to learn how things are done if they want positive feedback. Sticking some dusty code up on a password-protected web site doesn't do anyone much good. Dumping out enormous patches at the end of a year's development doesn't help much either.
I guess they're turning in the right direction, and it's just that big and (historically) secretive companies take a long time to change.
This tool is at a different level to pkgsrc or emerge. Distribution developers (for example) sometimes apply patches to packages that have not yet been merged upstream. emerge has a way to fetch them at compile time, as does rpm and dpkg-build and I suppose BSD does too. This tool has nothing to do with that. What it *does* do is help them find the right patches to apply, perhaps borrowing them from another distribution.
(Whether it is really a good idea for distributions to ship software that varies very much from the upstream source is another and complex question, but it is a fact of life at the moment.)
And as I recall you couldn't even do tcpip networking from the POSIX layer. A unix machine with no sockets is not much fun.
So, as you say, cleverly calculated to tick the box but not actually be useful.
Lisp needs a new incompatible dialect like it needs another hole in its foot. The problem with more widespread adoption of lisp is the lack of a good, free, widely standardized implementation. Practically every Lisp text begins with an apology for the fact that your implementation probably won't work exactly the same as the one the author used.
But then Paul knows far more about the problem than I do, and if it turns out he's right I'll be delighted.
He tried to kill me with a forklift!
Fuck yeah!
By the way, you'll note it doesn't ask you for a licence key, doesn't say you must be a licenced user, doesn't make you promise not to piss off larry, etc. Ask for help and get help.
telnet bkbits.net 8080
OSDL should have recognized that Linux is a more important project than reverse-engineering BitKeeper and told their employees not to do that on company time/servers or get fired.
tridge didn't do it on OSDL time/servers.
Please acquaint yourself with the history before flaming.
The problem is that many people, like the GP, own a car and incur most of those fixed costs anyhow: initial purchase, time-base maintenance, depreciation, registration, tax, insurance, garaging, road construction. These are fixed, or at least partially fixed costs: insurance costs the same (to me) regardless of whether I drive 100km or 100,000km in a year. (Which is probably an insurance market inefficiency, but anyhow.)
People can only avoid these costs if they can do without a car altogether. For many places in the world you're going to want one at least sometimes (e.g. if working late, or travelling out of town.) To get people not to own a car at all, public transport needs to be a compelling alternative even when it's raining at 11pm on Sunday.
Given that people have spent a large fixed amount to have a car available it's understandable they would want to get a lot of use out of it. Driving an extra 100km has a relatively small monetary cost.
One prong is to encourage people who have cars not to use them. Another is to encourage people not to buy cars: so, have good scooter/bike/motorbike parking, have clean safe and reliable taxis, etc.
Surprisingly enough, people roasting coffee do not just set the oven at random in the hope that it will turn out well. I don't just write invoices randomly in the hope that clients will overpay and not care.
Of course it's possible to have lucky accidents but I wouldn't bet that way.
Economies are not zero sum, except in a reductionist sense that we are eventually all dead. I had a cup of coffee this morning which was produced from less valuable things, rather than being taken from someone who previously had it. The cup of coffee was produced because of intentional effort by a whole chain of people, and likely would not have been made if their decisions were randomized.
Leaving aside pricing, suppose a spreadsheet error caused them to roast the coffee at too high of a temperature, ruining the batch. In what way does that possibly benefit someone? Possibly it creates more demand from the grower but to suggest randomly destroying things so they can be replaced is mere nihilism.
If you consider this too hand-wavey, try playing a computer game with random decisions compared to trying to make good decisions.
I think book-keeping errors really do have a cost. If you unintentionally undercharge then you've inserted a market inefficiency. Suppose because you undercharged, you have a cashflow problem, which then causes a rippling disruption through your suppliers and employees. Suppose you go broke because of spreadsheet errors, and then all your customers can't buy your stuff anymore.
Take your point about PwC and KPMG though.
I had a quick look through and can't spot it, but I remember seeing it and having just the same feeling as with the Register: "he really said that? oh, i see."
what's a petard? And how do you hoist with it?
Yes, that's a very clear way to look at it, and your categorizations are correct.
Larry asserts that's it's impossible to do #2 without doing #3. But then he asserts lots of outrageous things, such as that the existence of this tool will cause damage costing $35k to other people's repositories. (Which to me makes bk sounds really dodgy...)
Sometimes there is a fuzzy line but it seems pretty clear that what tridge was doing #1 and 2. And I think that's morally fine.
Of course it's pretty common for monopolists to get upset with #2.
Linus believes that reverse-engineering of proprietary binaries is not the right way to do things.
That fine, but also irrelevant.
I don't think tridge ever saw the bitkeeper binaries. All he did was look at data files containing open source code.
The principle proposed is that you should not interoperate with someone else's product if they don't want you to. Considering Linux runs on a lot of hardware where it was unwelcome by the manufacturer this is inconsistent with his own actions. Why did he support the sun port when Sun hated Linux?
the inclusion of .doc capabilities isnt the main reason for it and dont compete with MS Word on Linux
So you think OpenOffice is OK, but WordView is not, because it does nothing other than decode Word files? Why?
Or are you saying that the Linux OpenOffice is OK, but OpenOffice on Windows is wrong, because it competes with Office?
Or if he'd written a whole SCM that would be OK, but because he only wrote something that could only pull from bk and decode the result it's wrong?
Tridgells main reason was to circumvent the license for Bitkeeper
Uh, no. His purpose, it would seem, was just to get a copy of the kernel source without using bk. Is that so wrong?
BitKeeper has no monopoly. It may in fact be THE best of breed implementation, but that's irrelevant. Samba had to be done. A reverse-engineering of the BitKeeper protocol just to save time on developing a good approach using OSS is an endeavor with questionable ethical status and really isn't necessary. Also, reverse engineering BitKeeper just so people can access the data is obviated by the fact that they can (someone correct me here if I'm wrong as I haven't tried this myself) use CVS instead to access that data. BitKeeper doesn't need to be reverse engineered to get to the data. Right?
Wrong.
Firstly, Bitkeeper really does have a monopoly. If you want the current version of some kernel trees, the only way to get it was through Bitkeeper. Larry doesn't own the copyright in those trees, but he did control access to them.
Secondly, CVS can't be used to access the data. BKCVS is only available for one tree out of thousands in the world, is often down, corrupt or out of date, and loses a lot of useful information. You can (sometimes) get linus's tree from bkcvs, but not the head of the ppc port or mysql or e2fsprogs or whatever else.
The same goes for the recent "bkclient", except that people report it's even more flaky. One kernel developer said it took a week of trying to get a checkout, so clearly it's not a viable alternative.
For people whose licence has just been cancelled tridge's tool may be the only way to get their work back out.
I agree that *if* the reverse engineering had been merely to take ideas then it might be ethically questionable but that's not what happened.
Larry could have avoided this by providing a decent export command in the first place, but he's refused to do that because he wanted the monopoly. OK, I can see why he wanted that but eventually someone's going to route around the damage.
So, on the whole, I think the comparison to OpenOffice is pretty exact: given that people's own information is locked in a proprietary format it's entirely reasonable to work out how to get it out.
Linux runs on a lot of different hardware. Not every hardware vendor is so enlightened as to contribute open source drivers, and some actively oppose it.
And yet Linux supports at least some of that hardware. How? By reverse engineering it. By poking at it, trying things out, seeing what works, seeing what doesn't. Basically the same techniques tridge would have used on Bitkeeper repositories.
Sun was no friend of Linux in the 90s. They could have made just the same argument: that Linux is stealing their valuable IP by discovering enough about Sun hardware to run there.
But, y'know, that argument is bullshit. Reverse engineering for interoperability is legally protected and morally right.
Remember the very first filesystem supported by Linux was the minix filesystem, which was based on the non-free design of Minix.
Now, perhaps you can say that Linus never wrote any of those drivers himself, but he certainly accepted them into his tree and encouraged people to write them.
Journalists have a rule that anything between quotation marks has to be an exact quote.
Mediocre journalism undergrads, maybe.
Last week's Economist uses almost exactly the same tactic -- to show how hypocritical or inconsistent someone's position is. (I wouldn't be surprised if that was what put Orlowski in mind of it.)
Whether you agree with the Economist's moderate-libertarian politics or not, their journalism and sub-editing is of the highest rank.
The real fault here is not with the Register having a mock-quote, but with Slashdot quoting the Register out of context (which really is a sin.)
How would this be any different if a open-source project died and one needed to transfer files?
Well, the difference would be that open source projects never suddenly cancel everybody's licence. You can always at least use the code to export the data out again. That's why they call it open source.