Arch has changeset support as well, *and* the same distributed repository support as BitKeeper, *and* a dumb server model (keep your repository on any unmodified WebDAV/SFTP/FTP/whatever server), *and* far better platform support, *and* is available under a Free license.
Subversion also has atomic checkins, but it suffers from severe reliability and design issues (read the arch-users list archives for an analysis of the latter).
There already *is* a Free alternative with the same distributed development features, a repository format less prone to random corruption (well, less prone than BK was back in '99 when I used it), a proper dumb server model (use your unmodified WebDAV, FTP or SFTP server as a location for your repository), some exceedingly useful functionality (ie. the "star merge" algorithm) and an absolutely brilliant author who's much, much less of an asshole. It's called arch (and the new C version is called TLA). You should try it.
As for McVoy, my first interaction with him was through MontaVista Software, my employer at the time. We were using BitKeeper for developing Free software, and took advantage of the no-cost license (letting our changelogs be published to BitMover's site). McVoy changed the license such that we, specifically, would be out of compliance -- and terms were such that we were obligated to upgrade to any newer beta and accept its license or cease using BitKeeper. Being much smaller than presently, MVista had to fold and go back to CVS -- and fun that was *not*.
Even forgiving its author's antics, I'm still not fond of arch. Back at the time, its repositories tended to corrupt at the drop of a hat, and grow far larger than need be (particularly compared to the alternative I'll be introducing shortly).
TLA, the C version of Arch (a version control system by Tom Lord), has much more promise. It has the same distributed repository paradigm as BitKeeper, but is under a Free license. It doesn't have the graphical merge tools, but is written such that adding one would be very easy -- and it *does* have some nifty extra features such as the star merge algorithm (which prevents spurious conflicts in the case of multiple branches which are merged back and forth -- a common situation in open source development).
Ever wanted to make your own branch of a project but didn't have write access to the repository? Been annoyed by CVS's lack of support for versioning things like directory moves, file renames and the like? If files are given internal tags in arch, the VCS will even detect file renames *automatically*, without being told at all!
One final, strong, item in favor of arch: The repository format is simple and well-documented, and by its design unlikely to corrupt in ways that can't be fixed by hand. None of the crud like CVS's rewriting,v files (and thus permitting opportunities for a power cycle to kill all of a file's history).
So, to sum up: Arch is nifty. Arch is good. Arch is written by someone who is much less of a $@%#% rat bastard than Larry McVoy. You should try arch.
BitTorrent is good for distributing really big files, not large numbers of small ones (unless folks want the *same set* of small ones). Hence, not useful as an apt-get replacement.
OTOH, maybe the Freenet apt-get integration stuff has a bit more potential...
That would seem an exploitable distinction: Make a low-cost product (a trivial piece of software -- say an applet that pulls publicly available weather info and displays it in the user's taskbar); sell the product for some fairly low amount of money (but more than its actual value), and have a running contest for users of the software.
In that case, the software *is* in effect the gamepiece -- but the ability to reasonably contend that its purchasers pay their cash not for its value as a gamepiece but for whatever small intrinsic value it actually posesses could keep the persons running this out of court.
I'm not so sure that duplicating a CD is illegal. This is known as a backup copy. Oh, you meant in quantity for distribution? That's a different matter.
So are you suggesting that purcase of high-capacity CD duplication equipment should be evidence of copyright infringement?
Damn, that'd throw a kink in the wheels of my friend's band.
We obviously come from different sides of the country.
I grew up in a small West Coast town -- with an airport -- and an airplane flying by was about a once-in-30-minutes event. Then I moved to another, slightly less small West Coast town -- and an airplane flying by was still about once in 30 minutes unless you lived too close to the airport.
Now I'm in Austin, Texas. If you're in the city, sure, there're lots of aircraft about -- but go outside the city (and there's a *whoooole* lot of outside-the-city in Texas) and a plane flying by is pretty damned rare.
Want to carefully regulate rocket launches in heavily populated areas like those you know? Sure, go ahead. But if there's no airport in a 100-mile radius, and no planes scheduled to be overhead within a 1-hr window, then what's the point?
As for the terrorist thing... who would want to use 3rd-party info for targeting, anyhow? But if you're going after a specific target, and you know it's going over a big desolate area (where there won't be any bystanders, quick-responding police force or whatnot), then 3-minute info is still damn useful and every bit as good as realtime.
If the difference between a plane being somewhere it could be hit and not is less than three minutes of flight time, folks shouldn't be shooting off rockets anyhow!
There are lots of places (in nonconjested airspace) where even knowing that no plane is within a 6-minute window provides more than enough of a margin.
Similarly, I don't see how using only 3-minute updates substantially encumbers any halfway intelligent terrorist.
You *do* realize that by coming out and saying that this illegal behaviour is an anticipated or "beneficial" outcome of the scheme you propose, you're making it all that much harder to defend it in court as legit?
Your example might be a little iffy, though -- at least if playing the DVD in its entirety, rather than short segments demonstrating interesting techniques.
"Public performance" is the cutoff point. If you and your good friends are huddled 'round the TV, that's not public. If it's everyone in the building, it almost certainly is. Personally, I don't think the limit's all that arbitrary.
Anyhow, watching it with friends at home doesn't involve making copies for everyone. Yes, maybe I'm just arguing with the presumption of the same arbitrary line you think is so silly... but then, I don't think it is. After all, a line needs to be drawn somewhere with regard to how far these restrictions given to encourage authors and other creators go, and public performance and duplication are fairly clearcut places to draw the line, which permit fairly little abuse but allow quite a bit of legitimate freedom. If you can propose a better standard, fine -- but please, *do* propose a complete, consistant standard rather than just proposing to add loopholes or exceptions to the existing one where they're convenient to you.
One huge difference: While your copy is physically loaned out to a friend, neither you or any of your other friends can use it. You're not making a new copy, you're just passing one around.
Doing the IRC thing, OTOH, you're actually making additional copies which can then be used concurrently. Big no-no.
For corporate downloads of legal content, there's no reason a P2P system need be anonymous. See BitTorrent for an example of that. Having your P2P software handle searching as well as downloads -- well, you could, but why not use a specialized engine for each rather than trying to have one piece of software that Does It All?
Webs of trust? Nice buzzword, not likely to ever happen. Unless you massively centralize the whole P2P network around one registry. And even then such systems are easy to bypass unless you use something like Palladium.
Been implemented before -- and without a central trusted server, and in a very difficult-to-circumvent fashon. See PGP's method for determining keys' trustworthiness.
He got a trojan that redirects DNS queries. Hence, he gets the impression (wrongly) that it's his ISP's server and not his personal machine at fault. So, he THOUGHT that his ISP had a hacked DNS server, but in actuality he just had some spyware screwing with his box.
If it actually got to court (so if the author had the cash to defend himself), he'd probably win: The issue at hand isn't whether they're trying to indicate that their product is in some way similar to Warcraft, but rather whether a reasonable person would be deceived by the name to think that their product is created by the owner of the trademark.
Well, they could have signed an agreement to purchase the product after it became available. They could have funded its development. They could have been {alpha,beta} testers, "partners", whathaveyou.
I'm working for a startup right now, and just because we haven't released yet doesn't mean we don't have customers.
You ignore that a strong DRM system will be breakable even if all the details of how it works are known to the attacker. Remember, the patent necessarily tells *how it works* -- not "how to defeat it".
So what IBM has licensed via SCO is the right to make a UNIX derived from the ancestral code. In any event, losing that license -- should SCO be actually capable of revoking it -- would be rather a Bad Thing for IBM.
Slashdot Mirror
BitKeeper is in use because it's better than the available free tools.
Seen Arch?
Arch has changeset support as well, *and* the same distributed repository support as BitKeeper, *and* a dumb server model (keep your repository on any unmodified WebDAV/SFTP/FTP/whatever server), *and* far better platform support, *and* is available under a Free license.
Subversion also has atomic checkins, but it suffers from severe reliability and design issues (read the arch-users list archives for an analysis of the latter).
There already *is* a Free alternative with the same distributed development features, a repository format less prone to random corruption (well, less prone than BK was back in '99 when I used it), a proper dumb server model (use your unmodified WebDAV, FTP or SFTP server as a location for your repository), some exceedingly useful functionality (ie. the "star merge" algorithm) and an absolutely brilliant author who's much, much less of an asshole. It's called arch (and the new C version is called TLA). You should try it.
Oops. Very fond of arch. Gah.
As for McVoy, my first interaction with him was through MontaVista Software, my employer at the time. We were using BitKeeper for developing Free software, and took advantage of the no-cost license (letting our changelogs be published to BitMover's site). McVoy changed the license such that we, specifically, would be out of compliance -- and terms were such that we were obligated to upgrade to any newer beta and accept its license or cease using BitKeeper. Being much smaller than presently, MVista had to fold and go back to CVS -- and fun that was *not*.
,v files (and thus permitting opportunities for a power cycle to kill all of a file's history).
Even forgiving its author's antics, I'm still not fond of arch. Back at the time, its repositories tended to corrupt at the drop of a hat, and grow far larger than need be (particularly compared to the alternative I'll be introducing shortly).
TLA, the C version of Arch (a version control system by Tom Lord), has much more promise. It has the same distributed repository paradigm as BitKeeper, but is under a Free license. It doesn't have the graphical merge tools, but is written such that adding one would be very easy -- and it *does* have some nifty extra features such as the star merge algorithm (which prevents spurious conflicts in the case of multiple branches which are merged back and forth -- a common situation in open source development).
Ever wanted to make your own branch of a project but didn't have write access to the repository? Been annoyed by CVS's lack of support for versioning things like directory moves, file renames and the like? If files are given internal tags in arch, the VCS will even detect file renames *automatically*, without being told at all!
One final, strong, item in favor of arch: The repository format is simple and well-documented, and by its design unlikely to corrupt in ways that can't be fixed by hand. None of the crud like CVS's rewriting
So, to sum up: Arch is nifty. Arch is good. Arch is written by someone who is much less of a $@%#% rat bastard than Larry McVoy. You should try arch.
Oh, you want to know where? See the arch wiki or Tom Lord's home page.
Have fun!
BitTorrent is good for distributing really big files, not large numbers of small ones (unless folks want the *same set* of small ones). Hence, not useful as an apt-get replacement.
OTOH, maybe the Freenet apt-get integration stuff has a bit more potential...
That would seem an exploitable distinction: Make a low-cost product (a trivial piece of software -- say an applet that pulls publicly available weather info and displays it in the user's taskbar); sell the product for some fairly low amount of money (but more than its actual value), and have a running contest for users of the software.
In that case, the software *is* in effect the gamepiece -- but the ability to reasonably contend that its purchasers pay their cash not for its value as a gamepiece but for whatever small intrinsic value it actually posesses could keep the persons running this out of court.
Third, you may not modify the LGPL or the GPL in any way. It violates the FSF's copyright and is not allowed.
Granted, but that does not prevent an addendum or similar separate document to be used to clarify or modify the copyright holder's intended terms.
I'm not so sure that duplicating a CD is illegal. This is known as a backup copy. Oh, you meant in quantity for distribution? That's a different matter.
So are you suggesting that purcase of high-capacity CD duplication equipment should be evidence of copyright infringement?
Damn, that'd throw a kink in the wheels of my friend's band.
We obviously come from different sides of the country.
I grew up in a small West Coast town -- with an airport -- and an airplane flying by was about a once-in-30-minutes event. Then I moved to another, slightly less small West Coast town -- and an airplane flying by was still about once in 30 minutes unless you lived too close to the airport.
Now I'm in Austin, Texas. If you're in the city, sure, there're lots of aircraft about -- but go outside the city (and there's a *whoooole* lot of outside-the-city in Texas) and a plane flying by is pretty damned rare.
Want to carefully regulate rocket launches in heavily populated areas like those you know? Sure, go ahead. But if there's no airport in a 100-mile radius, and no planes scheduled to be overhead within a 1-hr window, then what's the point?
As for the terrorist thing... who would want to use 3rd-party info for targeting, anyhow? But if you're going after a specific target, and you know it's going over a big desolate area (where there won't be any bystanders, quick-responding police force or whatnot), then 3-minute info is still damn useful and every bit as good as realtime.
There is absolutely no issue importing Word documents written on other machines.
There *are* issues importing Word documents written with other versions of Word, though.
If the difference between a plane being somewhere it could be hit and not is less than three minutes of flight time, folks shouldn't be shooting off rockets anyhow!
There are lots of places (in nonconjested airspace) where even knowing that no plane is within a 6-minute window provides more than enough of a margin.
Similarly, I don't see how using only 3-minute updates substantially encumbers any halfway intelligent terrorist.
If it can help win a lawsuit, someone will have a flunkie or twelve doing research; it'll get found.
You *do* realize that by coming out and saying that this illegal behaviour is an anticipated or "beneficial" outcome of the scheme you propose, you're making it all that much harder to defend it in court as legit?
Being that the experienced intelligence agency is demonstrating the point of the cynical slashdotter, I think the decision is really quite clear.
Well, yes, there *is* fair use.
Your example might be a little iffy, though -- at least if playing the DVD in its entirety, rather than short segments demonstrating interesting techniques.
"Public performance" is the cutoff point. If you and your good friends are huddled 'round the TV, that's not public. If it's everyone in the building, it almost certainly is. Personally, I don't think the limit's all that arbitrary.
Anyhow, watching it with friends at home doesn't involve making copies for everyone. Yes, maybe I'm just arguing with the presumption of the same arbitrary line you think is so silly... but then, I don't think it is. After all, a line needs to be drawn somewhere with regard to how far these restrictions given to encourage authors and other creators go, and public performance and duplication are fairly clearcut places to draw the line, which permit fairly little abuse but allow quite a bit of legitimate freedom. If you can propose a better standard, fine -- but please, *do* propose a complete, consistant standard rather than just proposing to add loopholes or exceptions to the existing one where they're convenient to you.
One huge difference: While your copy is physically loaned out to a friend, neither you or any of your other friends can use it. You're not making a new copy, you're just passing one around.
Doing the IRC thing, OTOH, you're actually making additional copies which can then be used concurrently. Big no-no.
For corporate downloads of legal content, there's no reason a P2P system need be anonymous. See BitTorrent for an example of that. Having your P2P software handle searching as well as downloads -- well, you could, but why not use a specialized engine for each rather than trying to have one piece of software that Does It All?
Webs of trust? Nice buzzword, not likely to ever happen. Unless you massively centralize the whole P2P network around one registry. And even then such systems are easy to bypass unless you use something like Palladium.
Been implemented before -- and without a central trusted server, and in a very difficult-to-circumvent fashon. See PGP's method for determining keys' trustworthiness.
He got a trojan that redirects DNS queries. Hence, he gets the impression (wrongly) that it's his ISP's server and not his personal machine at fault. So, he THOUGHT that his ISP had a hacked DNS server, but in actuality he just had some spyware screwing with his box.
See here.
If it actually got to court (so if the author had the cash to defend himself), he'd probably win: The issue at hand isn't whether they're trying to indicate that their product is in some way similar to Warcraft, but rather whether a reasonable person would be deceived by the name to think that their product is created by the owner of the trademark.
I think that's pretty clearly not the case.
Well, they could have signed an agreement to purchase the product after it became available. They could have funded its development. They could have been {alpha,beta} testers, "partners", whathaveyou.
I'm working for a startup right now, and just because we haven't released yet doesn't mean we don't have customers.
You ignore that a strong DRM system will be breakable even if all the details of how it works are known to the attacker. Remember, the patent necessarily tells *how it works* -- not "how to defeat it".
Same rule applies to strong cryptography.
Err, yes, yer right -- oops.
So what IBM has licensed via SCO is the right to make a UNIX derived from the ancestral code. In any event, losing that license -- should SCO be actually capable of revoking it -- would be rather a Bad Thing for IBM.