BitKeeper EULA Forbids Working On Competition

Col. Klink (retired) writes "BitKeeper's new EULA forbids working on the competition. Larry McVoy has told Ben Collins that he can't use BK because he works on subversion (a free revision control program). In fact, you can't use BitKeeper if you OR your company have anything to do with competing software. Free Software advocates who were upset when Linus decided to use non-Free software now have the opportunity to say 'I told you so.'"

Comments

clarification for a tired dummy

[dirvish]

I don't feel like reading a EULA tonight...by "working on" I assume that means contributing code. Is that correct? It doesn't mean using the program, right?

Re:clarification for a tired dummy

[rseuhs]

Since Bitkeeper is a development package, "using" equals "contributing code" for all meaningful cases.

Re:clarification for a tired dummy

[kasperd]

"using" equals "contributing code"

Yes using BitKeeper equals contributing code to some project . But using BitKeeper does not equal contributing code to a project competing with BitKeeper .

You can use BitKeeper and other version control software for developing software for a completely different purpose (like for instance Linux), the question was what the EULA has to say about that.

I actually doubt this statement in the BitKeeper EULA has any relevance for European users. I guess it is only in America you can legally make such ridiculous claims.

Only the gratis license is affected

[Bartab]

Note that only the use of Bitkeeper for free is affected by this clause. It still seems like this was a bait-and-switch maneuver on the part of BitKeeper, also there seems to be some personal animosity with the Subversion crew.

Subversion isn't quite up to par, yet, but it does seem like the switch to 2.6/3.0 "soon" would be a good time to switch revision control systems to something less... counter productive.

Re:Only the gratis license is affected

[gladiator72]

An excellent time to quote President Zaphod Beeblebrox: "WOW!"

It makes me quiver with abject glee to know with relative certainty that authors of printed publications will never resort to individual licenses (rather than the kind of license that is required to, for instance, make a movie or adapt the story to the stage) that would abjectly forbid any other author or potential author of a book in a similar genre from reading!

Imagine if H.G. Wells would have declared that anyone reading his books would be strictly forbidden from publishing a novel in the genre that would become known as science-fiction.

Imagine if chip manufacturer X were to forbid other chip manufacturers from using their(X) chips or any product that uses their chips in the design or fabrication of the competing chips.

Imagine if you were forbidden from using ketchup in your meatloaf!! AAAAHHHHH!!!!! Hrm... okay. I'm slipping. Heh. Yeah. Anyway.

Regardless of how simple and striaght-forward the BitKeeper product may be, I think Mr. McVoy is forgetting that folks that do kernel development have been using tools such as gcc, as, emacs, vi, lint, m4 thingies, troff, make, info... XWindows (for the love of God!) Needless to say, your average kernel developer is probably not the typical oh-my-i-just-cant-figure-this-out-when-is-bill-goi ng-to-come-and-save-me-with-another-bug-ridden-blo ated-version-of-his-operating-system-so-I-can-get- on-with-what-I-really-want-do
sort of end user. If he really thinks he can bully the egg-head* community in such a fashion, he's either much more brilliant than he's coming off as or his visions of becoming a respected revision control system author are going to intersect quite abruptly with the particular variety of fate known as limited-lifespan (at least as it pertains to projects that have large groups of developers that just might actually work for a competitor).

On a different angle, if the kernel community does not decide to ditch BK for some reason, it will make for entertaining legal stories if/when Mr. McVoy starts having people hauled in. Can you imagine the kinds of goodies that will be drifting through the minds of those junior-assistant-undersecretary-to-the-person-who- brings-water-to-the-one-who-gets-to-deal-with-the- silly-things officer at foreign state departments?

Mr. McVoy, please. I beg of you. Our glorious leader is already making us look extremely silly and annoying to the rest of the planet! Please do not exaserbate the situation.

Praise Cheezewiz...

* this adjective used out of respect

Re:Only the gratis license is affected

[haystor]

Or better yet, write a software EULA to a widely used program that prohibits the practice of law. Then perhaps we might see some effort on behalf of the courts to say that EULA's are unenforceable.

Re:Only the gratis license is affected

[sjames]

I can understand (to a degree) preventing someone from using BK for free to develop a competing product, but to rule out working on competing software period is somewhat more destructive.

Necessity truly is the mother of invention. We invent because of some dissatisfaction with the present way of doing things. To make something that is necessary (or even quite helpful) more expensive for anyone who wants to invent a better replacement is to deliberatly kill innovation.

I imagine that Edison used either oil or gas lights while working on the light bulb. Henry ford probably used some form of transportation other than his feet while preparing to make automobiles. Imagine if they had been unable to afford the increased cost?

I suppose next, we will see OS licenses that disallow use of a computer to develop a better OS, or chipsets that don't allow the development of a new chipset.

"If I have seen further it is by standing on the shoulders of Giants". The BK EULA is like the 'giants' forbidding Newton from standing on their shoulders. Perhaps the oil companies would like to charge $100/gallon if you work on electric cars?

Re:Only the gratis license is affected

[mpe]

Imagine if H.G. Wells would have declared that anyone reading his books would be strictly forbidden from publishing a novel in the genre that would become known as science-fiction.

Or even forbidden from writing a story, play, poem, screenplay, movie, etc which used the themes of time travel, invention, social class, evolution, etc in any way. Just for having read "The Time machine".

Imagine if you were forbidden from using ketchup in your meatloaf!!

You could use katchup with your meatloaf, but never again eat any other product any part of the tomato or a related plant.

Re:Only the gratis license is affected

[sjames]

so, going back to your Edison analogy, i think the oil/gas light industry would have been upset had Edison developed the electric light bulb in their factories/development labs.

That's all fine and dandy. However, the BK EULA goes further than that. It would be more like the oil lamp company offers a free lamp with purchace of oil, but will cost $1000 if you or anyone you work for tries to develop a competing technology, even if that development is confined to daylight hours.

Further, they don't tell you that until after you have already used the 'free' lamp for a while and become dependant on it.

Re:Only the gratis license is affected

[Rik van Riel]

Subversion isn't quite up to par, yet, but it does seem like the switch to 2.6/3.0 "soon" would be a good time to switch revision control systems

Sorry to shatter your dreams, but subversion is fundamentally unsuitable to a project like the Linux kernel. Sure, Linus could export his kernel to the world via subversion, but:

• other developers couldn't use version control for their own development ... or
• other developers would need write rights to the central repository

As you know, neither of these options is acceptable. Linus wants to keep control over his tree while the other developers want to be able to have version control over their own tree.

CVS with diff&patch just doesn't cut it and neither does Subversion. Apart from the missing functionality there's also the speed problem: just imagine 1000 people asking for revision history of the kernel tree at once...

An alternative for bitkeeper really would need to be a distributed source control system, where each developer has his/her own repository locally and can push changes to (or pull changes from) other developers easily.

Re:Only the gratis license is affected

[sjames]

The buggy whip and oil lamp manufacturors of the world thank you! After all, if stifling innovation is such ways was during the industrial revolution, we might still be trying to get it going.

Imagine a world where you can't buy anything at all, only rent it for life provided you meet a few piddlingly small requirements....

Honestly, that's the way things are going these days. In order to evaluate what is right, we have to consider the effects on society and progress as well as individual rights.

Consider a similar scenerio: The bank holding your mortgage informs you that the interest rate will be 5%. Unless you enter into competition with one of their investments, then it will be 24.5%. Naturally, they decide what constitutes competition. That decision is subject to change without notice, of course.

What does BitKeeper exactly do?

[phr2]

Could someone please post a feature list of what BitKeeper does that comparable free programs don't? There may be such a list already, so a url would be fine. It's time for free source control programs to get whatever capabilities that they're missing. Since I've never seen BitKeeper myself, I'd like to know what new stuff needs to be implemented.

Re:What does BitKeeper exactly do?

[kryps]

Hi!

You can find a probably biased comparison here:
http://www.bitkeeper.com/Products.Comparisons.CVS. html

-- kryps

Re:What does BitKeeper exactly do?

[g4dget]

CVS is quite powerful and fast. I think just about any project for which CVS is not powerful enough probably needs to be broken up into larger numbers of independent source trees and groups of developers. And, yes, I include the Linux kernel in that assessment.

Re:What does BitKeeper exactly do?

[pediddle]

Yes CVS is powerful and fast, but anyone who uses it long enough knows there are just some CVS features that are hacks. Binary file support for one example, renaming files, and the biggest of all, renaming directories. If you can make a project that never has to reorganize in its history, then you are some kind of diety.

The reason Subversion, BitKeeper, and a whole host of other next-generation SCM products are being developed is because CVS just plain doesn't cut it for most serious development. It works, but not nicely.

Subversion is not distributed, so while having independent, distributed source trees is a nice feature of BitKeeper that some projects require, it is not the only reason to switch.

Re:What does BitKeeper exactly do?

[tomlord]

> he was under the perception that the so-called
> "community" would donate enough money to allow
> him to accomplish that.

No, I wasn't. The community did keep me afloat for longer than I otherwise would have been, while I worked on getting corporate funding for a small team to finish and polish the hell out of arch.

Now an interesting question becomes: what does the bitkeeper license imply to IBM, HP/Compaq, Red Hat, Suse, Mandrake, and other businesses that depend on the linux kernel?

This event points to a more general problem: the free software business world needs a better infrastructure for all projects, not just the kernel. Now they have one more reason to believe in the urgency of this need.

Re:What does BitKeeper exactly do?

[kryps]

Good to hear. Is there a website where I can track the progress of arch development?

-- kryps

Re:What does BitKeeper exactly do?

[tomlord]

> Is there a website....

No. I didn't say that commercial support has been found. It hasn't.

Re:What does BitKeeper exactly do?

[gehirntot]

This event points to a more general problem: the free software business world needs a better infrastructure for all projects, not just the kernel. Now they have one more reason to believe in the urgency of this need.

At least for content management systems, there is a very solid CVS replacement:

OpenCM.

One of the many features of OpenCM is cryptographic integrity protection.

Go, read their webpage.

Re:What does BitKeeper exactly do?

[Jordy]

BitKeeper does have one feature that I consider worth the price of development, simply because I haven't found it anywhere else. Each developer has a full-featured repository on their machine.

This means that you can get on a plane, disconnected from the world, start working on your laptop and commit, revert, branch, etc. Once you get back to an internet connection, you can easily sync back to the main repository and have all those lovely change messasges transferred with you.

Re:What does BitKeeper exactly do?

[rodgerd]

It implies that RedHat cannot, for example, patch an exploit in CVS and ship it any more. It could even be said to imply RedHat can't ship CVS - in as much as they modify vanilla CVS in order to package it.

Re:What does BitKeeper exactly do?

[g4dget]

Binary file support for one example,

It stores and versions them--what more do you want?

renaming files, and the biggest of all, renaming directories.

Renaming files and directories is already pretty straightforward in CVS. But since there is no explicit command for it, many people seem to think it's hard. Adding a "cvs rename" would be easy--no reason to throw out the entire system and start from scratch.

Re:What does BitKeeper exactly do?

[mirabilos]

Binary works kind of well.

Renaming (in general) sort of works, but you lose
the earlier names, or the history. I usually mv the
RCS files if it's not a big deal.
Also, with a bit of inter-developer action, you
could tag the tree before the rename, and after,
so everyone could diff his changes. Oh, wait.

You missed the big scary missing point of cvs
(after renaming): disconnected operation.

See, a developer at flight cannot simply check in.
Even if he has a local copy of the master repo, he
would need to preserve it, etc etc, with many
hassles.
I first encountered it getting the OpenBSD source
via CTM, by retrieving
the full repository. CTM cannot update any more when
you modificate the files (ok there is some mechanism
to circumvent that, but xxx,v.ctm is just ugly).

Some OpenBSD developer told me in IRC (#OpenBSD on
OpenProjects.net (www.freenode.net)) that they will
switch to OpenCM in some years when it is more mature.
(it became a port some days later...) which is said
to be better. They will not use any of the other CMS,
he added.

Maybe this helps.

Re:What does BitKeeper exactly do?

[Just Some Guy]

Are you still wanting to work on arch? Do you still need hosting? If so, I can probably donate some storage and bandwidth. Drop me an email if you can use my resources (consumer-grade though they may be).

Re:What does BitKeeper exactly do?

[g4dget]

In CVS, if you rename a directory, there's nothing that keeps track of the old name,

Sure there is. You rename by deleting the old file and adding it as a new file. It's simple and all versions of the software are consistent.

An explicit "cvs rename" command would basically do just that, but it could have a few more convenience features (linking logs together, handling directories automatically).

If you "mv" around files in the CVS directory, on the other hand, your repository will be inconsistent. Don't do that.

For what a EULA is worth

[Teun]

(without having read the "New EULA")

It's a New EULA, so the old one did not mention it?
The solution is simple: continue to use your existing version.

Re:For what a EULA is worth

[Florian Weimer]

It's a New EULA, so the old one did not mention it?
The solution is simple: continue to use your existing version.

The old EULA is revoked automatically as soon as Bitmover changes the Bitkeeper test suite so that the old version no longer passes it. In essence, this means that Bitmover can revoke old licenses at any time.

IANAL, but I know I can't rely on Bitkeeper (the vendor doesn't want me to, obviously). Maybe the commercially sold version is different, I don't know.

Bitkeeper is probably really nice software, so we can only hope that Red Hat (or someone else) buys Bitmover one day and licenses Bitkeeper under the GPL.

Re:For what a EULA is worth

[XaXXon]

Unfortunately, this as been in the EULA for at least 6 months. Not sure where I read it, but it's in the mailing list archive.

Also, as was mentioned earlier, if you're using the free version, BitKeeper forces you to upgrade as newer beta versions come out.

On a personal note,
Man, this really sucks. BitKeeper is cool, but man, I don't want to deal with it not being free, much less major restrictions on who can use it within the limitations put upon the free version. I'd be happy to see Linus come back and say "no" to bitkeeper and push it back into obscurity forever..

Re:For what a EULA is worth

[Florian Weimer]

Buy Bitmover and release Bitkeeper under the GPL? You want to reward him for this sort of behavior? I'd rather direct my goodwill wishing at someone or some company a bit nobler.....

What behavior? Actually, I'm not sure if Larry McVoy is the evil guy here. He couldn't do any harm to the free software community if people playing key roles in the community weren't using his software (thus forcing others to do so as well).

Re:For what a EULA is worth

[cduffy]

BitKeeper, back when I used it (2-3 years ago) had some nifty features, yes -- but was prone to corrupting the repository on a regular basis. What's more, Larry deliberately changed the license so that my then-current employer was no longer in compliance. Suffice to say that more than a few people there still consider him an asshole for that.

If Red Hat is going to put money into a better version control system, I'd hope that that would be either Subversion or arch. (The author is flat broke and has no web hosting unless someone gives him some, so that link may not work; also see here and here). Arch is brilliant, functional, much more reliable than BitKeeper (at least, much more reliable than BitKeeper was when I used it)... and for someone as utterly friggin' brilliant as Tom Lord to be utterly penniless (as in, unable to buy beer, much less pay rent) is just wrong.

Re:For what a EULA is worth

[Florian Weimer]

Otherwise, what's the next license change going to look like?

I agree that the hidden relicense clause is quite obnoxious, and it's something I can't deal with. I need version control badly, and I can't suddenly switch systems just because the vendor decided to change the license in some obscure way, making it unacceptable to me.

However, it's funny that you bring up Perforce in this context. Perforce grants gratis licenses for free software development for just one year. After this time period, the licensed apparently has to be renewed.

Re:For what a EULA is worth

[Rik van Riel]

I'd be happy to see Linus come back and say "no" to bitkeeper and push it back into obscurity forever..

Even if Linus stops using bitkeeper, I won't.

I'll only stop using bitkeeper the moment an equivalent free alternative to bitkeeper is available.

Flaming me won't change my decision, making a free alternative to bitkeeper available will.

Re:For what a EULA is worth

[tomlord]

> and for someone as utterly friggin' brilliant as
> Tom Lord to be utterly penniless [...] is just
> wrong

Of course, I strongly agree.

> (as in, unable to buy beer, much less pay rent)

I am as happy as one can be under these circumstances to report that, much to my surprise, I was able to buy both this month's rent and this week's beer on the last dribs and drabs of a friend's credit. But, yeah, it's pretty bleak.

But, hey ... I've got this kick-ass business and technology plan here for companies like Red Hat and all the unix vendors.... free software is _good_ for business, and I'm doing my damndest to make things work. (Hey, Scott McNealy, let's do lunch (you're buying):-)

Re:For what a EULA is worth

[Rik van Riel]

... thus forcing others to do so as well ...

Bitkeeper uses the open SCCS data format to store all its data. The Linux kernel source code is available in a half-dozen other ways than bitkeeper. Linus accepts (prefers!) patches sent the oldfashioned way.

I have no explanation other than ignorance or mass panic for the phenomenon that happened here on /. today. There simply is nobody forcing people to use bitkeeper, the only reason to use bitkeeper is that it's the best tool out there.

They can... if they purchase it!

[kryps]

Hi!

If the submitter had followed the thread on LKML more closely he would have realized that it is only forbidden to use the *free* (i.e. openlogging) version of BK to develop a competing product. They can still *purchase* a commercial license and develop whatever they want with it.

-- kryps

Re:They can... if they purchase it!

[kryps]

Hi!

Well this is quoted from the free license. The commercial license does not include this section.

-- kryps

Since when?

[Eudial]

Since when does ppl acutally read the EULA?

the path of least resistance

[patSPLAT]

The Subversion folks would like nothing better than to displace BK.

Larry McVoy has an entirely reasonable business concern. He has also now provided the momentum for that concern to materialize. This may provide the motivation for Subversion to produce the cvs.succ that we all wish for late at nights, writing posts such as this one.

~ pS

Re:the path of least resistance

[g4dget]

Larry McVoy has an entirely reasonable business concern.

Yes, but it is just as reasonable for open source users to reject such software. Merely making software available for free under some license does not obligate anybody to use it or open source advocates to defend it.

Not possible

[Anonymous Coward]

AFAIK, free users have to always use the latest version since they are beta testers at the same time. It should be in the license (I haven't read it though). At least Larry explained it like that in l-k mailing list.

Re:Not possible

[dillon_rinker]

Nope. If the license says so, it can be changed at any time, even retroactively.

Why don't they use standard CVS?

[caluml]

What was the reason behind not using standard CVS like other OSS projects?

Is the kernel just too big for it?

P.S. I don't have an opinion as to which oen they use - as long as the one they do use gets the job done, and is secure.

Re:Why don't they use standard CVS?

[ewhac]

CVS has too many inherent limitations to make it a good choice for large-scale projects. Although it's been around for just ever and is fairly solid, there are a couple of issues that make CVS a sub-optimal choice.

First, CVS is built on top of RCS and, as such, doesn't handle binary files. Okay, that's a fib; it sorta kinda does, but it's very klunky, and easily prone to errors. Further, it's easy for the "binary-ness" of a file to be lost (i.e. be treated as text), resulting in all kinds of nasty corruption. Best Practices will avoid this, but everyone has to be on their toes all the time.

Second, CVS has no notion of "transactions". Let's say you check in a bugfix/new feature to the kernel. The change involves modifying six different files. CVS does not see this checkin as a single transaction, but six completely separate ones. So a lot of information about the scope of a given change is not easily found. The only way you can know a particular change affected multiple files is by noticing that their checkin comments are identical. Further, if you perform a checkin against multiple files and one or more of them has a conflict (someone else checked in a change before you did), CVS will simply halt at the conflicting file; earlier files successfully checked in up to that point are not backed out. Thus, the repository is left in an inconsistent state. Best Practices can avoid this but, again, everyone has to be on their toes.

Other source control systems don't have these problems. In particular, Subversion is transaction-based, so groups of files checked in at once either all get checked in, or none of them do, keeping the repository consistent. Also, Subversion handles arbitrary meta-data for each file, including its MIME type, so the "binary-ness" of a file cannot be lost or modified unless you expressly change its MIME type. Even better, Subversion will automatically perform newline translation to/from your local platform when checking out/in text files.

For small projects with small numbers of people, CVS is perfectly okay. But beyond a certain scale, CVS's limitations start to get in the way, and you need something better.

Schwab

Re:Why don't they use standard CVS?

[theefer]

Yes, and there are others points :

- CVS cannot move files and keep a track of the log.
- CVS directory handling is quite horrible

Now, I use CVS as everybody else here does, it works, sure. But there are some problems that should be fixed (and cannot be because of the CVS base), that's why I'll probably switch to Subversion soon. It's still under heavy development, but it gets better from day to day.

Let's support some free software instead of proprietary ones !

Re:Why don't they use standard CVS?

[kevin lyda]

you made a lot of good points until the small projects with a small number of people bit. that's crap. free and open bsd use cvs for one thing; they are not small.

cvs works for developers with a clue about cvs. that's not to say that a better version control system couldn't be developed - one can and should. but saying cvs is crap for large projects is demonstrably false.

Re:Why don't they use standard CVS?

[ebyrob]

Ya, multiple repositories is certainly an interesting concept, but...

Isn't that why CVS requires you to update the things you want to update when you want them updated? Under CVS it is essentially each developer's responsibility to update their checkouts to the version that is appropriate for them. It would seem that under CVS this team of 5 would have their own branch or product that had incremental and "nightly" releases. No one else is obligated to use the "nightly" releases, instead waiting for tagged stable releases. However, if there is only a single repository then the information becomes available to everyone immediately rather than waiting for multiple merging processes to go on in the case it is ever needed outside that group of 5...

Re:Why don't they use standard CVS?

[shlong]

free and open bsd use cvs for one thing; they are not small.

Actually, most of the interesting, complicated, and/or highly distributed work in FreeBSD happens in Perforce. The only thing that CVS gives us that Perforce doesn't have is the ability to replicate the repository. Unfortunately, that's also 90% of the reason why haven't fully switched over to Perforce.

Re:Why don't they use standard CVS?

[pongo000]

First, CVS is built on top of RCS and, as such, doesn't handle binary files.

Give me one good scenario in which a version control system would be the appropriate place to archive binaries.

I believe you are trying to use the wrong tool for the job.

Re:Why don't they use standard CVS?

[dvdeug]

Give me one good scenario in which a version control system would be the appropriate place to archive binaries.

If you import your whole source into CVS, what happens to the png's (e.g. icons) that are in the directory? A version control system may not be able to do much with them, but the least it can do is not mangle them.

Re:Why don't they use standard CVS?

[timeOday]

I like to keep documentation under revision control, and part of documentation is images. Also bitmaps for toolbars etc. And for that matter Word files. (Yes, it's suboptimal because you can't usefully compare revisions if you consider them binary files, but at least you can keep all the old versions around).

Re:Why don't they use standard CVS?

[dubl-u]

Give me one good scenario in which a version control system would be the appropriate place to archive binaries.

1. When developing Java code, I always check in all the libraries my project depends on. That way any developer can build the whole thing by just checking out the project.
2. Often projects have raw data included; often the best way to store that is in binary.
3. When developing web sites, I check in images.
4. In my documentation for almost any project, I often include all sorts of diagrams.
5. I know of a project that checks a whole copy of Tomcat in, so that they have a clear reference platform in the repository. That makes automated testing much easier.
6. Some people will use their repository to check in full compiled versions, so that they can easily get a copy of whatever it is that they shipped.
7. Oh, and let's note that not everybody happens to speak a language that fits well into 7-bit ASCII; maybe they would like to check in something that they think of as "plain text", even if CVS doesn't.

And that's just off the top of my head; I'm sure others could suggest more.

The question should really be, "Why should a version control system be allowed to insist that I only use 7-bit ASCII files?"

Re:Why don't they use standard CVS?

[Kaz Kylheku]

Transactions are highly overrated, and the lack of them doesn't pose a serious problem to CVS users at all.

When a group of files are commited together, that information is not irretrievably lost. Tools exist which can extract these change sets out of CVS; for example Karl Fogel's cvs2cl perl script. There are some hacks involved, such as looking at ranges of timestamps, but it works.

It's possible that a network failure can interrupt a CVS commit. That isn't much of a problem; you simply reestablish the connection and complete it. This doesn't pose any serious problem to your configuration management process. In principle, CVS could be modified to do commits in two phases; in the first phase, build up the files to be committed, and in the second phase, rename them over top of the original ones, rather than doing this file by file. That would require a lot of extra disk space for large commits, with no real benefit.

I have developed a project which addresses many of the real *semantic* issues of CVS version control, by layering a little bit of clever software on top of the CVS client. Meta-CVS versions the directory structure, symbolic links, execute permissions and property lists attached to objects. See http://www.freshmeat.net/projects/mcvs. Meta-CVS also simplifies branching and merging, handling all the tagging to keep track of what has been merged where. These are the number one and two pains in CVS: lack of support for renaming, and branching that requires the explicit, tedious management of irrelevant details. Add these on top of CVS and you have a pretty decent version control system.

Re:Why don't they use standard CVS?

[pongo000]

All good comments, but save for one, no one really justifies the use of version control software as the appropriate place to archive binaries. The beauty of VCS is that the revisions themselves are not saved, but the deltas between them. Saving binaries under VCS serves to do nothing mor than bloat the repositories with data best archived elsewhere.

Re:Why don't they use standard CVS?

[gorilla]

I'd say that the saving of deltas is an internal detail, which the user of the VCS shouldn't need to be aware of.

VCS system are used because it makes management of development easier. Including the correct binary files is part of that making easier.

Re:Why don't they use standard CVS?

[spitzak]

Although CVS certainly has problems, I have had not trouble with the "lack of transactions". At least the version I use checks for conflicts before checking anything in.

Biggest problems: the inability to rename or mv files.

Second biggest problem: getting around the inability to rename files involves deleting files and it seems it often goes bonkers here. These seem to be bugs like where it insists that a file is in the repository but will not check it in and refuses addempts to add or remove it.

I have also had trouble with their transactions, if it crashes (esp with SourceForge) in the middle it is left "locked" and nobody can do anything. And you can never get rid of a subdirectory.

I would like to see a new system that treats the entire project as a single "file" and allows changes to be tracked not only across the renameing or moving of files, but also the splitting and joining of files and the movement of large blocks from one file to another (this last one may be hard...)

Re:Why don't they use standard CVS?

[ebyrob]

Past .1 the project should always build.

It may not build the version with all the features you want that is current development but it should always build. Tags combined with testing and knowing what you are doing are enough to accomplish this.

There is no way each developer needs their own branch. Each developer can check out the repository on their machine and do whatever testing and what not they need to do locally. Checking in to CVS *is* the act of remerging your changes back into the larger project.

A checkin goes as follows:
0) Test. You should have already fully tested all your changes with what was previosly checked out to be worked on.

1) Update. This is to see if anyone else has "beaten" you and checked something in while you were working. It should be assumed that whatever is currently in CVS is currently working. If this assumption is false it's red flag time and whoever checked in something that didn't work is in deep doo doo. (If no updates have occured, skip to step 3. )

2) Test with updated version.
If any updates have occured, then everything needs to be retested before checkin. (Now go back to step 1)

3) Commit. Check those puppies in and make sure you put in the right comments or you'll keep getting asked about stuff.

4) Test. One last time you should check out whatever has been committed (proabably to a new location) and test it all again. This is to cover your own butt and be sure you don't wind up in deep doo doo from someone else's step 1.

5) Always remember, you are the only one responsible for the changes you make on your own machine. If someone else makes changes that make your changes invalid and your time is wasted then communication has broken down. CVS job is to facilitate communcation. In this case, it did by notifying you there is a problem. Your job is to solve the problem.

Note: many houses actually pass around a "checkin token" to avoid getting in an update/test/update cycle while someone else is committing changes. This does put an upper limit on number of developers that should have CVS access to a particular set of files. (5-15?).

IMHO having more than 10 individuals responsible for a single file (or even sub-project) at the same time should be enough to scare anyone...

Re:Why don't they use standard CVS?

[JamieF]

There's a race condition in that process between steps 1 and 3, that I think you are partly aware of since you have a step 4.

On small to medium-small projects CVS works OK. (It's why my employer uses; despite CVS's hideous usability problems, it's free and once you learn all its quirks and limitations you can get work done and it doesn't get in your way much.)

But on a medium project, you can get into problems where you do an update, merge, test, and then commit, and (because commits aren't atomic) still you end up with a half-checkin that stopped due to a conflict, and suddenly the head won't build. So you return to step 1 and fix it. Whew, that was scary. But for a moment, it *was* broken, even though you followed the process.

Now all you have to do is scale up x10 or x100 developers (and maybe x10 or x100 lines of code) and you can imagine that it would be broken frequently. The better other developers are about updating often, the greater the chance that they'll grab the broken code, try to work with it, build, and wonder WTF they did that broke it. Super loss of productivity, all because of one stupid feature that nobody even cares about unless they're on a large project.

And then there must be some project size (probably OS scale or something similar) where this problem is so bad that you basically can't get any work done at all because you're just treading water trying to get the changes merged and working. At that point CVS becomes totally out of the question.

Re:Why don't they use standard CVS?

[ebyrob]

Ya, there are issues in useability and what not with CVS.. (although I've never used a source control tool that I actually thought was easier for small projects)

The lack of atomicity really is the most critical feature missing in CVS. I suppose when I've worked on projects over "small/medium" size I'll consider that one even more important.

The "checkin token" does avoid this race condition because doing a commit after an update will always work if you're the only one commiting at a given time. The reason for step 4 is not to avoid a race condition in update/checkin, but to validate that what you thought you checked in was checked in properly and that any tags/branches are still valid and capable of building properly. It is also a "double-check" to be sure that things weren't missed in an earlier test/build phase.

When a "checkin token" is not used, the race condition is simply risked and only if it occurs does everything stop while one person (or group) sorts things out.

Of course, working for a small company I don't really see what happens when there are say 100 developers working on a project. Perhaps the needs are special perhaps it just requires specialization and proper management.

Bottom line, I have to wonder about farming out something as important as source control to another company. BitKeeper is willing to move people off of CVS. Who is willing to move people off of BitKeeper when they need it?

Too bad.

[7-Vodka]

It seemed like bitkeeper was working out quite well for the linux kernel. I liked the detailed changelogs that started apearing after the switch.

Hopefully one of the teams working on Free alternatives will get it to a stage suitable for maintaining the kernel.

I wonder what they'll be using when linux 4.x rolls around? Maybe linux will still be using bitkeeper and the HURD will be using something like subversion (assuming the HURD becomes easy enough for us mortals to use by then :)

I'm hoping that by the time I wake up this afternoon there will be interesting comments by the top kernel hackers, the FSF and Linus about this.

Illegal

[giminy]

Forgive me if I'm stupid, but doesn't an EULA say what you can and can't do with respect to the product that the EULA covers? Reverse engineering and stuff like that are, grudgingly, acceptable terms of an EULA, but saying you can't do something that is not directly related to the software program covered by the EULA seems a tad on the side of illegality.

I have a feeling that if anyone challenged the agreement, the law would force it to change. Granted you have to accept the EULA in order to use the software...but if I made a EULA that said you were no longer allowed to own a firearm if you used my product, it would be tossed to the wind in a second. In a sense, Bitmover's EULA infringes on my right to compete, yes/no? If Bitmover doesn't want people to use an idea they have, they should file a patent for that idea, or otherwise rely on copyright/trademark law to prevent people from "stealing."

Re:Illegal

[a_n_d_e_r_s]

The sad part is that many software companies tries to control HOW you use the program, WHO uses it and WHAT they use it for.

The gargantual licenses used by software companies nowadays are taking ridiculous proportions.

We are all lucky that RMS once upon a time came up with the GNU GPL to ensure end users rights and that at least some software gives you a lot more freedom that restrictions.

Re:Illegal

[orkysoft]

Well, basically, what they're saying is: "We made this neat program, which you can use, but in return, you have to promise you won't compete with us."

If this clause had always been in the EULA, there would have been no problem: people would've known what they were getting into.

But now, apparently, the clause has appeared in a revised version of the EULA, which would now force users to switch if they find the new terms unacceptable. This is obviously not a nice practice.

Re:Illegal

[Bartab]

As has been pointed out, non compete licenses are illegal. Refusing to do business with competitors is illegal, etc, etc.

However, BitKeeper isn't saying they won't -sell- licenses to competitors. Just that competitors can't use the free license. The Commerical license does not have the problem clause.

Re:Illegal

[Mnemia]

Yeah, it's the whole bait and switch aspect of this that's worrisome to me. As much as I disagree with the idea that any company should be able to tell me what I can do with something not related _directly_ to their product, I could accept that if they had said "this is the deal" right at the start, and let people make an informed decision about whether they were willing to be bound by that. But they've clearly just done this to lock people in and then try to squash competition. A very Redmondian tactic if you ask me.

Whatever happened to the idea that software should compete on its merits rather than by trying to hobble its competitors? I say, the sooner we have a functional replacement for this, the sooner we will be free of onerous and unfair practices like what's going on here.

Reading the LKML thread, the recurring theme was "we just don't want to help our competition for free". But the misleading, deliberately or not, thing about saying that is that the actual clause goes far beyond just prohibiting the use of BK for direct use in developing Subversion, for instance. It actually stops you from using it when you are simply working on an *unrelated* competing project that does *not* use BK. Frankly, that's not their business to decide and is designed as a way to siphon off developer support for these other projects by forcing a choice between say the kernel and Subversion.

I think the best legal attack on this clause would be to say that they are being discriminatory in who they license to since first-sale probably doesn't apply when they give it away.

Re:Illegal

[standards]

if I made a EULA that said you were no longer allowed to own a firearm if you used my product, it would be tossed to the wind in a second.

How so? I will contract with you if you do not own a firearm. If you do own a firearm, I will not contract with you.

What's so illegal about that? I am not the US government, but a private person. Unless the discriminatory action is clearly specified in law, I can discriminate against you all I wish.

I don't think there is a law that says I, as a private individual, can't discriminate against gun owners. If there is, please let me know. And please don't bother to quote the constitution - that's for discrimination by the Federal gov't.

Re:Illegal

[UnknownSoldier]

> ...but if I made a EULA that said you were no longer allowed to own a firearm if you used my product, it would be tossed to the wind in a second.

Not quite. You're uninformed on contract law:

1. You can contract your rights away. That is, private contract law can *supercede* the constituional rights. (Note: That illegal contracts, such as a contract for murder is void, since you never had the right in the first place to kill someone.)

2. A contract is based on "reasonable" terms. If you believe a stipulation is not reasonable, and broke the contract as a result, a judge has to figure out what was reasonable.

3. If the contract was agreed upon voluntantiy AND not under duress, then it is legal. Note the AND! Otherwise it is null and void.

Now as to whether the EULA constitues a legally-binding agreement (since you never signed it, or verbally agreed to it), is still up in debate. Although I believe there have been a few recent rulings. One said it was, one said it wasn't.

Cheers

Re:Illegal

[ameoba]

If Sun's licence for Java has gotten away with preventing the publication of benchmarks & its use in nuclear power plants, this isn't much of a step beyond that...

Re:Illegal

[Reziac]

But this sounds more like "If I contract with you, I'll wait til you are thoroughly dependent on our product, then at some arbitrary time I will suddenly change the contract so that you must throw away all your existing firearms, even if you need them."

You can't unilaterally and retroactively change the terms of a contract -- if you do, that gives the other party the right to vacate the contract, because it is no longer what they agreed to. IF an EULA is an enforceable contract, then it falls under normal contract law -- and that cuts both ways.

I'm not being very clear here, but you get the idea.

Re:Illegal

[gilroy]

Blockquoth the poster:

You can contract your rights away. That is, private contract law can *supercede* the constituional rights.

You can contract away some of your rights. Courts have held that there are rights you cannot waive in a contract.

Re:Illegal

[pongo000]

I don't think there is a law that says I, as a private individual, can't discriminate against gun owners. If there is, please let me know. And please don't bother to quote the constitution - that's for discrimination by the Federal gov't.

Please refrain from undermining your arguments with baseless assertions. Courts have upheld the Constitution in many cases that do not involve the Federal government. Illegal search and seizure? Applies to local governments as well. Due process? Can be extended to local school districts. And on and on.

Re:Illegal

[mpe]

One cannot contract away protections provided by law (including those enumerated in the Constitution and the Bill of Rights). That is very clear. As for this EULA, if it's found to interfere w/ interstate commerce (and it probably can be interpreted that way), the Feds will be happy to get involved.

Many EULAs contain clauses to the effect that all disputes must be handled under the law of a specific place. Presumably that would satisfy that condition. Or if the user was outside the US it would automatically be a federal matter.

Re:Illegal

[mpe]

Okay, one other thing I've been wondering about. I read somewhere that to be valid a contract has to include some form of future payment. In other words, both parties to the contract have to gain something from the contract.

The legal term is "consideration" which simply means that something of value (or at least something which all parties agree is of value) must be exchanged.

Re:Illegal

[blibbleblobble]

"You can't unilaterally and retroactively change the terms of a contract"

Can't you? Lawyers at most software companies, and even most websites think that you can.

Why isn't my software listed on TuCows? Because their user agreement would have required me to automatically accept any unilateral changes to their contract. Yahoo, hotmail, passport, ebay, are all the same.

That type of contract is like signing a blank cheque (which also has no legal protection), and if you see such a clause, don't agree to it. Most places will relax a EULA or ToS if people make it clear that they will not accept the condition, and if not, it's still not worth the risk of agreeing to the contract.

Re:Illegal

[the gnat]

I believe that's because of the 14th amendment- local governments (or their agents, including schools) are not allowed to violate your rights under the constitution. They can provide additional rights, but not revoke those granted by the federal government. Thus the US Supreme Court can rescind state laws, or change the verdict or sentence in a death penalty case (the majority of which are not federal).

Private individuals, however, are not under the same restrictions. I'm not sure what the source of the ban against racial discrimination is; I think the SCOTUS has struck down laws that mandate it, but additional laws (state or federal) prohibit certain types of discrimination by individuals. Other things such as gay rights laws, where they exist, are local. I've never seen a law about firearm owners, though.

Re:Illegal

[Reziac]

A very good comparison -- agreeing to a retroactively-alterable contract or EULA is indeed like signing a blank check, and perhaps that's precisely the analogy needed to open eyes about the dangers (especially to business) of such EULAs/contracts.

Re:Illegal

[sql*kitten]

I don't think there is a law that says I, as a private individual, can't discriminate against gun owners. If there is, please let me know. And please don't bother to quote the constitution - that's for discrimination by the Federal gov't.

There are plenty of laws that say that private individuals can't discriminate, it just so happens that gun owners aren't protected (at present). If you refuse to contract with gays, blacks, the disabled, etc, you will find yourself in a lot of trouble. You can't even say "abusive" things these days, right to free speech does not protect you from committing a "hate crime" - attacking a man is assault, but attacking a man an also calling him a "nigger" is judged much more harshly.

I can hear RMS now ...

[Strike]

... saying "told ya so!"

RMS was right

[raahul_da_man]

Many slashdot posters seem to think Richard is just a voice crying out in the wilderness, but increasingly he seems to be a prophet.

Many years before this happened Richard pointed out the flaws of relying on non free software. Will any of the slashdot posters who called him crazy then apologize now?

Linus is wrong and Richard was right. You can't be "pragmatic" and use the best tool for the job if you want to keep your freedom.

Re:RMS was right

[Subcarrier]

Linus is wrong and Richard was right. You can't be "pragmatic" and use the best tool for the job if you want to keep your freedom.

Pragmatic, according to Linus, means freedom to choose the best tool for the job from the available alternatives.

Adhering strictly to the free software ideology limits your freedom to do so. Which is fine, as long as you recognize that this limitation to your freedom is self-imposed and that others may not be bound by the same limitations.

Re:RMS was right

[albalbo]

Many slashdot posters seem to think Richard is just a voice crying out in the wilderness, but increasingly he seems to be a prophet.

Absolutely right. Lest we forget, EULA clauses not allowing people to develop competitive (esp. Free Software) products is something Microsoft does. And they were rightly derided for that. Are we saying just because Bitmover are giving away free stuff that we're not going to apply the same standards?

Re:RMS was right

[nagora]

Many slashdot posters seem to think Richard is just a voice crying out in the wilderness, but increasingly he seems to be a prophet.

The real problem is that RMS may or may not be a prophet but he insists on acting like god and pissing off people just by his tone. The real message gets lost in the ensuing flamewar. Overall he has become counter-productive to his own aims

TWW

Re:RMS was right

[nagora]

How has RMS's message been counterproductive?

Read my post again; his message has not become counter-productive, his manner has. The whole irrational GUN/Linux argument has convinced a lot of people that anything RMS says can safely be ignored as the rantings of a crank. This is in turn hurting the GPL. The fact that anyone ever considered using BitKeeper is a sign that the message of why the GPL is so important to programmers working on projects like the kernel has been lost in the noise somewhere.

TWW

Re:RMS was right

[nathanh]

Many years before this happened Richard pointed out the flaws of relying on non free software. Will any of the slashdot posters who called him crazy then apologize now?

No, they won't.

Hating RMS is a religion. Facts don't faze the fanatics.

Re: RMS was right

[Black Parrot]

> Hating RMS is a religion.

For agnustics?

Re:RMS was right

[ebyrob]

Well... the fully free alternative definitely must exist, and I'm grateful that Mr. Stallman saw fit to undertake that task. It also shows great foresight (or stubborness) that the GNU project continues to work on their own kernel even with Linux getting such acclaim these days. I applaud them for it!

However, non-free alternatives and mixed alternatives simply existing is not necessarily a problem. What is good for the prophet is not always good for the people.

Re:RMS was right

[LordNimon]

raahul_da_man's point was that Linus did not make the right choice. He thought he did, but he was wrong then. That's right - Linus Torvalds was wrong to choose BitKeeper when he did. He should never have chosen it. Why? Because the fact that the license could have changed to something this onerous means that you could not rely on the product over the long term, and choosing something like BitKeeper requires you to make a long-term commitment to the product. What good is a version control system if you have to throw it out six months later? What are you supposed to do with the versioning information when you abandon BitKeeper for some other product?

Not only that, but Linus may not even be able to test Subversion while using BitKeeper, because the BK people may consider testing to be the same thing as "working on".

Re:RMS was right

[Zeinfeld]

Don't insult my reading comprehension. That's rude and unnecessary. I read and quoted your entire post and asked you to clarify. However, you did clarify your point.

Your reading comprehension appeared off to me as well.

RMS is a crank. There is no contradiction between doing something good and being a crank. Schockley invented the transistor and won the nobel prize but he was an utter crank who spent most of his later years writing racist tracts on Eugenics with the same basic premise as Murray/Herstein but without taking the trouble to hide the racism motivating the work.

The BitKeeper license is simply the logical extension of the GPL viral clause. Instead of coercing people to only use free software bitkeeper forces you to only use their software. This is not so different if you remember that when GPL was written FSF was the only game in town.

Re:RMS was right

[Subcarrier]

raahul_da_man's point was that Linus did not make the right choice.

That was raahul_da_man's opinion, for which he gave no supporting arguments. I ventured no opinion either way, I merely pointed out that ideological constraints limit the pool from which you can choose the tools.

You make some good points and I agree with some of them, although I don't feel qualified to second guess Linus on this.

If the new EULA makes BK no longer the best tool for the job then it's time to change the tool. If the pain of changeover is worth enduring then the decision is clear. It's not like we're chained to BK by a pact of blood. This is what I call pragmatism.

Re:RMS was right

[GigsVT]

The BitKeeper license is simply the logical extension of the GPL viral clause. Instead of coercing people to only use free software bitkeeper forces you to only use their software.

What the hell are you talking about? You don't even have to agree to the GPL to use GPL software! The GPL only comes into play if you want to distribute a work based from the source code of a GPL program.

You can even use stuff like gcc to produce code under whatever license you like, as you own the output you cause a GPL program to create (in all but a couple minor exceptional circumstances, where the program outputs parts of its own source code).

Re:RMS was right

[Zeinfeld]

What the hell are you talking about? You don't even have to agree to the GPL to use GPL software! The GPL only comes into play if you want to distribute a work based from the source code of a GPL program.

Go talk to Stallman and he will make it absolutely clear that his real aim is to eliminate non-free software. It will be just about the only thing that is absolutely clear...

For RMS the GPL is simply a means to an end that is beyond the GPL.

The Open Sorce Movement long ago outgrew RMS. The only person who really takes him seriously these days is Bill Gates.

Many people who start radically new movements are cranks. Freud was a drug adict, Kellog started his breakfast cereal company to stop mastubation, the Onedia company started out as a hippie free love community. Robert Owen invented modern manufacturing, socialism and went to America to set up a utopian society (interesting footnote, his son was responsible for the founding of the Smithsonian, not by donating the money but by preventing it being stolen by the then Congress).

If all you know of RMS is the GPL then you don't know him. Hero worship is never a particularly good idea, if you are going to choose a hero to worship, please at least choose one that is not afraid of water.

Re:RMS was right

[Reziac]

"The BitKeeper license is simply the logical extension of the GPL viral clause. Instead of coercing people to only use free software bitkeeper forces you to only use their software." Yiiiy! I hadn't thought of it that way, but you're right -- that is indeed the next logical step, whether the software in question is "free" or not!

Re:RMS was right

[Reziac]

Well, I don't hate RMS (I don't even dislike him), even tho over time I've become a bit disillusioned with some of the GPL's terms. I've even corresponded with RMS. He struck me as a nice, sincere, dedicated, hardworking -- fanatic. And just as you said, "Facts don't faze the fanatics."

Re:RMS was right

[peter]

You're saying that RMS wrote the GPL, thus the GPL stands for everything RMS does. That's wrong: you can use GPLed software, and even develop GPLed software without sharing all of RMSes goals and ideals. What you first said was:

The BitKeeper license is simply the logical extension of the GPL viral clause. Instead of coercing people to only use free software bitkeeper forces you to only use their software.

GigsVT answered: "The GPL only comes into play if you want to distribute a work based from the source code of a GPL program." This is correct.

You then carried on your argument as if you'd been talking about RMS:

Go talk to Stallman and he will make it absolutely clear that his real aim is to eliminate non-free software. It will be just about the only thing that is absolutely clear...

For RMS the GPL is simply a means to an end that is beyond the GPL.

This doesn't support your earlier argument at all. RMS is a thoughtful person, and doesn't force his ideals on anyone. First of all, nobody would use GPLed software if it forced you to act like RMS wishes everyone would. Software with such restrictions would be the opposite of what RMS is trying to accomplish. If the GPL worked the way you first said, GPLed software would be non-free! (and since it would require you to only use Free software, nobody could use it because using it would require you to not use it. Duh.)

If all you know of RMS is the GPL then you don't know him. Hero worship is never a particularly good idea, if you are going to choose a hero to worship, please at least choose one that is not afraid of water.

I don't worship him at all. I respect him, but that's about it as far as what I think of him personally. I really like some of his ideas and philosophical arguments. For any given piece of software I can think of, I think it would be a Good Thing if it was Free. Unless the mindset of the world changes, I suppose proprietary software will keep getting developed, esp. for specialized applications, like controlling lab equipment. Proprietary software is better than nothing, but should be avoided as much as possible as a building block for other software. If a computer running the company's software is an integral part of an atomic force microscope setup, you can use it without worrying too much that it will bite you. The software is totally specific to that one application, so if there's a problem, you need a new AFM, but you don't need to change anything else. (proprietary data formats are another story. They are _always_ a Bad Thing).

Re:RMS was right

[Ian Bicking]

The HURD no longer has any political purpose -- it is continued purely for technical reasons, because some people are interested in it (the nature of free software projects). FSF, GNU, and RMS all have absolutely no problem with the Linux kernel on political/ideological grounds. There may be disagreement on binary modules and development tools (i.e. BK), but those things are not the same as the kernel itself.

In fact, if the BSD kernel had clear licensing and legal status when the HURD was first being developed, it probably would have been used instead.

Re:RMS was right

[bruthasj]

All this really means is that the bitmover guys are afraid that their technology is so non-novel it would be too easy for someone to create another tool that does the same thing. Shoot, it could be a bunch of shell scripts using diff, patch and rsync. Subsequently, you would have to invent a bunch of new vocabulary words to mask the fact it isn't original.

Let's take for example the TrollTech guys. They were derided and yelled at for awhile -- especially the KDE guys for using non-free related material. One of the reason they relicensed under the QPL and GPL was to get more market. Another prime reason is that they knew they could be faster and better than any fork off the software. That's the most important thing to remember and that's why BitKeeper has this clause in their EULA. It's because they're afraid of forks accelerating and replacing their work and so they must use legalities to protect themselves.

So, if Debian were to be consistent in their politics, they would actually put the Kernel in Non-free. How ironic. Yeah they don't actually use a library or code from them, but remember what Debian is trying to stand for.

Re:RMS was right

[Rik van Riel]

The BitKeeper license is simply the logical extension of the GPL viral clause. Instead of coercing people to only use free software bitkeeper forces you to only use their software.

Please read the bitkeeper license before writing about it. All that the new free bitkeeper license said that if you develop and/or sell a competing product you don't get to use bitkeeper for free.

This means that eg. the developers of the Subversion project need to grab the Linux kernel source code in a different way. They could use ftp, rsync+sccs, http and possibly other ways too.

I don't see what the big problem is with this "if you compete with me you no longer get my product for free" clause...

Re:RMS was right

[IGnatius T Foobar]

Many years before this happened Richard pointed out the flaws of relying on non free software. Will any of the slashdot posters who called him crazy then apologize now?

Ok, I'll step up to the microphone and do just that.

I used to say that RMS was a wacko who is hurting the free software universe more than he's helping it at this point. But as time goes on, the closed world is getting so incredibly out of control that RMS's strict adherence to the ideals of free software make more and more sense. Kudos to RMS for being dependably ideal about it.

However, I still think his insistence on calling Linux "GNU/Linux" is sophomoric and imbecilic. Perhaps if he'd be willing to drop that petty crusade, people would take the rest of his position seriously.

Re: RMS was right

[WNight]

You are truly quasar-level stupid. Festingly ignorant.

It's a joke. The spelling is intentional.

Re:RMS was right

[Subcarrier]

So you agree that there would be some 'pain' in changing over to some other system?

Change is always painful.

You also agree that the new EULA may be a reason to switch?

Sure, it inconveniences a few people who develop other version control tools. Whether those people are central to Linux kernel development remains to be seen. As I said, I'm not prepared to second guess Linus on this.

Is there a place in your so called 'pragmatism' for forward looking thinking? If so, by your own statements, you seem to be saying that choosing BK was wrong in the first place, pragmatically, not ideologically.

Now you're putting words in my mouth. Hindsight is so wonderful, isn't it? There are a number of people raving that the world is coming to and end any day now and that if we don't believe this or that we're all going to burn. I'm sure that if the world DID come to an end, those very same people would be gleefully shouting "I told you so."

I'm convinced that Linus chose the best available tool for the job at the time. It may still be the best tool for all I know. Why not get off your high and mighty horse and volunteer to maintain the Linxu 2.6 (or 3.0?) kernel tree? Perhaps you will learn the anser.

BitMover is NOT the "bad guys"

[Perdo]

Put yourself in their shoes.

Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

What if you knew that they were using it in production with in house changes and additions with out releasing source code?

This is where BitMover is sitting. Developers are using their software to assist in developing their competition and doing it in violation of their licensing agreement.

BitMover is just doing what we would do if the shoe was on the other foot. This issue will be solved in the same way the open source community always deals with challenges.

The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

Re:BitMover is NOT the "bad guys"

[TsEA]

If you actually read the link in the story, you will see that it prevents you from using it if you are developping (or aiding development) of an alternative.

This actually means that if I am both a subversion hacker and a kernel hacker, I can't use BitKeeper anymore for my kernel hacking....

Anything good (or sane) about that?

And by the way, the GPL clearly gives the right to microsoft to use linux, even modify it, if they aren't distributing it... I think most conscious kernel hackers already know that.

So that really makes them the bad guys (I didn't see any anti-Microsoft clause in the GPL)

So that really makes them the bad guys ;)

Re:BitMover is NOT the "bad guys"

[The Fanta Menace]

The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

This isn't the issue, however.

The problem was that the developer of Subversion was also a kernel developer. I don't think that they were using Bitkeeper for developing Subversion - but the developer used Bitkeeper to check patches into the kernel. Now he cannot use Bitkeeper at all, and hence it is more difficult for him to work on Linux

No, it's not Bitmover who is at fault here - it's a problem caused by using non-free software to develop Linux.

Re:BitMover is NOT the "bad guys"

[Perdo]

Yeah, Mod that Perdo guy down. He almost made us think for a minute. We just want to follow the party line. The party line says BitMover is bad! ...

Meta might catch it.

Re:BitMover is NOT the "bad guys"

[Saxerman]

Put yourself in their shoes.

I... uh... can't. I understand the concept of trying to sell software to make a living, but I don't support it. I sell my services as a programmer to make a living and give away the code. This is not to say people who sell code are 'bad guys' but I fail to understand how they hope to compete with those commie open source hackers. Sure your start out with an edge and a superior product, but how long are you going to stay that way?

Which, of course, you sum up nicely: The open source community will produce a better alternative under the GPL without using their software. That being said, do they really think they stand to make more money by pushing away the Subversion team? In the short term, maybe, but I think in the long run they just killed themselves. I think the wineX crew handles their PR much better.

Re:BitMover is NOT the "bad guys"

[mgkimsal2]

This is not to say people who sell code are 'bad guys' but I fail to understand how they hope to compete with those commie open source hackers.

By making stuff that no commie open source hacker has an 'itch' to 'scratch', or at least 'scratch' well enough to appeal to common end users.

Sure your start out with an edge and a superior product, but how long are you going to stay that way?

Maybe only 4-5 years. That's enough for me for one product.

Re:BitMover is NOT the "bad guys"

[kryps]

I think that LM overrates the benefits that BitKeeper has to his competitors.

1) His main argument why open source developers can not reproduce something like BitKeeper is that it takes a god-awful amount of work to develop a complex SCM like BK and make it work for all corner cases as well. And this does not change at all even if they have access to BitKeeper for free.

2) For his commercial competitors (e.g. Rational) it is no big deal to buy a few BitKeeper license and have some developers thoroughly test and disect it. The licensing costs are by no means prohibitive to do that. So this point is moot as well.

So all in all having the competitors use the product does not seem to be a big deal. He should have refrained from introducing this clause because of all the bad hype it generates. But he seems to suffer from an overly inflated ego like many developers in the open-source community so he fails to understand that he has much more to loose than to gain by including this clause.

-- kryps

Re:BitMover is NOT the "bad guys"

[Perdo]

As other posters have pointed out, BitKeeper's licence is the same paid or free. You may not use BitKeeper to assist in developing a competitive product.

This may mean in it's role as revision control software.

This may also mean as a model to base competeing software off of.

In the first case, don't use it.

In the second case, it is a reverse engineering poison pill.

Re:BitMover is NOT the "bad guys"

[kryps]

>>> As other posters have pointed out, BitKeeper's licence is the same paid or free. You may not use BitKeeper to assist in developing a competitive product.

This is just not true. There is the commercial license (the BKCL) and there is the free license (the BKL). Both differ in many points and there is no clause about development of competing products in the BKCL. Check your sources.

-- kryps

Re:BitMover is NOT the "bad guys"

[Perdo]

Well, that's a pretty big claim.

Microsoft violating the GPL.

You even have a dead link to back it up.

Find the source. Read it carefully. Do not reply to me. Post the story to Slashdot, because it would make BIG news.

Re:BitMover is NOT the "bad guys"

[MaxVlast]

Or he could just stfu and pay for it. It's not like he has any legitimate reason to expect free software from a company that's trying to stay in business.

Re:BitMover is NOT the "bad guys"

[naasking]

Put yourself in their shoes. Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

Yes.

What if you knew that they were using it in production with in house changes and additions with out releasing source code?

No problem. Distribution requires source changes to be available, not use.

The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

You're right, it's called OpenCM

Re:BitMover is NOT the "bad guys"

[fwr]

Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

I don't see why it would bother kernel developers.

What if you knew that they were using it in production with in house changes and additions with out releasing source code?

This is explicitly allowed by the GPL, so for any kernel developers to have a problem with this would be hypocritical. Anyone can use any GPL software in house in a production environment with as many custom changes they want without releasing those changes to everyone in the world as long as they do not distribute their custom version outside their organization. Perhaps you meant something else than what your words clearly say? That you mean an "in house" "production" environment is somehow equivalent to distributing a version of a GPL software package outside (not in house) your organization with custom changes and not releasing the source code? That would be illegal, but that's not what you said.

This is where BitMover is sitting. Developers are using their software to assist in developing their competition and doing it in violation of their licensing agreement.

Not it is not. Their new license apparently goes well beyond that. It says that developers using (the free license version of) their software for a non-competing product, such as the kernel, can not work on a competing product, regardless of what other revision control software they use to build the competing product. So, no Linux kernel developers, or anyone else that uses the "free" version of BK, can contribute to some competing products. This is quite different than you portray.

BitMover is just doing what we would do if the shoe was on the other foot. This issue will be solved in the same way the open source community always deals with challenges.

I don't believe you understand what the issue is.

The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

One would hope that the community produces a better alternative under the GPL. If BM wants to limit the use of their software to create a competing product then I don't see a problem with this as much as what they are doing, which is described above.

Re:BitMover is NOT the "bad guys"

[ceejayoz]

Umm... how exactly is that page supposed to prove that MS is using Linux and not releasing the results? Down the bottom of that page, the source code for the compiler (lcc) they're discussing is provided for download.

Re:BitMover is NOT the "bad guys"

[pbryan]

Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

If I were a Linux kernel developer, how people would use my kernel is none of my business.

What if you knew that they were using it in production with in house changes and additions with out releasing source code?

If I knew they were distributing binaries to Linux without accompanying source code, I would insist that they rectify their apparent violations of the GPL.

This is where BitMover is sitting. Developers are using their software to assist in developing their competition and doing it in violation of their licensing agreement.

Actually, BM is restricting the license to BK, not based on how it's used, but on who uses it. If you're a competitor to BM, you do not qualify to use the Gratis version.

It's not open source software. It's commercial software. This may be ultimately incompatible with its use by open source developers. This is no surprise, right? Linus seems to make choices based on the merits of technology and practicality, not politics. If too many barriers to the use of BK emerge, I have a feeling he could make a different decision.

BitMover is just doing what we would do if the shoe was on the other foot. This issue will be solved in the same way the open source community always deals with challenges.

Placing restrictions on how a piece of software is used violates the "free speech" elements of any open source software license. It would stop being open source software. How people use the Linux kernel is none of the developers' business. How they redistribute it, however, differs with certain licenses.

The open source community will produce a better alternative under the GPL without using their software. Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

I don't think the SV folks ever considered using BK as their revision control system. I think the issue is, a SV developer could not accept the Gratis license to BK to work on the Kernel, because he was excluded because he works on a competitive project.

Re:BitMover is NOT the "bad guys"

[Lonath]

Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

Reducto Ad-Absurdum - If people had acted like this, then there wouldn't be ANY free or open source software, because RMS (or anyone else for that matter) would never have been able to write a compiler using an editor compiled by a commercial compiler that wouldn't allow you to use that compiler to make things that could be used to make other compilers. This IS fucked up regardless of how you see it. You do have the right to use software under copyright law, and this little EULA bullshit dance got plopped on top of it and nobody's wanted to go to court to stop it.

Copyright law is supposed to be limited. It's supposed to cover copying and public performance. You sitting in your house using software you've paid for shouldn't be controlled. The whole idea that you license the software and you can't use it until you agree to the license is bullshit. It may be the law, but it's still bullshit. Otherwise you have nothing except a worthless shiny disk. And once you've paid for that disk you ought to be allowed to use it and you are allowed to use it under copyright law, but somehow they've managed to get this legal fiction scaffolded into place that says you need more permission to use the software after you have the bits.

It's like books with shrinkwrap licenses. I know they've been mentioned here before, but again. Bullshit. Someday books will come with locks and you'll get thrown in jail if you buy the book and then don't pony up to give up your rights to get the key.

Yet another reason to never give money to the copyright industry forever.

Re:BitMover is NOT the "bad guys"

[Patersmith]

I don't care. It is principally wrong to allow someone to dictate what you can and can't develop on a given compiler, RCS, operating system, DBMS, programming language, whatever.

What if Microsoft changed their Windows or Visual [insert language here] EULA tomorrow to say that you can't use their products to work on anything that, in their reasonable judgement, competes with any of their products?

It might not sit well with kernel developers if Microsoft were to use Linux in their business, but what business is it of ours to tell anyone what they can or can't do with Linux? Actually, I'd bet 100:1 odds that Microsoft has at least one Linux box in Redmond.

Not only is it bad judgement, it's anti-competitive in my opinion.

I hope you're right and the open source community comes up with something better.

When will people learn? Every time you put up a stupid block, you WILL be coded around.

Re:BitMover is NOT the "bad guys"

[kubrick]

Or he could just stfu and pay for it. It's not like he has any legitimate reason to expect free software from a company that's trying to stay in business.

... and the quality (or at least the quantity :) of Linux kernel developers drops, as the process of acquiring the software required to develop it becomes more onerous and legally difficult. Not a good move from a technical standpoint.

Still, that's a decision for Linus et. al. to make, and it looks like they'll stick with it until the situation becomes unbearable for a majority of major developers -- given the way BitMover keep changing their licenses, it wouldn't surprise me to see this happen. Besides, the license language is overly broad. All major Linux distros contain CVS (I imagine :), so no-one who works for these organisations can use BitKeeper, and these people will find it more difficult to keep up with kernel development.

Re:BitMover is NOT the "bad guys"

[dubl-u]

This is not to say people who sell code are 'bad guys' but I fail to understand how they hope to compete with those commie open source hackers. Sure your start out with an edge and a superior product, but how long are you going to stay that way?

Right now, I strictly sell services, but were I to sell a product, this would not worry me. The way for any software company (or any company whose main skill is innovation) to stay on top is to avoid commoditization. Take a look at 3M. They have a corporate goal that 30% of revenue come from new products, which forces them to keep coming out with new stuff all the time. That means that they get to charge premium prices until their competitors catch up.

Were I running a software product company, I'd be tempted to just GPL the source code to any version more than, say, 5 years old. Not only would that contribute to the open source community and thus the broader public, but it would create stiff low-end competition for any of my competitors, making it harder for them to get a foothold that would let them come after my lead on the high end.

Any software company that is really dependent for revenue on old code isn't really in the business of making products or selling services; they're in the business of making monopolies.

Re:BitMover is NOT the "bad guys"

[Saxerman]

Seriously - I am very curious where you expect those paying you to get the money from in the first place?

You don't understand how a company that sells something other than software might require a programmer? Then I sugest you read The Cathedral and the Bazaar by Eric Raymond.

Re:BitMover is NOT the "bad guys"

[Rik van Riel]

Bitkeeper is just a tool to access the kernel source, but it's not the only tool.

As long as people have a free choice between tar+patch, bitkeeper, rsync+sccs and other alternatives, what's the problem ?

If Bitkeeper tried vendor lock-in we would have a problem, but since bitkeeper is in no way required to work on the kernel I can't see what everybody is upset about.

Re:BitMover is NOT the "bad guys"

[geekoid]

except your arguments were both ignorant and wrong. Thats is why you were modded down.

You can...

[Sunnan]

"You can't be "pragmatic" and use the best tool for the job if you want to keep your freedom."

You can, but non-free software can't be the best tool for the job.

Consider ethics and software freedom.

[jbn-o]

What part of this says you can develop what you want by acquiring a commercial license?

Nothing, but that doesn't make your point. To determine if the claim is true you need to compare both licenses for both versions. The license on the $0 version might differ from the other version.

Of course none of this matters if you recognize that Linus Torvalds is arguing a rather selfish point--one should use the programs that get the job done, proprietary or Free Software (or anything in between). No regard is given for the ethical and larger social ramifications of our choices; we are being asked by Torvalds to consider only our own desires. I encourage you all to consider your software freedom and recognize that the practical benefits of better programs and a better society where we can share freely come (in part) from the freedoms and attention paid to ethics found in the Free Software movement.

Re:Consider ethics and software freedom.

[AceMarkE]

Aw, enough already. Look, this isn't personal, and it's partially cause I'm way too tired right now and therefore easily annoyed.

With that said...

I'm sick of people acting like "Software Freedom" is a life-and-death issue. Linus is right. If it works, use it. If it doesn't work, don't. If the Free Software product is better, use it. If the proprietary/closed/whatever version is better - use it. Or contribute to the open product until it's better, THEN use it. The key point here is, USE WHAT WORKS.

Don't get me wrong. I'm in favor of open-source stuff, I admire RMS and the GNU project for everything they've contributed to the computing world, and I enjoy having the freedom to tinker with stuff. In the end, though, I'll use whatever is going to work best for ME in whatever situation.

The world won't end if people use proprietary software. Get over it.

Mark Erikson

Re:Consider ethics and software freedom.

[khuber]

otopico, you can't use your hammer to pount nails manufactured by our competitors.

We feel this is necessary to ensure the viability of our business.

Unfortunately your hammer was a free sample you obtained from the International Hammer Show 2001, and not the full commercial version.

We do sell a commercial hammer with no restrictions for $99.95.

Sincerely,
Ron O'Nail, U.S. Hammer Corp.

Re:Consider ethics and software freedom.

[xigxag]

It was funny but if someone's giving you a free hammer, so what? Either use it according to their restrictions or stop being a cheap bastard and pay for an "unrestricted" hammer.

The irony of this whole thing is that if BitMover completely withdrew its free offering, you folks wouldn't have a cause for complaint here. When the removal of choice is viewed somehow as an ethical improvement, it really makes me wonder about the FSM zealots.

ObLink: Here's a link to a lengthy critique of BitKeeper's license.

Re:Consider ethics and software freedom.

[Znork]

The problem with licensed proprietary software is that you can never make more than a snapshot judgement on it. You do not have the data necessary to make a judgement than will be valid for more than a few seconds.

I see nothing where Larry McVoy swears the license will never be changed to exclude anyone providing non-BK repositories. I havent seen a mail where he swears that people working for for-profit corporations wont be excluded. I havent seen him promise that BK wont exclude anyone with a beard either in the future.

How do you make a judgement then? How well does it do what it's supposed to do? How well does it do what you need it to do? Well, how much does that matter when _you may not be allowed to use it at all tomorrow_? What value does it have for you then?

Software freedom isnt necessarily the deciding factor if your choice matters the next five minutes. But when you make a choice that must be valid over a decade youd better have a crystal ball to see how whoever decides the license is going to act for the next ten years.

Re:Consider ethics and software freedom.

[kryps]

I wholeheartedly agree. I think that the FSM should be really thankful to be able to use a great tool such as BK for free. If there were a free SCM which could do what BK can then I am sure that the kernel hackers would use it. But there is no such tool.

-- kryps

Re:Consider ethics and software freedom.

[InodoroPereyra]

Don't get me wrong. I'm in favor of open-source stuff, I admire RMS and the GNU project for everything they've contributed to the computing world, and I enjoy having the freedom to tinker with stuff. In the end, though, I'll use whatever is going to work best for ME in whatever situation.

Fine, but you don't seem to understand that if everybody did what you do, you wouldn't have free software to enjoy. So, in short, you adopt a comfortable "I use the right tool for the job" attitude, you "get sick" of people who really stand for free software and finally use their software when it is done. Brilliant.

Re:Consider ethics and software freedom.

[Tikiman]

I'm sick of people acting like "Software Freedom" is a life-and-death issue. Linus is right. If it works, use it. If it doesn't work, don't. If the Free Software product is better, use it. If the proprietary/closed/whatever version is better - use it. Or contribute to the open product until it's better, THEN use it. The key point here is, USE WHAT WORKS.

Don't get me wrong. I'm in favor of open-source stuff, I admire RMS and the GNU project for everything they've contributed to the computing world, and I enjoy having the freedom to tinker with stuff. In the end, though, I'll use whatever is going to work best for ME in whatever situation.

Quite a selfish viewpoint you have there - it turns out that the best solution for YOU may not be the best for society at large. Perhaps you need to brush up on FSF philosphy. No one said it as "life-or-death". But if businesses had their way, there would be no free software - and you don't find that the least bit scary? Think about it - you have 0 rights to your hardware unless you start dishing out cash and accepting possibly onerous license agreements. In other words, you give up all of your rights.

So you have a choice - live in a world where free software is a critical force for maintaining the rights of consumers, or live in a world where you just want whats "best", and therefor implying that the world would be just fine without free software. I hope you thing the first, because the second is a scary world indeed.

Re:Consider ethics and software freedom.

[Blkdeath]

Quit trying to make it a moral issue. It is an issue of choice. People have the right to use what they want. If you don't like that then maybe you are more like the closed source software houses than you wish to admit.

You're thinking in the microcosmic view of the situation. Essentially, you're considering a single person performing a single task. You have to think of the people who make the software industry work - business. The home "market" essentially only exists to ensure that home users will be comfortable with the offerings that mega software corporations sell to business (small and large - moreso large) when they go to work.

Decisions made by people in the software industry affect millions of people and tens, even hundreds of billions of dollars annually.

Consider the release of Microsoft Windows 95. IBM (a company not without its own monopolistic history, but I digress) was initially going to promote OS/2 alongside Win'95, but Microsoft did not approve of this. At the last minute before the release, IBM was presented with an ultimatum; Win'95 or nothing. Since Win'95 was the current 'thing to have', it would have been a crippling blow for the (current) industry leading hardware manufacturer to ship PCs without it.

Now consider things that retroactively cost billions - Melissa shut down corporations and wreaked havoc for weeks. Since people did not have any access to the code that makes the affected products 'tick' (ie; Outlook (Express)), they were forced to sit on their hands and wait for a proprietary solution.

Proprietary products, as it's been pointed out in the past, tend to limit their users to only their own products. Concealment of APIs to make it difficult for competitors to integrate, making significant changes to the API and/or protocols without proper documentation so that competitors will find their products behind the times, etc..

Proprietary software licenses tend to become progressively more restrictive, rather than less. Restricting a user's rights to use the other products and (digital) media they already own, for one thing. Restricting the types of files they are permitted to store locally and share with others. Restricting who they may converse with online, and allowing corporations and government bodies a peek into what you're doing on your computer - in the interests of preventing theft of "Intellectual Property" and terrorism, of course.

Free software is a moral issue. Don't try to make it less of one; you're only playing into the hands of the corporations.

For a good read on a possible free-software-free future, head on over to read this fine essay.

Re:Consider ethics and software freedom.

[SDF-7]

He probably doesn't seem to understand it because what you said doesn't follow at all.

What he said was "Use what works - and if nothing does, either write your own or help out those who _are_ writing what you need" (loose paraphrasing).

There's nothing implying that _only_ non-Free software will fill your needs, nor is there anything implying that people will automagically stop writing Free software just because someone is willing to pay for a non-Free piece they feel does the job better. You seem to be implying that everyone should use only Free software - regardless of the competence of the software for the task at hand, and frankly - that's either just silly or you need to look in the mirror and confess that you've become a zealot.

If there's a need for a piece of software, someone will write it. If it is someone who believes in Free (and presumably not necessarily free unless they have a day job) software, they write it and it fits the need, people will use it.

Re:Consider ethics and software freedom.

[Skjellifetti]

The bullshit sure is thick around here today.

Quite a selfish viewpoint you have there - it turns out that the best solution for YOU may not be the best for society at large.

Who are you to impose on the rest of us your vision of what is best for society at large -- especially when your vision conflicts with what is best for someone else?

But if businesses had their way, there would be no free software - and you don't find that the least bit scary?

Not at all because it won't happen. You will always be free to write software and licence it as GNU/BSD/Whatever so long as your software does not steal rights that belong to someone else. Note that the "so long" clause has many implications that will be fought out in the courts, legislatures, and international orgs like the WTO in the coming months and years.

Think about it - you have 0 rights to your hardware unless you start dishing out cash and accepting possibly onerous license agreements. In other words, you give up all of your rights.

What rights are you giving up? When you buy a product, you enter a contractual arrangement with the seller. You only get those rights that you purchase. Want more rights to the something? Then convince the seller to sell them to you. Think about a plot of land you are considering buying. Does the sale include the mineral rights? Does it include deed restrictions? Why is software different? Some companies sell their software as purely closed source, some sell it with source code. In each case you have bought a different package of rights. Why does any product offered for sale have to include all potential rights to that product? Unbundling the product into seperate packages of rights enhances the public welfare by increasing the choices available to both sellers and buyers. Fewer people would buy the product if the seller were forced to include all potential rights.

So you have a choice - live in a world where free software is a critical force for maintaining the rights of consumers, or live in a world where you just want whats "best", and therefor implying that the world would be just fine without free software.

Huh? Why does a willingness to pay for a particular feature set that is currently provided only by closed source vendors imply "that the world would be just fine without free software." Your logic escapes me.

Re:Consider ethics and software freedom.

[erat]

How you can compare freedom of speech with free software is beyond me. Last time I checked, nobody lost his/her life or the lives of family members and friends over a free/proprietary software issue.

Re:Consider ethics and software freedom.

[Atzanteol]

Linux Torvalds Selfish! News at 11! Seriously. He's the project lead of a very large project that many of us reap the benefits of. When was the last time you offered to assist him in keeping track of the source? You didn't? And you expect him to bend over backwards for *you*? This is far and away an unreasonable request to make.

Re:Consider ethics and software freedom.

[Znork]

You are, of course, entirely right. If you can be sure that the license you have is binding for both parties (ie, you 'bought' the software and it's yours according to the terms in the original license and provided that the file formats are open enough to allow you to migrate off the software in some reasonable way, should future revisions or change in circumstances merit such a migration) then you have an acceptable situation. Then you _can_ make an informed judgement as to the cost vs. benefit of the proprietary product.

BitKeeper, unfortunately, isnt such a product. As far as I can recall, the free BitKeeper license requires you to upgrade at any time a new test release is made, which also means the license terms can change at any time.

This tends to be the trend in proprietary software. This trend tends to make it less and less useful for me, since I make decisions on what software to use on a longer term perspective (I _hate_ having to do unecessary migrations or changes just because I cant use a certain product anymore).

Oh, well, apparently we agree then :).

Re:Consider ethics and software freedom.

[dubl-u]

Fine, but you don't seem to understand that if everybody did what you do, you wouldn't have free software to enjoy.

That's just wrong. Larry Wall wrote Perl because he needed it. Linus wrote Linux because it was interesting and fun. Neither of them did it out of any mystical dedication to Free Software, hallowed be its name. Millions of people use them not because RMS told them to, but because Linux and Perl kick ass.

The existence of free software doesn't depend on people using crappy software just because it fits with some political agenda. It depends on people making cool things and then giving them away, which in turn inspires others to do the same.

Re:Consider ethics and software freedom.

[dubl-u]

But if businesses had their way, there would be no free software - and you don't find that the least bit scary?

That's a pretty broad brush you're painting with, there.

It's true that some businesses don't want some software to be free. But it's clearly false that all businesses want no software to be free.

So you have a choice - live in a world where free software is a critical force for maintaining the rights of consumers, or live in a world where you just want whats "best", and therefor implying that the world would be just fine without free software.

That's a lovely dichotomy; it's a pity it's false.

How about we live in a world where we make free software the "best" for many purposes? That way we don't have to have the Freedom Police goose-stepping their way onto my computer to make sure I'm making the right choices for the benefit of "society at large".

Happily, that's the world I live in. When free software is the best, I use it. When it's not, I pay up. And either way, I contribute back to the community, widening the space in which free software is the best.

Re:Consider ethics and software freedom.

[Mr. Slippery]

I'm sick of people acting like "Software Freedom" is a life-and-death issue.

As software comes to take a greater role in our society, software freedom is going to becomre just as much a life-and-death issue as freedom of speech and freedom of the press.

The key point here is, USE WHAT WORKS.

In determining what "works", a wise person takes into account the total range of effects of a choice (or as broad as he or she can see, anyway).

Say company X makes a better hammer than company Y; maybe X's has a more comfortable handle. But company X engages in all sorts of unsavory business practices. I am willing - obligated, even - to put up with an occasional blister generated by my Brand Y hammer, rather than buy a Brand X and put my money in company X's slimy little pocket.

Re:Consider ethics and software freedom.

[jbn-o]

Linus is right. If it works, use it. If it doesn't work, don't.

That doesn't illustrate why you think Torvalds is right.

I'm in favor of open-source stuff, I admire RMS and the GNU project for everything they've contributed to the computing world...

Please show your support by citing the correct movement when you talk about RMS and GNU. What you just said suggests an unfamiliarity with both software movements significant enough to be confusing to readers. RMS and GNU have nothing to do with the Open Source movement. RMS does Free Software and the GNU project & the GNU GPL were set up to make a complete Free Software operating system a reality. Listen to the 2001 NYU speech or read the transcript of this speech where RMS corrects the error you just made. The Free Software movement predates the Open Source movement by over a decade. Please read the FSF's essay on the difference between the two movements so you won't make this mistake again and confuse other readers.

Re:Consider ethics and software freedom.

[Lemmy Caution]

The problem isn't the Linus is selfish. He isn't.

He's just not a very good Kantian. :)

Re:Consider ethics and software freedom.

[Rik van Riel]

Software freedom ? What about freedom of choice ?

we are being asked by Torvalds to consider only our own desires

Nonsense. All Linus is asking for is for people to be able to make their own choices. Linus choses to use bitkeeper, but he doesn't force that choice on you in any way.

You can get the latest Linux Kernel source code by ftp, rsync, etc... You can even get the full revision history from the bitkeeper tree without using bitkeeper:

ftp://nl.linux.org/pub/linux/bk2patch/README

Re:Consider ethics and software freedom.

[Rik van Riel]

Proprietary products, as it's been pointed out in the past, tend to limit their users to only their own products.

This problem is called "vendor lock-in" and it happens when the proprietary software stores your data in a format that can't be accessed by other software.

Bitkeeper doesn't suffer from this problem since its data is stored in SCCS format (GNU CSSC can handle that fine) and it will happily export patches so people that don't use bitkeeper can access the latest source code.

Vendor lock-in is NOT an argument against bitkeeper.

Blatant plug: you can get the latest bitkeeper kernel source without using bitkeeper.
http://ftp.nl.linux.org/pub/linux/bk2patch/

Re:Consider ethics and software freedom.

[jbn-o]

What about freedom of choice?

That is not one of the freedoms the Free Software movement champions because that is a practical consequence of the freedoms they do champion. The freedom of choice is well served by maintaining a commons--the commons of Free Software. If you got further (as the FSF does) and protect that commons (say, by copylefting Free Software), you ensure the commons will grow and serve choice even further. Lawrence Lessig will be arguing a related point in the upcoming Supreme Court copyright case Eldred v. Ashcroft, but he'll take it from the other side: when one stifles the commons of the Public Domain by extending copyright's term, one is not promoting "the progress of science and the useful arts" (a quote from the US Constitution).

All Linus is asking for is for people to be able to make their own choices.

If that were truly all he were asking for it would be rather silly--there is no danger of multiple choices going away. What's interesting about Torvald's request is what's not being raised: Torvalds is not asking you to consider forces at work outside your own concerns. To adopt your language, all the FSF is asking for is for people to consider the ethical implications of choice they may not have been aware of before.

You can get the latest Linux Kernel source code by ftp, rsync, etc...

I never argued one couldn't do that, so I don't see how that is apropos at all. Alternatives for getting the kernal is not the point.

Re:Consider ethics and software freedom.

[William Tanksley]

Quite a selfish viewpoint you have there - it turns out that the best solution for YOU may not be the best for society at large.

Two points.

First, in the most general case, contrary to what you say, society (including the Free Software society) gains by encouraging the individual to make the best choice for his own interests. See the economic work of John Nash for a detailed mathematical proof, or von Mises' "Human Action" for a carefully reasoned logical explanation.

But if businesses had their way, there would be no free software - and you don't find that the least bit scary?

I find it to be an uninteresting scare tactic on your part. Obviously, a license or law like that would be against my interests, and I'd fight to prevent it, just as I am fighting to support Open Source Software and Free Software (both for their own merits).

So you have a choice - live in a world where free software is a critical force for maintaining the rights of consumers, or live in a world where you just want whats "best", and therefor implying that the world would be just fine without free software. I hope you thing the first, because the second is a scary world indeed.

I take the second choice, because contrary to your statement, Free Software IS the best. Shake off your fear -- if you truly support free software, have a little bit of trust in it!

Fight for it -- freedom is always worth fighting for -- but stop trying to destroy freedom in the name of Freedom.

-Billy

Re:Consider ethics and software freedom.

[William Tanksley]

Quite a selfish viewpoint you have there - it turns out that the best solution for YOU may not be the best for society at large.

Two points.

First, in the most general case...

Second :-), in the specific case of software, choosing and being satisfied with subpar software because it's free provides a negative selection pressure on Free Software. If you wish it to remain inferior, then by all means keep advancing it.

Choosing a product based on how it meets your needs doesn't hurt the worse Free Software (although it may hurt a company which happens to be backing it); it only forces the Free Software to compete for users, which in the long run will help it.

And at the end of the day, even if you're right and I SHOULD have been using the Free Software, it's still free and you can still use it in utter certainty that you're doing the right thing -- and I can still switch to it.

(Of course, this license sounds too bad to be true; I can't agree to terminating all possibility of working on Subversion. The license here is against my interests, so I won't accept it.)

-Billy

Re:Consider ethics and software freedom.

[aminorex]

> Last time I checked, nobody lost his/her life or
> the lives of family members and friends over a
> free/proprietary software issue.

But you haven't checked, have you? Remember when
the USN destroyer was shut down by NT4? How many
commercial aircraft have been lost due to software
errors? There's really no way of estimating,
frankly. I only know of one clear case, in which
an ATC screen display was misprogrammed, resulting
in a collision with mass fatalities in Germany,
but in general, when closed-source software costs
lives it's very difficult to prove that it was the
result of a software defect, and believe me, the
vendor will spend every last dime they have making
sure that you will never be able to pin the blame
on them.

Free software is free speech, and whether the cost
of defying censorship is jailtime, court awards,
or a bullet in the head is immaterial to that fact.

Has no one here any idea of what a "business" is?

[pediddle]

So many people here are getting all upset because BitKeeper is not free. Well, there's nothing wrong with trying to make money off of some software, while helping the community at the same time.

No business in their right mind is going to help a competetor take their market share. Maybe BitKeeper can't help if Subversion takes that market on its own, but they are not going to help them do it.

Disclaimer: I have a huge interest in Subversion, and I've been contributing to their mailing list for almost a year. I love Subversion. But I still implore all you Slashdot hippies: do not assume that all non-free software is evil, and do not make BitKeeper the bad guy just because they want to make money.

Free software depends on a few companies' ability to actually make money developing and using free software. Without industry support, free software will never make it past a select few geeks' basement computers. If you like free software, then you should support BitKeeper's decision. BitKeeper has helped the FS community in the past, and their support for the kernel project has been wonderful. Support them, help the FS industry grow, and everyone benefits.

In Related News...

[sparkz]

Microsoft announce that all Windows licenses held by Open Source developers are null and void.

The BSA will be knocking on the door any minute... follow the white rabbit.

Alan Cox?

[vsync64]

Does Alan Cox use BitKeeper, and if so, does he pay for his copy? I would imagine not, given his stances on free software and intellectual property.

I'd like to point out that Alan Cox works for RedHat, whose operating system includes CVS. I would venture to guess that RedHat hackers have contributed to CVS, at the very least with a 1-line diff here or there. This makes RedHat both a reseller and a developer of CVS, and even if he doesn't personally have anything to do with CVS (doubtful) he is forbidden from using the openlogging version.

I find it ironic that at a time when BitKeeper is trying to sway developers toward their product, they create onerous conditions which prevent a prominent developer and political spokesman from using said product on any sort of trial basis.

Technically, I suppose I'm not allowed to use BitKeeper either, since I've written (and released, I think; I'll have to double-check) an add-on to CVS which parses and cross-references checkin logs.

The really funny thing is that CVS is quite prevalent in the free software world, where it is extremely common to create patches and add-ons. The most effective referrals to BitKeeper would be from CVS hackers or those otherwise extremely experienced with it, but by preventing precisely these people from trying BitKeeper out, the one thing that could help BitKeeper the most -- a public defection from a "pet project" -- is verboten.

It's rare that we get to see such an obvious case of shooting oneself in the foot.

Re:Alan Cox?

[another_plonk]

Here's a similar question by Ulrich Drepper
And here's Larry McVoy's answer

Please see Larry's comments (and responses)

[crimsun]

I believe the intent of "Col. Klink (retired)" was to bring this to a wider audience, but there are several points that need to be reiterated.

1) "In fact you can't use BitKeeper if you OR your company have anything to do with competing software."

The above applies to /free/ use only. You are still welcome to purchase a commercial license from BitMover. What Larry has said "makes sense" from a survival/profit (i.e. capitalist) point of view: "you simply don't get to use our product -- which we provide for free -- to put our company out of business."

Furthermore, Larry has demonstrated that even if you /don't/ use BK, accessing changes and patches should be no more difficult than prior to Linus's trial/adoption of BK.

2) It has been made very clear by several of the core developers that accessibility to Linus's merges has been made much easier since his trial/adoption of BK. See here, here, and here.

3) This is hardly a "new EULA."

Please see the thread at http://marc.theaimsgroup.com/?l=linux-kernel&m=103 389686711292&w=2, or subscribe to linux-kernel at vger.kernel.org for updates.

Re:Please see Larry's comments (and responses)

[Znork]

"you simply don't get to use our product -- which we provide for free -- to put our company out of business."

Not quite. He's saying "You dont get to use our product -- which we provide for free -- for _anything_ if you also work on a product providing similar functionality to what we do (or work for a company that does)".

That not only hinders development of competing products, it also hinders development on entirely unrelated products by degrading access to the sources for anyone who also works on other revision handling products, or for a company that might also be developing such products (which means nobody working at, for example, RedHat, IBM, Oracle, Rational, etc can use BK to access the kernel source without legal exposure). Which means BK is an extremely bad choice for any major free software project.

While accessing patches may not be _harder_ now, nor is it easier. Choosing something other than BK would make it easier for everyone.

Are you from Florida, by any chance?

[Subcarrier]

I have great respect for Linis...
I myself vote for Alam Cox...
Let Linix retire...

I don't recognize any of these gentlemen. Your vote has been disqualified.

Read the whole discussion on LKML.

[Nerant]

Kerneltrap.org covered all of this. for those too lazy to read through the whole exchange, i'll extract the best part (emphasis in bold is mine):
"
From: Larry McVoy
Subject: Re: New BK License Problem?
Date: Sat, 5 Oct 2002 16:44:06 -0700

> And that's perfectly fair. However as worded in your license today, the
> individuals who work for those companies and have nothing to do with
> the competitive software you are worried about can't use your product
> to work on open source software.

Yes, that's true. But that doesn't mean we can't make exceptions, we can
and do.

> defined on www.opensource.org, may apply for a waiver to
>
> stating
> 1) Which company they work for
> 2) Which Open Source Project(s) they are going to be using the
> Bitkeeper software for
> 3) Identify if they are working on this project in their "free" time or
> as part of their
> job definition
>
> If granted the waiver will only cover the stated Open Source project(s)
> you have named. If you expand your use of the BitKeeper software to
> other Open Source project(s) you will need to apply for a waiver for
> those project(s) as well.

If *I* had suggested this language I would have been flamed off the face
of the earth. The people who are complaining the loudest are complaining
that BitKeeper limits their choices or takes their freedom away or whatever.
They absolutely *despise* any sort of authority figure and the idea of
coming begging to BitMover for a waiver each time just makes them crazy. "

In short?
If you want to use Bitkeeper for the development of something to replace it, you have to purchase a commercial license. Otherwise, you can use the "gratis" license.

Re:Read the whole discussion on LKML.

[XaXXon]

In short?
If you want to use Bitkeeper for the development of something to replace it, you have to purchase a commercial license. Otherwise, you can use the "gratis" license.


This isn't an accurate statement, or at best it's misleading. Say you want to work on two projects -- one a version control program, the other the Linux kernel. For the version control stuff, you use your own software (or CVS or anything not BK), and for Linux you use BK (which apparently you don't have to do, but it integrates best). Nope, can't do it. Because you work on a competing project, you can't use BK for free for anything. I think this is the biggest problem.

Apparently you're allowed to buy your own license, but most people don't have $5,000 to shell out (I've seen the price list) for a single copy.

Things like this...

[testuser58]

Just make me feel like a sucker for choosing the "hip" GPL for my software. To think that I could have included a license that says something like:

• "by using this software, you agree to give me your car and talk to a jar of pickels at work for the first five minutes of every day."
  
• "by using this software, you agree to agree to the previous agreement, section D, which can be found in records department 41, level 9, building B. Yeah, see them to find out what you just agreed to, sucker."
  
  or
  
  
• "by using this software, you agree to tell me when you encounter bugs instead of emailing me I'll never use your software because it doesn't work good!"

Sigh... the fun I could've had...

Re:Things like this...

[Knobby]

To heck with the gpl, try the Free Oject-Oriented License

Read the thread

[blender98]

If anyone bothers on read the whole thread (ha!), they'll find that this only affects the free use of BK.

Larry's main concern is that someone who wants to implement a competing version control system does not use a free version of BK to do so. He is not attempting to prevent the subversion people from using bitkeeper; he just doesn't want them using it for free.

Before people start jumping up and down and screaming "antitrust", let me just state again that he is simply insisting that people who work on competing products but BK, rather than using it for free. He is by no means restricting anyone's trade.

Furthermore, BK is not required to checkout source code from a BK repository -- SCCS suffices, and Rik van Riel, Jeff Garzik and others make snapshots available every couple of hours.

The long and short is that nobody need use bitkeeper for kernel development (the source code may be obtained in a timely fashion using existing tools). If you don't like the BK license, don't use BK!

Larry has a responsibility to BitMover and its employees. He has salaries to pay, and making it easier for competitors to duplicate BK does not make that any easier. By providing BK and bkbits.net for free, he is doing the kernel community a service -- how about we cut him some slack?

Re:Read the thread

[jrfonseca]

I've read carefully all the thread on http://kerneltrap.org/node.php?id=444 but I don't share your opinion.

Larry first presented BitKeeper designed to both aid the kernel development and to be comercially viable. So far these two goals haven't collided: people could use freely BitKeeper for kernel development and BitKeeper has been growing as a comercial product.

But this changes does affect everything: it prevents people that (even if just remotely) contribute somehow to different SCM products and which were using BitKeeper freely has they were incentivated to revert their habits. The problem is not that they can't find a way around, but that Larry is taking away a present which had been given away freely.

The worst is that this change does not seem to be made to protect BitKeeper business model but seems instead a act of bad faith against a particural set of people.

This radically change my opinion about the usage of BitKeeper and the trust on the people behind it, and from I've read Debian maintainers feel the same.

McVoy just killed BK

[Performer Guy]

Face it, after this EULA and the email this guy just sent out bit keeper is dead. R.I.P. Who knows where their business dealings will take them and what use it will be in their interests to curtail in future. If you're using BK for source management you have to be looking over your sholder and worrying what proclamation McVoy will issue next that might force you to throw out all versions in your tree currently and move to an alternative product.

Re:McVoy just killed BK

[jdreed1024]

If you're using BK for source management you have to be looking over your sholder and worrying what proclamation McVoy will issue next that might force you to throw out all versions in your tree currently and move to an alternative product.

Wow, this is FUD worthy of Microsoft.

Go read the fscking links. All it says is that you can't use BitKeeper to work on competing products. Can you use BitKeeper to work on The GIMP? Sure. Can you use BitKeeper to work on KDE? Sure. Can you use BitKeeper to work on Subversion? No.

Do you honestly think it's McVoy's goal to kill off free software? If so, why does he say in his mail that

we're a business which happens to be committed to helping the kernel team because we think that the kernel is vital to the world at large. Helping the kernel absolutely does not translate to helping people who happen to be our competitors.

Come on, people. If they really hated free software, they wouldn't be doing this. Of course, now is the spot where people will chime in saying "they're just making us use it so they can control the code and lock us in." Wrong. I haven't used BitKeeper, but I'll bet that you can still get the source code out of it. I don't think it will ever prohibit you from extracting the current source tree - if it does, well, that's the point at which Linus should abandon it.

That having been said, it does appear from this mail that McVoy has a personal disagreement with Ben Collins. (See the relevant text about 'netwinder') If so, a EULA is a poor forum in which to take action for his grievances. It does NOT, however, mean that he is any more wrong for doing so. He wants to make money. There's nothing wrong with that. The FSF may have a truly noble cause, but until there's such a thing as Open Source Food, and Free-As-In-Beer-And-Speech housing, people will still need money.

Now is the chance for the community to put live up to its hype. We've always said that we don't need to badmouth MS, we can just come up with something better. Go ahead! Make Subversion better than BitKeeper. Make it so that everyone who uses BitKeeper will be pounding your doors down trying to get Subversion. This isn't Windows we're talking about here - it's a revision control prorgam that's used mainly by clueful people. So make Subversion better, and put BitMover out of business, and then you'll have won.

Re:McVoy just killed BK

[Col. Klink (retired)]

> Can you use BitKeeper to work on The GIMP? Sure.

Unless you or your company also work on CVS.

> Can you use BitKeeper to work on KDE? Sure.

Unless you or your company distribute Subversion.

Ben Collins can't use BK to work on the kernel anymore.

Re:McVoy just killed BK

[epine]

As a user of the free BitKeeper license I've had a direct experience with Mr McVoy's "reasonable opinion". I will say first of all that I'm extremely pleased with the technical capabilities of the BitKeeper software. It's a superb fit for the distributed mode of development we practice here. I would extremely distressed to lose the use of this tool over petty licensing conditions.

That said, I see two traits in Larry McVoy as the person behind the terminology. One is the hard nosed "we're here to make a living" side where he steps up to the plate and makes unpleasant decisions when he feels he needs to protect his team and his company. The other trait is his feisty, confrontation rhetorical style where "my way or the highway" takes a front seat to "reasonable opinion". I'm not even sure that "reasonable opinion" was granted a rumble seat in my encounter.

Reasonable opinion means different things to different people. Perhaps it is a flaw in my own nature that I tend to be far too forgiving, but nevertheless that factors into my own standard of reasonable opinion. I was unable to detect a shread of commonality between my own standard and Larry's standard, whatever it might be.

I find this development to put me in an extremely awkward position. I have a fetish for good tools, and BitKeeper is an excellent tool. I banned the use of CVS in this shop (for our own source code) because I believe the use of CVS sends the message that compromise is acceptable. By far my strongest reason for adopting BitKeeper was to reinforce the message among my own team that sloppiness around the edges is not tolerated.

Soon we will be making additional hires and I have to ask myself "am I willing to subject the people we hire to the constraints of the BitKeeper license, now and in the future?" We are looking for the kinds of people who contribute to open source projects wherever they feel they have the skills to do so. I despise non-linearity in my own professional life, I certainly can't imagine becoming a conduit of non-linearity in the lives of the people I hire.

I admire Larry for standing up and doing what he feels is right to protect his team and his company. Where Larry crosses the line IMHO is conveying the message with pitchfork included. He carries a pitchfork in one hand, and writes "resonable" into his EULA with the other. That certainly has me looking over my shoulder. If I find myself shafted on Larry's pitchfork I'll be drinking alone.

My first move will be to establish an internal line of development on one of the open source alternatives.

I may yet choose BitKeeper for its technical superiority and commercial support, but certainly not without a backup parachute strapped on my back.

Caveat Emptor.

Re:McVoy just killed BK

[Xtifr]

McVoy didn't take action specifically against Collins in the EULA; rather, Collins had the chutzpah to tell McVoy what a dirty rotten no-goodnik he was and then ask for a favor.

That is not what happened! Keep in mind that Ben Collins is a former leader of the Debian Project, a non-profit free software development and integration org. Larry works for a for-profit company that makes non-free software. Larry asked Ben to donate hardware! Such a donation to a company that only produces non-free software would have been entirely inappropriate for the Debian Project Leader. And pointing out that BK's license fails to meet the (long established) Debian Free Software Guidelines hardly constitutes calling Larry a "dirty rotten no-goodnik".

Of course, Larry tends to fly into a tizzy whenever anyone suggests that his contributions to the free software community might be less than those who actually produce free software!

Re:McVoy just killed BK

[nagora]

Go read the fscking links. All it says is that you can't use BitKeeper to work on competing products. Can you use BitKeeper to work on The GIMP? Sure.

Today. What about next week when Larry reveals his great new paint program? Who died and let him decide what people can program?

Does MS have the right to prevent people using Excel to show that they're not stumping up dividends? Can GM tell you not to drive to anti-GM protests in your car?

If they really hated free software, they wouldn't be doing this.

Um, I think you'll find that they are doing this because they do hate free software, at least when it's free as in "free competition".

TWW

Re:McVoy just killed BK

[Xtifr]

Instead, he told Larry what a dirty rotten no-goodnik

Can you prove that claim? Larry gets a lot of flak from free software fanatics. It's highly probable that he interprets any MENTION of the non-freeness of BK as a claim of his dirty-rotten-no-goodnikness at this point. But it seems out of character for Ben to have actually insulted Larry without mitigating circumstances.

Note that if Ben were the usual sort of raving free-software loon you frequently get on /., he wouldn't have ever installed BK in the first place. As a former leader of the Debian project, there is ZERO chance that he was unaware of BK's non-libre status. So even if you don't know Ben as well as I do (not well, but well enough), it should be pretty obvious that there must either be more to the story or the story (that Ben gratuitously insulted Larry out of the blue) is just plain wrong.

Now, he wants Larry to grant him a favor.

No, he doesn't. He asked if the his license was still valid, Larry said, no, Ben said OK and deleted BK. No problem.

CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Tet]

This makes RedHat both a reseller and a developer of CVS, and even if he doesn't personally have anything to do with CVS (doubtful) he is forbidden from using the openlogging version.

Nope. You entire argument rest on the premise that CVS "contains substantially similar capabilities" to BitKeeper. It doesn't... not just in my eyes, but in the eyes of Larry McVoy and BitMover. Larry has repeatedly stated that if CVS was good enough, he'd never have had to start developing BK in the first place. CVS is fundamentally flawed in its design, and doesn't come close to BK in terms of capabilities. By far the biggest one is its lack of changesets, but there are others, too. Hence, RedHat shipping CVS has no bearing on use of BK by any RH employees. Now if Red Hat shipped TrueChange, Perforce, or (more relevant in this case) Subversion, then it would be a different matter. And even if they did, I'm sure Larry would make an exception, or modify the license slightly. He's a reasonable guy, and wants to do the right thing, but at the same time, he has a business to run, and staff to pay, and it's perfectly reasonable for him to take steps to protect that.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Tet]

It is not about how buggy CVS is, or how close YOU feel it is. RTFA

Sigh. The "article" is a piece of uninformed and legally irrelevant speculation by one Debian developer. What matters in this case is what BitMover think, and BitMover have repeatedly stated that they don't see CVS as competition.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[epine]

If BitMover so thinks, it should be written into the EULA where the word "reasonable" now presides. The point of my previous post was that people should evaluate the EULA exactly as written, as a lawyer would do. There's exactly as much rope coiled underneath that harpoon as the legal system defines that term legally.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Znork]

You're 'sure' he's 'reasonable'? How 'sure' are you? Sure enough to offer a warranty offering to pay for whatever license RedHat would have to buy to obtain the same level of functionality? Sure enough to pay for the development of an interoperable product if no licenses are obtainable at any price? Sure enough to pay for and migrate the entire Linux kernel to a new revision handling system, should BitMover get bought by MS ('at a price they cant refuse') who then proceeds to relicense BK so that it cannot be used for development of GPL software?

As you say, he's got a buisness to run and a staff to pay, and as long as you use licensed proprietary products whose licenses can change at anytime you're taking a serious risk.

So, are you sure enough to pick up the tab, or do you think the kernel should be using a free product for revision handling?

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Tet]

So, are you sure enough to pick up the tab, or do you think the kernel should be using a free product for revision handling?

"The kernel" doesn't use any revision control. Some kernel developers use BK, and yes, that now includes Linus. Some use CVS. Some may use others (subversion, arch, etc.). But the point is, no one is saying you need to use BK to hack the kernel. Indeed, Alan Cox doesn't. So where's the problem again? Linus uses it because it makes his life easier. Prior to using BK, he didn't use *anything*. If BitMover gets bought out by MS, then Linus reverts back to using nothing (or if subversion or some other free package has improved to the point where it does what he wants, then he'll use that instead). There is no risk here. Oh, and BTW, you can't retroactively relicense a product. Even if MS did buy BitMover, existing licensees could keep using the product under the terms of their original license.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[TrentC]

Now if Red Hat shipped TrueChange, Perforce, or (more relevant in this case) Subversion, then it would be a different matter.

So BitMover gets a say in what Red Hat gets to ship in their distribution now? That's good to hear...

[McVoy is] a reasonable guy, and wants to do the right thing,

Bullshit. In one of the linked articles, Larry McVoy specifically tells Ben Collins that "you work on Subversion, which places you in violation of our license, and you wouldn't give us a netwinder to test on when I asked for one because you didn't like our license, so you specifically are in violation."

The fact that McVoy dredged up an incident that is totally irrelevant to Collins' work on Subversion and uses it to justify revoking Collins' gratis license for BitKeeper tells me just how "reasonable" McVoy is (and BitMover is by extension, if McVoy decides who is in compliance with their license).

Jay (=

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Znork]

"Oh, and BTW, you can't retroactively relicense a product. Even if MS did buy BitMover, existing licensees could keep using the product under the terms of their original license."

As the current BitKeeper Free license is only valid as long as the BitKeeper software "performs all licensing functions, such as Open Logging, identically to the current version of the Bit-Keeper Software as distributed by BitMover, Inc."..., well, you should re-read the license.

They dont have to "retroactively relicense" the product. Your license expires as soon as you dont conform anymore, BitMover controls wether you conform or not, and you have to upgrade to a new version when they decide, at which point they can change the license in whatever way they want.

Furthermore the license explicitly forbids interfacting to BitKeeper Packages by any other means than using bitkeeper, unless you comply with the license of the BitKeeper Package, which again means access to the source can be arbitrarily changed to disallow access by interfacing products.

Do you see the problem and the risk now?

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[dubl-u]

You're missing the point.

McVoy said that the guy was in violation, ergo no license.

The bit you're complaining about was meant to show that even if McVoy felt like being nice, it was clear that Collins had been a prick about exactly the kind of issue he was complaining about now, so that any request to keep using BitKeeper for free even though he was in clear violation of the license was hypocritical.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Tet]

Furthermore the license explicitly forbids interfacting to BitKeeper Packages by any other means than using bitkeeper, unless you comply with the license of the BitKeeper Package, which again means access to the source can be arbitrarily changed to disallow access by interfacing products.

No it doesn't. Read the BKL. What is says is that if you use BK to access a BK package, then you may only do so by complying with the license of that package. If you use other tools to access the package, then the BK licenses don't come into play at all.

Do you see the problem and the risk now?

For the kernel, no. Assume the worst. What happens then? We revert back to the previously released kernel, and start from there. Actually, it's not even that bad, because there are several up to date trees that aren't held in BitKeeper.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Compuser]

Soooo...
As I see it, the license hinges on Bit_guys' opinions.
So then it basically reduces to: "This software is
free for use by my homies. If I cease to like you,
then you pay." This in turn means that people using
free version effectively now have overhead costs,
namely keeping the McVoy guy happy.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Znork]

Ah, yeah, you're right on the first point.

"For the kernel, no. Assume the worst. What happens then? We revert back to the previously released kernel, and start from there. Actually, it's not even that bad, because there are several up to date trees that aren't held in BitKeeper."

As yet it would not be a major problem, since it's a fairly short time since the kernel source was BKized. However, revision control systems have a tendency to become a major part in how well projects work, and they tend to integrate into the workflow of a project (frankly, I cant imagine how Linus managed to keep track for as long as he did; I tend to find that managing projects without at least CVS becomes a pain even with just a few people involved in them. Heck, I even CVS'ize things I'm working on by myself if they go beyond one or two files and a few hundred lines). They also tend to get third party functionality built upon the existence of these tools, which might all have to be rewritten.

If we do assume the worst, exporting the sources would be the easy thing, even if all metadata was lost. Rearranging project workflow and starting to form a new one around another system would be the bad thing. Personally, I'd guess it'd cost about 6 months to a year before things got up to speed again.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Tet]

Rearranging project workflow and starting to form a new one around another system would be the bad thing. Personally, I'd guess it'd cost about 6 months to a year before things got up to speed again.

Yep, and on that point I agree with you, although I think the 6 months is a little pessimistic. Not every kernel developer uses BK, and I don't see that changing in the near future, even if it was GPLed tomorrow. For those that do, changing to another system will incur an overhead, sure, but I'd say 4-6 weeks is more realistic. Given the likelihood of this worst case scenario in the first place (low, IMHO, others may disagree), then I'd say the risk is small enough to be worth taking for the benefits using BK brings.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Znork]

Yeah, we agree pretty much. 6 months to a year is based on a future where bitkeeper use is the mainstream choice for kernel developers.

I also think the scenario where BK turns 'evil' over a day is unlikely; however I think it will more likely turn 'difficult' over a longer period of time. Since the 'excluded' people who cant use BitKeeper includes anyone people working for companies like IBM, Oracle, RedHat (unless they obtain specific permission) as well as anyone trying to write a versioned filesystem for linux (which, in turn, may taint people working on the IO subsystems if they work to accomodate such a filesystem) or contribute to any revisioning handling system, the list may eventually get so large that something else has to be used instead. Since the exclusion is explicity there to discourage work on competing products and it might actually work in that way, it may take longer for such alterantives to get developed, which will make the eventual transition more painful.

The advantages of BitKeeper over the previous umm... method... are indeed what makes it worth it. However, the advantages of BitKeeper over CVS or PRCS (with some stabilizing work) are not quite as large. The use of either of those for the kernel would also get more developers involved in them to adress the issues.

So, in my opinion, on one hand we have BitKeeper which is the best technical solution, but which excludes a whole bunch of developers from the advantage of revision controlled source and generates a whole lot of frustration and more or less pointless discussion, and which will have to be replaced eventually (either because it becomes too much of a license pain or because BitMover goes out of buisness (which apparently Larry McVoy thinks is likely, should anyone develop a free revision control system that solves the problems of the linux kernel)) and on the other we have CVS or PRCS which arent quite as good but which wont exclude anyone and which will evolve faster if used by such a large project.

The best long term choice IMO would be to go with the free solution.

Re:CVS is *NOT* equivalent to BK (was "Alan Cox?")

[Tet]

CVS or PRCS which arent quite as good but which wont exclude anyone and which will evolve faster if used by such a large project.

CVS is already used by more than enough people. If it was going to evolve, it would have already done so. Part of the reason it hasn't is that the design is fundamentally flawed to start with. It's easier to start from scratch than it is to fix the faults of CVS. Which is what PRCS has done to an extent, and yes, if kernel developers started using that, then perhaps it would eventually evolve to the point where it was as good as BK. But it's not good enough now, and Linux wasn't/isn't interested in the political side of using something because it's free. He's using BK because Larry kept asking him what he needed to add to BK before Linus was happy to use it, and he enhanced BK until it reached that point. Had one of the PRCS (or subversion, or arch) developers done the same thing, then maybe we'd be in a similar position but with a free solution. But it didn't work out that way. And though he may be a bit hotheaded at times, I personally believe Larry to be a net gain to our community. He gives far more than he takes, and I struggle to criticise him for it...

arch

[chris_sawtell]

It looks to me as if arch is a pretty good alternative yo Bit-Keeper.

Anybody used it for a big project?

Re:arch

[chris_sawtell]

That may or may not be the case, but remember that there are several software authors who come to mind who give one the completely erroneous impression that they are "utter twits", yet they somehow they manage to churn out brilliant software packages. I have d/led the arch thingie and wondered if it was worth investing the time to get my head around it? It's far from simple you see.

Sure are full of themselves!

[ebyrob]

From the site:

If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.

Wow... We use CVS at work and certainly haven't felt it isn't "industrial enough" to handle what we're after. Quite the opposite in fact.

Broken builds?? What do they think the last tagged version of the stable branch is supposed to be for?

"plain text" a bad thing? I find I can usually trust products that keep plain things plain, much more than ones that try to over-complexify everything. If a developer can't handle managing several checkouts of a repository in his/her own work area, he/she probably doesn't deserve the title.

RCS limitations? Be nice to see some of the most prominent listed if they are such a big deal.

The multiple repository thing does seem interesting, but I'd think if it came to where you really needed it, something could be worked out using CVS without too much work... Actually, in practice it would seem better to get everything into the main repository as quickly as possible so everyone else can start testing on the code sooner, even if there was a bit more overhead associated with doing that.

Course, maybe this BitKeeper appeals to managers more than actual developers...

Re:Sure are full of themselves!

[Sircus]

RCS limitations? Be nice to see some of the most prominent listed if they are such a big deal.

I'm betting you use cvs annotate (aka cvs blame) quite a lot, right? Consider the fact that in order to provide this functionality, CVS first internally converts its RCS file into SCCS format, then uses the temporary SCCS file to provide the annotation. RCS simply doesn't have the capability to sensibly provide this functionality on the fly.

Re:Sure are full of themselves!

[peter]

> This, my friends, is the fallacy commonly known as "appeal to autority". Tell your family and colleagues! It's fun.

From the website you linked to:
Since this sort of reasoning is fallacious only when the person is not a
legitimate authority in a particular context...

Almost everyone on /. knows who Linus is. Most would agree that he is a very talented developer. He handles submissions from lots of people every day, and keeps the kernel project going quite nicely. He is one of the best know people who is obviously in a position to evaluate software like CVS and BK. The post you replied to was phrased like a falacious appeal to authority, but it's actually a good point.

Also note that part of the issue here is whether Linus should be using BK to manage the kernel. Thus, it is a lot more relevant what Linus thinks about BK than if you were trying to decide for yourself whether to use it. I hope Linus will eventually decide that BK is too non-Free for him, or, preferably, pressures BitMover to make BK more Free.

Re:Sure are full of themselves!

[Just Some Guy]

You mean, like:

• FreeBSD 3.5 (maintenance)
  
• FreeBSD 4.6.2 (current stable branch)
  
• FreeBSD 4.7 (upcoming release, still in testing)
  
• FreeBSD 5.0 (current unstable branch)
  

...all existing in one CVS tree? You're right. CVS is so awful that it wouldn't be possible.

Re:Sure are full of themselves!

[peter]

Hmm, good point. I guess anything would seem better than what he was doing before, so of course Linus likes it. I still don't think the argument was a falacious appeal to authority, but instead a somewhat biased authority. The examples cited in the web page about appeal to authority were things like "I'm not a doctor, but I play one on TV. Use these drugs, they are good." Linus actually does use BK, and he manages a really big project with it. His opinion is relevant, especially his opinon on how much the Linux kernel benefits from the use of BK, since that is an issue as much as whether other people should use BK for other projects. The general consensus is that it's great to be able to see what Linus's tree looks like in near real time, rather than snapshots every two days. The loss of freedom is starting to mount as BK's no-cost license becomes more and more restrictive. A couple years ago, it was GPL+you have to use the open-logging stuff.

Re:Sure are full of themselves!

[ebyrob]

These guys are putting their own foot up their own ass all over the place.

Well, seeing as I work for a small company where a big project would be 5 devlopers, CVS is more than enough. Funny that we've already tried VSS and had to give it up because we couldn't reliably back things up.

Were we a lot bigger I'd figure on one of two options. Either get better at using and adding to CVS to make it more useful, or hire somebody else to manage our source for us (ala BitKeeper). Of course there is one really big issue with any proprietary solution. Vendor lock in. I could see being any one of those 3 companies and choosing CVS becuase then I knew if I ever did change to something else, I'd have multiple vendors offering to support my stuff.

Bitkeeper said it best themselves:
If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.

CVS is easy to migrate off of... Can the same be said about BitKeeper?

aegis: a free software alternative

[Anonymous Coward]

aegis (aegis.sourceforge.net) is a mature source code management solution much better than CVS and offers the same core functionality of BitKeeper (transactions, changesets) plus a lot more. Heck, there was even a proposal to use aegis to manage the Linux kernel source code, way back in 1999! See this article. Unfortunately the choice was made for non-free software. Maybe now it's time to look at that proposal again.

Re:aegis: a free software alternative

[Florian Weimer]

Aegis implements a process, not just version control, and many people are cautious about software which forces them to work in a certain way (until they have been using it for years, then it becomes The One True Way). Most Aegis newcomers who are forced to use it by the project maintainer will detest it because it encourages (forces?) them to write test cases along their changes...

However, the process implemented by Aegis closely mirrors the Linux development process: a developer makes changes, some subsystem maintainer reviews it, and Linus integrates it into the official tree. But there's a drawback: this only works if all developers have access to the same repository, on the same filesystem. :-(

Aegis has got a distributed development model, but it doesn't offer the same repository tracking features as Bitkeeper. I don't know if this is relevant in the kernel context, IIRC Linus has complained more than once that the repository tracking (which links changesets to particular repositories/revisions) prevents him from automatically applying patches to the master repository.

Re:aegis: a free software alternative

[GooberToo]

I was just looking at that project just the other day for my own use. Anyone actually using Aegis? Is it reliable (no data loss)? Is it muture and stable? I'm curious what the reasons were for using BK over this. Anyone? Has the Aeigis matured enough to be considered a serious contender with BK?

When comparing the two, what features are lacking and/or missing?

Anyone in the know what to share?

Re:Has no one here any idea of what a "business" i

[javilon]

'So many people here are getting all upset because BitKeeper is not free'

No, I am upset because it is used to develop Linux (which is free) and because is the only non free tool used to do it.

I think Linus is wrong on this, because by using it, in a way, he is forcing it upon other people involved in kernel development.

If BK where used to develop windows I wouldn't have any problem with it.

Re:Has no one here any idea of what a "business" i

[ebyrob]

Free software depends on a few companies' ability to actually make money developing and using free software.

Ya, and commercial software relies on free software to keep it honest enough that computers can actually remain a useful tool to the human race...

We all need each other, lets have a group hug.

P.S - I don't think most of the point is that bitkeeper is bad, just that it was a bad idea for the kernel to rely so heavily on a commercial product in the first place. From some posts, it even sounds like the development team could have licenses to bitkeeper that wouldn't limit what they can work on if they're ready to shell out the bucks...

If you really want to make a difference....

[croftj]

Then you should really consider starting a "free the source" fund to collect enough money for the required number of licenses needed to work on subversion.

Re:If you really want to make a difference....

[XaXXon]

Hrmm.. what I want to know is why subversion doesn't use subversion for their source control..

Re:If you really want to make a difference....

[the eric conspiracy]

I want to know is why subversion doesn't use subversion for their source control..

They do.

If only if it were so innocent

[MobyTurbo]

BitMover is just doing what we would do if the shoe was on the other foot.[...] Just like Windows is not the developer enviroment for the kernel, BitKeeper will not be the revision control software used for Subversion.

I have moderator points today, but I guess I'll give them up for this article because I don't see anyone else bringing up the most common useage in the legal field of this particular form of license agreement.Of course, IANAL. :-)

I'd agree with your perspective concerning Bitkeepers IP rights if this was the only way this clause is used in a shrink-wrap license. However, it is more often used in court in a semi-fraudulent manner. More often than not, Bitkeeper could claim that a developer was "contaminated", and unless it was *very carefully* documented otherwise, with the sort of documentation rarely available in an open-source project, it can shut down the competitition. I'd hate to think that Bitkeeper's lawyers would do something so cynical, but its a common practice with this sort of contract. About the only remedy is to start the entire project over from scratch and work in "double-clean" rooms, but that's practically impossible in an open source project.

Kudos to Bitkeeper's lawyers for proving that fascism is alive and well in the commercial software industry when it comes to competing with open source projects. Until they drop this clause open-source developers should boycott their tools, because doing otherwise is too great a risk. Maybe they'll get the message, if not, Bitkeeper will go the way of gopher, another product which got a license like this and was dropped like a hot potato by developers in favor of www, and of course the competition ended up being better. :-)

BK Summary

[mysticalreaper]

What's the short version?

A) The license forbids you to use BK to further a direct competitor to BK. Distributing a competitor, while using BK, like Red Hat does, is allowed.

B) This license is the FREE license. Remember the saying, "Beggars can't be choosers?" They can't. Are you using BK for free? Then you can't expect to choose the license. If you buy the program, you can develop whatever you like with it.

C) Anyone still has the ability to be a kernel hacker without using BK whatsoever. The old tools still work, Linus and everyone else still accepts standard patches. It's just the old tools are actually worse than BK. BK was chosen purely on technical merits, it's only the license that's raising questions.

Point B) is important. Because this is the FREE license, it means that BM is not violating anti-trust laws by forbidding competition, because you can purchase the product, and get unrestricted use. Companies are not required to provide free samples of their products to competitors to help them out. Also, it means that BM is NOT acting like MS when they pulled the same stunt in their EULA. (Adding a clause stating that you cannot use MS products to harm MS in any way).

Summary: Bit Mover is acting reasonably, and completely within their rights as a company to define the acceptable uses of their free gift to users. The issue should is not whether or not Bit Mover is 'cheating' people. The issue now is whether or not to use Bit Keeper personally.

Re:BK Summary

[fwr]

A) The license forbids you to use BK to further a direct competitor to BK. Distributing a competitor, while using BK, like Red Hat does, is allowed.

Ah, I see you choose your words carefully. I have to grudgingly agree what you say here. However, you are misleading. Distributing a competitor, while using BK may be allowed, but contributing to a competitor (while not using BK for that purpose) while using BK for a non-competing project is NOT allowed. Does RedHat contribute to any competing products? If so, and that would mean ANY of their employees, then they, and that would mean any of their employees, can not use BK for kernel development. Heck, if you were a disgruntaled RedHat employee and wanted to screw over the company all you would have to do is contribute to one of BK's competitors. Then NO OTHER RedHat employees could use BK for any purpose.

Re:BK Summary

[blibbleblobble]

"Beggars can't be choosers ... If you buy the program, you can develop whatever you like with it."

So which license did you choose for that £600 version of microsoft office?

If your beggars can't be choosers, neither can rich and generous customers in the EULA-software world.

Re:BK Summary

[Citizen of Earth]

This license is the FREE license. Remember the saying, "Beggars can't be choosers?" They can't.

This is all very nice, but they still can't do anything illegal. The restriction in the EULA, even if for a free-as-in-beer product, smacks of anti-trust and anti-trade violations. AFAIK, even a pipsqueak outfit can be sued for anti-trust violations. The first response to this EULA should come in the form of a threatening lawyergram from the EFF. Presumably BK doesn't want to spend the next ten years in court.

Re:BK Summary

[Citizen of Earth]

BK is not free software. If they do somehow end up in court for this, violating anti-trust laws, you know what Bit Mover will do? They will say, fine, if this license is illegal, there is none anymore. No free license at all. And then BK will not be free as in beer, not at all. You will not be able to get BK in a free form, you will only be able to get the pay version.

Sounds good to me! The only chance they have of being big is to use the GIF strategy of market penetration. Without that, and the the advancing open-source systems, they will be out of business within two years. They sound like big assholes to me. Fuck 'em!

Linus and Linux need to do some serious soul searching over the next couple of days anyway. If they choose to use an open system that is not quite as good today, they can be reasonable sure that it will become better than commercial software PDQ.

Re:Illegal...(it depends on the state)

[Zeinfeld]

IANAL, but a related ruling in California does make it illegal to stick non-compete clauses in an employment agreementI don't think there's a ruling in any state as to whether or not it holds for EULAs.

IANAL but the rulling you cite is not the most relevant because it is based on a provision which is specifically about employment, "[E]very contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void." (Business & Professions Code section 16600.)

While there is an employment aspect here, in particular the attempt to taint people using competing code I don't think it is the most direct grounds for invalidating the licence clause. There is no shortage of state and federal anti-trust laws. The fact that software is open source does not remove those protections, the software is also offered on commercial terms and so is a for-profit concern.

The clause is intentionally anti-competative and might well cross the line into unfair competition.

However there is another dimension here. The minute the guy attempted to enforce the license term he would be ostracised as being what the Open Source community call 'a complete and utter prick'.

EULA crosses separation of jobs

[yerricde]

why should a company develop a piece of software, and give a limited (???) version away for free in hopes of people paying for the full version, only to allow people to use the free version to create competing software?

Except the incident in question doesn't involve using the free(beer) version of bitkeeper to work on a replacement. It involves somebody who works two jobs: in one job, he uses free(beer) bitkeeper; in the other, he works on a replacement. The EULA crosses that separation of jobs by restricting the person, not the use of the software.

This isn't like the MSVC EULA

[yerricde]

After all, you don't see people complaining on LKML that Microsoft Visual Studio is not free.

The Microsoft Visual Studio EULA doesn't prohibit licensees from developing GCC. On the other hand, the free(beer) BK license prohibits users of free(beer) BK from developing revision control software, even if they don't use free(beer) BK to develop such software.

If you have to ask for price, you can't afford it.

[yerricde]

Because this is the FREE license, it means that BM is not violating anti-trust laws by forbidding competition, because you can purchase the product

Oh really? BM's web site doesn't give a price for the full version of BK. I haven't asked BM for pricing information, but last time I tried contacting a company about a software product whose price wasn't listed (some filesystem development library for NT), I got a figure of $100,000 per seat, which is more than most individual developers can afford without getting a second mortgage. By not listing the price, BM may be saying: "If you have to ask, you can't afford it."

Free tools, Free chips, RMS and LGPL

[Gerry Gleason]

Their site is uncomfortably cagey about the $price. That probably means, some suit dickers with your boss, feeling out "what the market will bear". IE the most money they can get.

You need to understand that it is exactly this issue that causes a lot of the problems. It is really worth reading all of the talk transcript from the guy who is going to debate the RIAA VP next week. It is exactly because of the desire to extract every dime available under the utility curve that leads to the desire to create non-transferable licensing (restrict right of first sale) and a host of other evils that almost everyone objects to.

How awful is it if you actually PAID MONEY for the software? Face it, if your boss doesn't have bucks, you don't have a job. Somebody's paying for the Linux kernel to be developed - if it costs 1% more, is that a big deal?

It isn't that simple. If a commercial tool is needed to participate, it limits the scope. Not everyone working on any given free source project is getting paid. Ok, so you can grab bitkeeper for free to work on the Linux kernel, that's sort of ok, but now they say you can't work on some projects if you do that. Sort of silly if you ask me, since it just gives them (BitMover) a black eye in the community and it won't slow down the development of the free alternative. It is, in fact, pretty easy to argue the opposite based on discussion of the issue here. Lots of people who were on the fence for this issue are going to move away from their product.

The transcript that I linked above makes the point that we don't actually know if BitMover is hurting or helping themselves. If they just GPLed their tool, and charged for support, commercial licenses, and other stuff, they might do better in the long run. It is a leap of faith, but you gotta ask how much the change of EULA language will hurt them in the long run. It will encourage more people to push the free alternative, and work to make that tool competetive. If it was GPLed, they would have the whole community behind them, and a lot of people would buy their books and support in gratitute for the gift of their software.

These issues are even more stark if you want to work on free hardware. The free tools are in a primitive state, so you are in a bind of choosing a less desirable tool vs something free. The producers of the commercial tools are afraid of their business drying up, so they won't do anything if it might help the free tools compete with them. You say, ok, so I'll find a tool I can use for free on free hardware even if it is closed source, but that slows down the free alternatives.

This is where you start to get just how important GPL is and why it is such an important innovation. One of the big problems in the sub-chip level hardware design is that the big tool makers have everything locked up and they don't talk to each other very well.

There are some open standards, but the whole mentality of closed intellectual property creates this situation where the best minds are all working to recreate the same tools and chip functions in each closed universe. This is even worse than it is for software because there aren't nearly as many people working in hardware as with software, and it is getting more complex just as fast.

My gut tells me that any company that makes the leap of faith and frees their intellectual property under GPL or similar terms will get back much more than they give up. It's hard, if not impossible to prove this, but instictively we know this when we look deeply at the issues.

On a side note, RMS doesn't think that the GPL is appropriate for hardware. It's bits all the way down until you start replicating the physical parts, and unlike software, it isn't possible to actually use it until you physically replicate it.

Nothing stops me from downloading the ISO images of RedHat's latest release cutting as many one-offs as I want on my CDR, or even making a run of CDs, and cutting them out of the loop completely. I can even offer my own support services to compete with RH. Doing this with chip or board level fabrication has considerably higher entry barriers, so potential "Red Hat Hardware" vendors would have less to worry about.

As long as I've come this far, I want to finish with a comment about the LGPL. From where I stand, RMS's stance on the LGPL is a take-back that is just as damaging, if not more so, as the EULA change being discussed. LGPL gives you a lot more choice in terms of integrating free and proprietary subsystems and components. Where free libraries have significantly extended functionality, he explicitly recomends GPL over LGPL. As an example if you want all the GNU goodies that make command line work so nice in bash, you have to either write your own or be ready to release your entire project under GPL. I might even agree with his goal of all software being free, but my choice is limited. What if I'm doing this work for an employer who is not ready to release the whole thing? I can't choose GPL, but I could choose LGPL.

This is the one case where I would claim that it goes beyond style, and the message itself actually hurts the movement.

We are not all the same.

[LoonXTall]

Slashdot is not a homogenous herd of clones, despite what moderation may suggest. People are different: we have different opinions, and we disagree with each other. In fact, it's been observed throughout history that once a minority movement gains some success, they fall apart because they're no longer so strongly united by that common goal. Yet those differences were always present.

However, I'm willing to listen to your argument if you can find me some post pairs made by a single person that contradict themselves, and prove that the information they had at the time of the later post was identical to the information they had at the time of the earlier one. It is perfectly reasonable to adapt to changing reality. That is, after all, the nature of survival.

Can't Work On Competition...

[MBCook]

One question: if you're making some kind of version controll system, why whould you use BK to develop it? Once it's working, wouldn't you use itself? Before it's working well enough, just do it by hand or with CVS or something.

Re: Can't Work On Competition...

[CaptainZapp]

From the Subversion FAQ

Is Subversion stable enough for me to use for my own projects?

We believe that Subversion is stable and have confidence in our code, in fact, we've been self-hosting since September of 2001--eating our own caviar so to speak. We declared alpha because we're ready for the world to try Subversion.

After 10 months of self-hosting, we haven't lost any data at all.

Hope this helps

Re:Can't Work On Competition...

[dvdeug]

One question: if you're making some kind of version controll system, why whould you use BK to develop it?

Note that the license doesn't say you can't use BK to develop the competition; it says you can't use BK if you're developing the competition. So you can't use BK to develop the kernel if you also work on Subversion.

Also, one example was that Ben Collins wanted to use BK to import the kernel into a Subversion system and keep it uptodate with the BK version.

Re:Can't Work On Competition...

[kubrick]

Ben Collins works on Subversion, and packages glibc for Debian, and does work on the Linux kernel. And he didn't send a Netwinder to Larry McVoy.

He was using BitKeeper to work on the Linux kernel, as requested by Linus; now it is impossible for him to do so because of his work on the Subversion project. A number of people feel that the development of an important Free Software project should not depend on a non-Free version management system, especially one where the rules as to who is allowed to use it keep on changing.

I wonder if it's the work on Subversion or the missing Netwinder that caused all this...

Re:Can't Work On Competition...

[Rik van Riel]

He was using BitKeeper to work on the Linux kernel, as requested by Linus;

Please stop lying. Linus never asked anybody to use bitkeeper...

now it is impossible for him to do so because of his work on the Subversion project

Please stop lying. There are a half-dozen other ways to get the latest Linux kernel source code. You don't need bitkeeper to get the latest source.

Take a deep breath...

[alienmole]

Regardless, attacking me was juvenile.

He said "Read my post again". That is not even remotely an "attack". You're being paranoid - get a grip. That's not an attack, just friendly advice.

Re:If you have to ask for price, you can't afford

[XaXXon]

nono. The short answer is that it's $5800 to buy a copy of BitKeeper, and another $1200 / year after the first year if you want to keep support and upgrades. While this is far from $100K, it's still not cheap for individuals.

Prices for BitKeeper (from BitKeeper)

[XaXXon]

Here's the actual prices for BitKeeper in PDF as they were sent to me from BitKeeper. I was interested in using it for my personal projects until this licensing garbage came along, and I had inquired on the pricing model..

If you want the short version, it's $5,800 for a single license, and then $1,200 / year starting the second year (the first year's included in the base price) for service and upgrades (and you have to keep it current. You can't just pay $1,200 3 years down and try and get upgrades).

So anyone who says that an Open Source developer should just "buy themselves a copy", isn't really understanding that you don't go to Best Buy and plunk down $50.

Re:Prices for BitKeeper (from BitKeeper)

[shlong]

$5,800 for a single license, and then $1,200 / year starting the second year...

I'd like to point out that Perforce licenses cost on a fraction of that. Plus, you can request free licenses if you are a private person and developing open source software. Look here. The company that I work buys commercial licenses for the work that my group does, and I have a free licensed server at home for my work. Everybody wins

Larry McVoy

[DustMagnet]

I know Larry McVoy (or more accurately knew him). He's brilliant, rash, and arrogant. He can do amazing things, but he's a tough guy to deal with. If you argue with him, you'd better have your facts straight. If you prove him wrong, he'll admit it. He has the biggest ego I've ever seen. When he gets into a project he doesn't stop until it's perfect. He is one truly amazing human. I'm glad to have worked with him.

The problem here is, it's his software and he can do what he wants with it. So you'll never argue him out of it. I just hope Linus will realize he made a mistake. BK is not free as in speech only free as in beer.

Blatant violation of commercial ethics

[Ektanoor]

Sorry to those who buz talk about "beggars cannot be choosers". The philosophy of Open Source and Free Software is not about begging and getting for gratis. It is an exchange, someone offers a service and ethically I have a duty to offer some feedback. It worked very well while we were a few tens of thousands. Today the masses came in and we have lots of seemingly "beggars" around. But this is not the hear of the movement and we shall keep our efforts to show people how things really develope. The problem of having supposedly "beggars" is similar to the problem of Anonymous Cowards in /.. If we take them away, we jeopardise our ideals. "Beggars" and ACs are a side effect of a world that is not perfect and which we should fight for being a little more correct. Not marginalising the masses but bringing to them the real meaning of the Open Source, Free Software and Free Speech is the real duty we shall not ever ever forget.

Now about this blatant monopolistic and ridiculous license. I may understand a commercial interest when someone declares a agreement void because I work on something that may hinder my partner. Development, production are things that are interim to a work where I and my partners should trust each other ofr a common cause. Using or developing some product while I do the same thing "on the side" for a concurrent product, is somehow a dubious behaviour from my side.

However sell/resell? Who's the jerk that wrote this license? Who's the stupid lawyer that forgets centuries of commercial ethics and practices? Who is he to hinder my right of choice and the right of choice of my clients? Any exclusivety on distributing, selling or lending anything is a conception that immediately forces a special agreement of rights and duties between two partners, sharing a common profit. Not something that "I should do or else". This is monopolism and it is ethicaly criminal to state such things in this way. No matter I get this thing for free or under a fee, claiming that I have not a right to choose what is best for me is the worst of dictatorships ever. They hinder the very principal of market with this.

Imagine this situation. I have a market. I try to find the best product so that this market lives on. Under this agreement either I cannot test their product if I sell something similar, I am forced to stop selling it to test their stuff or I have to pay them a fee to test their product. This, I would just call blackmail. If everyone starts doing it, it would be much worse than Windows EULAs.

Re:Blatant violation of commercial ethics

[JamieF]

I try not to be a grammar nazi, but seriously... your spelling, grammar, and punctuation are so bad that it's really hard to read your post at all. The whole second paragraph is such a mess that I had to read it three times and I still don't know what your point is.

Missing the point..

[lpontiac]

A lot of people seem to commenting that there's nothing wrong with BitKeeper being licensed as it is. This isn't really being argued ..

The argument is that because BitKeeper's license is as it is, that the Linux kernel developers shouldn't be using it.

Re:Missing the point..

[Rik van Riel]

And who exactly are you, to tell me which products I should or shouldn't use ?

All my patches are available in other formats too, you don't need bitkeeper to access my stuff. I'm not forcing anybody to use bitkeeper, you shouldn't try to force me to stop using bitkeeper.

Bitkeeper has improved my productivity and my contribution to open source software. Though it's not a necessary tool for my work, I'm thankful that Larry makes my work easier by allowing me to use his program.

Re:Missing the point..

[lpontiac]

And who exactly are you, to tell me which products I should or shouldn't use ?

Now, now, I was stating my view on what the issue is - not my view on the issue itself! Perhaps I should have been a bit clearer ... if BitKeeper works for the primary developers, then all the power to them.

Your work is appreciated, btw.

Re:Missing the point..

[Rik van Riel]

YOU are missing the point.
Your use of ButtKeeper sets a very bad example.
Why are you working on Linux, anyway?
Perhaps you would be more comfortable with a closed source UNIX like Solaris or HP/UX.

Personally I like on Linux because I like the system. If you really think bitkeeper users should stop working on Linux, maybe you should ask Linus to stop development of 2.5 ? ;)

As for the "bad example", you've shown a pretty bad one yourself: trying to reduce somebody's freedom of choice, under the guise of some "larger freedom". Can't get much more hypocritical than that...

Re:Missing the point..

[Rik van Riel]

Well, I can really see the convenience of using such a tool - but only if the communication between the developers follows thge push pull model.

This is not the case with Linux (the kernel) and Linus.

• Linus does pull from bitkeeper trees
• distributed repositories have much more benefits than the push/pull model, they are also needed so every developer can do version control on his/her own tree
• There are a whole number of forks of the Linux kernel tree out there, that wouldn't have been as easily possible without bitkeeper

Given that your conclusions are based on false premises I wouldn't put too much value in them. Having a distributed SCM does matter.

Re:Has no one here any idea of what a "business" i

[sjames]

So many people here are getting all upset because BitKeeper is not free. Well, there's nothing wrong with trying to make money off of some software, while helping the community at the same time.

The problem is, the 'help' to the community is made to be more like a deal with the devil, complete with the full price not being stated until after the deal is made.

I would strongly suggest to all free software developers that they stay away from BK unless they can tell (by crystal ball for example) they they will NEVER work for anyone who in BK's opinion competes with them in any way AND that they themselves will never work on anything that BK might believe will compete with them, AND FINALLY, that EVERYBODY who might become a valuable contributor to their project at any time in the future will also meet the first two conditions as well. It seems like a pretty bad bet to me.

Change of license terms

[gotan]

This example illustrates a more general problem:
Lately we see more and more license changes for existing software, BitKeeper and various Microsoft products are only the most notable cases. License changes accompany updates and patches, or it's just a document on some website that changes.

Most Software isn't ever a `finished' product, it's subject to changes called `new version', `upgrade' or `patch'. Often the customers depend on having the latest version of a software, be it for security reasons, compatibility issues, or just part of a leasing contract for the software. The software makers use these changes in the software to change the license terms in the software. In the BitKeeper example, someone using BitKeeper in a large project probably depends on it, or it would at least cause a lot of additional work and delay the project to switch from BK to something else.

This means, that even subtle license changes may have a huge effect on anyone depending on that software, done right such a license change might even ruin someones business (imagine someone using free BK on some project competing with BK, and imagine BK had gone one step further and made their "no competition" clause mandatory on all new licenses. Done just a few months before some critical timeline this might have killed the whole project. Even so any project using BK for a competing open-source product would probably have a hard time or even falter).

To protect businesses from being at the whim of software-makers there should be some regulations in place, that only allow license changes within reasonable limits, and demand that such changes are announced some time beforehand, so the customers have time to react. Most companies protect their business by making sure that they can't be cut of from any resource they depend on, they should realize that software is just such a resource and enforce license terms that don't allow for ugly surprises due to one-sided changes. But since few companies have the leverage to change Microsofts license terms i think there's a need for legislation considering software license changes.

Re:How do you distinguish

[sjames]

I do not make such a distinction. They are the same thing.

Theo de Raadt and Richard M. Stallman were right

[mirabilos]

They were right to refuse code with insecure licences
(Theo removed many code from OpenBSD because
of licence issues) and tell us that Linux is non-free
(remember the story about RMS telling us that bitkeeper
and vendor-supplied scsi code are unfree?)

I knew that Theo was right, even if I have my small
struggles with him, too.
If people want to try out free operating systems with
fewer licence issues, try out OpenBSD.

NetBSD still uses IPFilter (by Darren Reed) which
started the licence questioning in OpenBSD, and at
least FreeBSD 4.x has patented SMP code from BSD/OS
in it (that's why they started SMPng IIRC).

Re:Has no one here any idea of what a "business" i

[epine]

People who argue points of the form "sends a message" are generally describing their particular set of emotional filters which are not nearly as widespread as they might imagine. Fortunately, arguments that fail to distinguish pragmatism from compromise are quickly discarded by those who do.

Re:Has no one here any idea of what a "business" i

[Macrobat]

I'm sorry, this is wrong. The "free beer/free speech" analogy is at work here.

No business in their right mind is going to help a competitor take their market share.

Doesn't matter. If I buy a car from General Motors, GM has no right to tell me I can't taxi Ford workers to and from their workplace. That's "helping a competitor" with a product I bought from them, and if they don't like it, tough. This EULA is trying to prohibit an analogous freedom.

And as far as the "Slashdot hippies" crack and non-free software goes: this isn't about cost, as most of us (not all, but most) didn't complain about Linus using Bitkeeper in the first place. Non-free software prevents what you can do to that software; that's a choice Linus made. But even makers of non-free software don't have the right to tell you what to do with the software. Microsoft has no legal power to stop me from writing an anti-MS diatribe using MS Word, not with a (hypothetical) copy I bought from them. It's mine, that's that.

Re:Prices for BitKeeper (from BitKeeper) - removed

[XaXXon]

I just got this email from Larry McVoy informing me I had to take down the price listing. Here's the email I received:


That was clearly marked as confidential not to be disclosed. See page 7
right above the price list. Posting it is a blatent violation of our
copyright and causes our company material damage. If our lawyers find
that link still working tomorrow morning at 8am, you'll be the first
entity we have sued for copyright violation. Ask around, what you are
doing is serious with serious legal exposure for you.


I'm not exactly sure why I'm not allowed to post it, as nothing says "you may not post this", but it is copyrighted to them, but I don't really know what that means. They're probably just using the fact that they have more lawyers than me (greater than zero vs. zero) to bully me around.. but ah well. I suppose I don't really care about BK anymore.

BitKeeper's the enemy, Stallman was RIGHT

[dh003i]

No court in the nation is going to enforce those kind of EULA terms.

It would be like MS saying you can't use MS Word if your using it to write up a document critical of MS, or to write up source code for something competing with an MS product.

Most of these EULA terms are either unenforcible practically, or simply would not be upheld in a court of law. I believe the anti-competitive terms in this EULA are both. Firstly, as I said before, no court is going to enforce such non-sense. To do so would usher forth an era where every product includes a license forbidding you to use it if you work for or help a competitor. Secondly, this is simply unenforcible, or largely so. Why should anyone abide by this? There are no consequences if they don't, except perhaps being forced to stop using it. This is not a case where any financial damage enters the picture, so there's no potential cost to violating the license. Third, even if it is enforcible within the US, that can easily be side-stepped by hosting one's project outside of the US, where the US has no jurisdiction.

What really annoys me about this BitKeeper people is their audacity to say that they are actually trying to help the community. No, they are not. They are doing this to make money, not to help the community. Its fine that they want to make money, but its not fine that they try to say that a Free Software project isn't trying to help the community, and that they are. The Ben Collins was right not to help BitKeeper, as BitKeeper has now proven by these draconian licensing terms. Helping non-free projects will invariably harm the Open Source (OSI-compliant) and Free Software (FSF-compliant) communities, in several regards. Firstly, it will encourage people to use non-free software. Secondly, as non-free software will become more popular and universal, the community will become more vulnerable to draconian EULA licenses like BitKeeper's.

That aside, this is just proof that Stallman was right. You can't rely on a product with a EULA. They will always include draconian licensing terms. We should be switching over to Subversion and supporting that.

Supporting non-free software will always hurt the cause of Free Software, and will ultimately hurt development of Free Software (which includes the GNU/Hurd; GNU/Linux; and the Free-, Open-, and Net -BSDs.

Re:BitKeeper's the enemy, Stallman was RIGHT

[YoungHack]

It would be like MS saying you can't use MS Word if your using it to write up a document critical of MS, or to write up source code for something competing with an MS product.

Is this a joke? That's apparently exactly the license on FrontPage 2002. You may not disparage Microsoft.

Re:Prices for BitKeeper (from BitKeeper) - removed

[XaXXon]

So, I sent Mr McVoy an email back stating that wasn't sure exactly why I couldn't post his pricelist. He responded that it was on the price sheet and that I had missed it. He was correct about that. I had checked the top and bottom of the price listing and seen nothing regarding redistribution.

This is one of the emails I got back:


[my email quoted]
> But I suppose I'll take it down. And you're causing your company more
> material damages in what you're doing than what I'm doing.
[his email]
Actually, every time you slashdot kiddies get your undies in a bundie our
sales go up. Thanks.


Just thought I'd share that..

Re:Who am I to impose my vision?

[Lemmy Caution]

What does the size of the gun matter? All that matters is who gets the first clear shot. What, you think most gunplay is High Noon quick-draw crap?

Re:Prices for BitKeeper (from BitKeeper) - removed

[Synn]

Frankly that doesn't suprise me. From his email to Ben Collins he doesn't strike me as the most mature person in the world.

If you want to survive in business you do it through value-adding, giving the customer more than the competitor. Changing EULA's and keeping your prices "confidential"(because they're rediculously high?) doesn't cut the mustard.

Re:Bitkeeper is a service, no?

[ceejayoz]

Nope, that's an optional service - you can run it on your own server as well.

Bzzt, thanks for playing

[Xtifr]

Would it sit well with you as a kernel developer if, for instance, microsoft was using linux as their development platform for their next OS?

Bad analogy. This is more like saying that anyone who works for Microsoft or Sun or Apple is forbidden from using Linux. Even if they work in the applications division, or as a secretary or administrator. Or even someone who doesn't work for MS/Sun/Apple, but who happens to helped one of those companies track down a bug in one of their OSes. Or, for that matter, anyone who has worked on, helped with, or who works for a company that has worked on or helped with BSD! (That evil BSD is just too darned free!)

In any case, I assure you that if MS were to consider using Linux as the base for their nextgen OS, most (probably all) kernel developers would sit up and cheer! (As long as MS followed the license terms.)

For a better analogy, imagine if KDE (which used to be non-free on a technicality) became truly non-free by forbidding anyone who has worked on (or who works for a company which has worked on) any competing desktop systems from using the system (note: using, not just redistributing, which is all the GPL ever addresses).

Re:Prices for BitKeeper (from BitKeeper) - removed

[gmhowell]

Well, shit, that just cemented it for me. Thanks for the linkage attempt.

RIAA, MPAA, BK.

Re:ReIllegal that is such crap blood flows vermill

[mpe]

The EULA is a piece of crap, in general, its a bullshit pile of legalese crap and cruft, and no one ever reads them, and when they do, they find all sorts of stupid, irrelevant and contradictory crap.

A lot of EULAs appear to be made up of boilerplate, which contains a large amount of bluff, in the often correct assumption, that few people know what the actual legal situation is. If people don't know they have certain rights it can be quite easy to fool them in to believing that they don't...

And the states and the federal government, particularly a jury of peers, is likely to override bullshit EULA contracts in favor of laws protecting consumers.

Assuming the case actually got to court. Quite often threats of lawsuits are used or the plaintiff wants to stretch the thing out as long as possible (especially if they have deep pockets).

Re:Prices for BitKeeper (from BitKeeper) - removed

[Synn]

5-6K is still extremely high. MS Sourcesafe is only 600 bucks. Hell I can get .NET enterprise architect for a measly 2.5k.

MONO developers take notice....

[Jerry]

Microsoft won't be as "friendly" as McVOY in 'preventing competition', but they won't show their claws until the MONO work is essentially done and lots of Linux coders have followed the pied pipper Icaza into the .NET honeypot. THEN they will release a modified EULA preventing the use of .NET or .NET compatible tools in conjuction with GPL software projects of any kind. They have already done this with a certain SDK.

That's why I won't be using MONO or .NET. I also downloaded BitKeeper, but before I read the entire license, including the non-compete stuff. After I read it I deleted the packaged.

I'm still looking around for a CVS replacement. I will look at Subversion but does anyone know of an FTP for Arch? The Arch site is down permenantly.

A side note: Judging from the number and flavor of posts on this and other topics that diss the GPL and Open Souce, and extoll the virtues of propriatary code and restrictive EULAs, it seems to me that the number of WinXX users are consistantly exceeding the number of Linux users on Slasdot. Anyone else notice this?

Bait-and-switch will get them what they deserve.

[Futurepower(R)]

"The sad part is that many software companies tries to control HOW you use the program, WHO uses it and WHAT they use it for."

Yes, and changing the license AFTER you have already started using the software is bait-and-switch.

Thanks to this abusive policy, Bitkeeper now has tons and tons of bad publicity. With certainty, the bad publicity will cost them more than any extra money they would have made from the bait-and-switch. Incidentally, did I mention bait-and-switch?

Every company that would have paid for the Bitkeeper product interprets this sneaky activity very clearly: If they can do sneaky things to Linus, they can do this to our company, too. We should stay away from them. They are not trustworthy.

This is typical of technically capable people who know nothing about marketing and think there is nothing to know: Work for years to build the product, and sink the company in an afternoon.

Truly innovative industry leaders like Microsoft would never do something so low and mean as change the contract after companies have already decided to use the product: EULA (End User License Agreement) for a security bug fix. (Don't croak, it's a joke. Don't blink, read the link.)

VA Software, owner of Slashdot, uses a sneaky tactic, also. As you can see from the stock price, the VA Software executives are people of great business insight. At the top of every Slashdot article, it says, "The Fine Print: The following comments are owned by whoever posted them." This sounds like you own your comments, doesn't it? However, the OSDN Terms of Service says at section 4, CONTENT, paragraph 6, that they own your comments, too. It's as though Chevy sold you a car, but gave its executives the right to come around and use it, also. (I don't like sneakiness. All my comments belong solely to me. Slashdot would not have the importance it has now if the members knew that they were losing control over their writing.)

It's no fun to work at an abusive company. We are seeing a rise in the number of sneaky contracts. This seems due to, not only technically capable people who are ignorant of marketing, but also the presence of people with no technical knowledge at technically oriented companies. These people cannot contribute to the real work of the companies; all they can do is invent ways to abuse the customer.

As companies become more abusive, it becomes more miserable to work there. If you are good at what you do, quit and get a job somewhere where people are treated like people.

The final EULA: EULAs are becoming more and more abusive. I decided to jump several steps ahead and write the final EULA:

1. I can do anything I like.
2. You have no power.
3. You can't say anything bad about me.
4. Everything belongs to me.

I knew a 3-year-old who said this. He has since become an adult, which is more than I can say for some executives.

OpenSource wants to be free...and IS.

[rgsmith]

How about the SourceForge analogy?
Suppose someone were using SourceForge's free service to develop a product which would compete directly with SourceForge's commercial offering.

You mean like this?

Xoops Forge

Predictions:

[Futurepower(R)]

Predictions:

Within 18 months, Linus will stop using Bitkeeper. This will get the Bitkeeper company an enormous amount of additional free negative publicity.

Within 3 years, the Bitkeeper company will be on the edge of bankruptcy.

Within 6 years, if someone mentions Bitkeeper on Slashdot, people will say, "Bit Who?"

Re:Prices for BitKeeper (from BitKeeper) - removed

[Frater 219]

I'm not exactly sure why I'm not allowed to post it, as nothing says "you may not post this", but it is copyrighted to them, but I don't really know what that means.

The text of the price list can be copyrighted. The fact that company X offered to sell you product Y for price Z cannot, as it is expressions and not facts or ideas that are copyrighted. IANAL, but unless you're under an NDA or another contract not to disclose the prices you were offered, I think you can safely tell someone else what those prices were. Copyright on the price list just means you have to express those facts in your own words.

Re:Prices for BitKeeper (from BitKeeper) - removed

[shlong]

Printing all you source onto paper and throwing into a fire is usally safer than SourceSafe. Is it any wonder than MS doesn't "eat their own dog food" in this respect? I'm too lazy to dig up the references, but it's a well known secret that WinNT/2K/etc is developed on Perforce.

Re:Prices for BitKeeper (from BitKeeper) - removed

[forgoil]

And I who was under the impression that NT/2K/XP was developed using a piece of software that M$ bought and seems to have the same ancestory as perforce does. If someone really wants to know exactly feel free to dig it up on Microsoft's pages. They have a lot of information out there.

Source safe is, and apparently will remain so, a toy that is useful for small businesses. It does what it is supposed to do, but not much more. For hard core development I personally can recommend the excellent piece of software called perforce. Heck, they even give away free licenses to free software developers. Perforce rocks!

yes they are

[MenTaLguY]

BK is in the range of several thousand dollars per seat.

Now that Larry's got the Linux kernel development going through BK, he's trying to hold it hostage and extort money.

Regardless of intent, that's what this amounts to.

Re:Has no one here any idea of what a "business" i

[dubl-u]

No, I am upset because it is used to develop Linux (which is free) and because is the only non free tool used to do it.

Then perhaps you should go out there and write something so that kernel development can go smoothly without the use of commercial tools.

Until you release that, perhaps the Linux kernel team could carry on as it is. Linux benefits millions of people and is the poster child for the open source movement. I'd say tiny questions about its philosophical purity are vastly outweighed by the benefits that come from its progress.

Re:Prices for BitKeeper (from BitKeeper) - removed

[dubl-u]

RIAA, MPAA, BK

I see somebody had an extra bowl of Drama Flakes for breakfast.

RIAA and MPAA want complete control over all media distribution so that they can extract monopoly rents. They eagerly manipulate public opinion, corrupt our government, and sue anybody they can.

BitKeeper has so far only tried to exercise a modicum of control over the free version of their own software, so that you don't use it to put them out of business. Plus they don't want their price list public, a pretty common thing for businesses to do.

I know this is Slashdot, but you should at least try to keep your hyperbole plausible.

What do you feel is threatening you?

[Uggy]

In my company (Free software based) we get our investors always talking about competition and patenting the living shit out of everything we can get our hands on. They talk about NDA's, closing stuff, hiding stuff, denying access to etc.

My response has been and will always be: "What are you afraid of? Our clear objective is to do it better, keep our lead, solve customers' problems, give good service, and not sit on our asses and collect checks."

Just do it better. There are enough incompetent people in the world. We shouldn't have such a weak view of ourselves that we fear THEM, should we?

Investors don't like to hear that, but then I suppose, it's hard to keep fear from the equation.

If Bitkeeper really wants to be around they should just make sure their product is better than the competition's. If there exists someday a free software alternative that is as good, they they had better make sure they excel in the service area, that they respond quickly and promptly to their clients' needs.

If the free software alternative exceeds their closed source version, then they should switch to it. They could lay off part of their developers, save a bundle, and hire more service folks. They can then happily maintain their extraordinaryily content clients with the high level of support and care to which they have become acustomed.

It's really simple, IMHO. Your fear will end up consuming you until such a time as you end up nothing but an insane reactionary, screaming and hurling insults at your last loyal client.

Re:What do you feel is threatening you?

[Rik van Riel]

If Bitkeeper really wants to be around they should just make sure their product is better than the competition's.

And guess what? This is exactly what bitkeeper is doing. There are a half-dozen other ways to grab the latest Linux kernel source code, you don't need bitkeeper.

The reason people use bitkeeper anyway is that it's the best tool (for them). There is no vendor lock-in or any other reason people should use bitkeeper, except for the quality of the tool.

Don't believe me? Look at my own repository with the latest Linux kernel sources, you can grab all of them without using bitkeeper!

Re:Prices for BitKeeper (from BitKeeper) - removed

[ftobin]

I'm surprised that the PDF hasn't turned up on Gnutella, Freenet, or on newsgroups posted anonymously.

Re:legit uses for binaries in open source trees

[HiThere]

I'm not sure about sound, but *.xpm will handle most 2-D images. I'd like an equivalent format for 3-D (or n-D) objects, but I haven't yet encountered one. Still, anything that can be seen has a projective transform into a pair of 2-D image files, which xpm format can handle.

N.B.: This is more complicated than just a 2-D array of bits. You need a header that talks about value to color translation, and how wide, and how high the image is, and whether parts of it are transparent, etc. But the xpm format hadles this reasonably well. One thing it doesn't do is specify compression, but that's what gzip is for. So binary files allow you to compress images. This is sometimes important, depending on your purpose.

P.S.: Executable compiled files, however, probably require binary.

Re:"best tool" is silly

[zsmooth]

It all depends on how you define "best".

Linux proliferation

[Chris Johnson]

I was just reading another 'windows will rule for 1000 years' spiel and as always it mentioned 'unless they really do come up with a better user interface paradigm'.

Seems to me that the real silver bullet- and this article reminds me of it for very obvious reasons- will be a better user RIGHTS paradigm.

Interface is a solved problem. User rights is very much in flux. I suggest that Linux should concentrate on guarding the user (and developer) rights paradigm. Under Free Software there's no distinction anyway- you're allowed.

BitKeeper should be spanked- and it should be a wake-up call. Their need for a business model can go pound sand- it does not contribute to the better USER RIGHTS paradigm that Linux needs to be able to offer.

Re:Has no one here any idea of what a "business" i

[Nathaniel]

"So many people here are getting all upset because BitKeeper is not free."

I'm not at all upset by this change to BitKeeper, but I am even more sad than I was the last time (months ago) that I heard anything about BitKeeper.

At that time I read the licence and determined I'd be unable (unwilling) to have anything to do with Linux kernel development for the forseeable future because accepting BitKeeper's license was effectively a cost of entry that I couldn't (wouldn't) pay.

This change comes as no surprise to me, but it is pointless to say 'saw that coming', as it doesn't help eleviate the burden others are stuck with.

What makes me really sad is that other people are being forced to decide which free projects they will continue to work on and which free projects they will have to stop working on, and these painful dicsisions are the direct result of what is likely to turn out to have been a bad financial choice on BitMover's part anyway.

So much needless suffering for so little benefit.

Re:Has no one here any idea of what a "business" i

[Nathaniel]

"Their stupid license isn't what's the problem. The problem is people who refuse to consider paying for their software. Not even an option to consider? Nobody on this whole topic has even brought up the actual number of dollars - no need to, because spending money is out of the question. You're willing to hamper your project because you're not willing to even consider paying money. "

The price isn't the main objection I'm hearing people raise, but even that may be a perfectly legitimate objection based on what the price is and how much someone who wants to participate in kernel development can spend. (Remember to consider developers in foreign contries before claiming that any particular price is affordable, no matter how small it may seem to you.)

The main objection people are raising is that the license appears to require that people pick sides in an ideological conflict that shouldn't exist. Either you use BitKeeper and you side with their imposed view of which other projects you may also work on, or you reject BitKeeper's restrictions and you don't get to participate in projects that require the use of BitKeeper in order to participate.

The ideal model (which people are upset with BitKeeper for breaking) is that you may participate in whichever set of projects you wish, without artificial restrictions.

Consider a person you wants to contribute to the development of both Linux and CVS. Before this license change by BitKeeper, there were no obvious restictions on a persons ability to do this. With this new clause, such a person will have to give something up.

Re:A "take-back"?

[Gerry Gleason]

It's a take-back because the LGPL came into being because in many cases strict GPL made it difficult or at least questionable to even use GPL tools in the production of software for sale. Then much later RMS decides that too many people are using LGPL and he doesn't like it. That's a take back as far as I'm concerned. Who really cares to debate which is worse, I don't.

Making something LGPL instead of GPL doesn't make it or any derivatives any less available to the community, but it does mean there are fewer situation that you can use the code in. In my opinion it is a good thing for Free Source libraries to become widely used, and a bad thing to duplicate efforts. Limiting the use of LGPL does bad and limits good. It also makes the GPL is viral arguments true, or at least seem true and that isn't good either.

I don't have an employer to please at the moment, so I have no outside motivation to influence my opinion in this matter. You are free to think differently. The argument that GPL code is 'better' is not persuasive if it doesn't fit in their business model. Not everyone has academic salaries or other means of support, so these are real concerns of people who support the idea of Free Source in a deep way.

The no incentive to create a free alternative is bogus. If you think that, you are too concerned with the short term. In the long term the GPL model will win, and the flexibility of the LGPL is a good thing. Freedom is about choice after all.

Is this enforceable?

[Ninja Programmer]

This license stipulation doesn't sound enforceable. My recommendation: For anyone in the situtation where this applies, just violate the license. I don't think there is anything they can do to you.

CVS isn't usable (Re:Sure are full of themselves!)

[Rik van Riel]

Wow... We use CVS at work and certainly haven't felt it isn't "industrial enough" to handle what we're after. Quite the opposite in fact.

Now try using the same CVS repository with all the Linux kernel developers and part-time developers. Imagine a single CVS server with 10000 users and 3000 branches.

A source control system with a central repository just doesn't scale well enough, you need to have a system with distributed repositories and the ability to send diffs between any random developer. CVS and Subversion just don't cut it for a project as huge and active as the kernel.

Why serve the proprietary software industry again?

[GreyWizard]

The argument that GPL code is 'better' is not persuasive if it doesn't fit in their business model. Not everyone has academic salaries or other means of support, so these are real concerns of people who support the idea of Free Source in a deep way.

Proprietary software companies are not the only employers in the world -- in fact they employ less than 10% of software developers! The rest are working for companies that do something else but need specific software for some internal purpose. The right way to address the concerns of wages for free software developers is to create a robust free software industry, but even in the meantime there is no need to make the free software movement to pander to the interests and business models of proprietary software companies by watering down licenses.

Re:Has no one here any idea of what a "business" i

[nolife]

Maybe BitKeeper can't help if Subversion takes that market on its own, but they are not going to help them do it.

What if Chevy forbid you from driving your Camaro to a Ford dealer. What if Cingular Wireless blocked the customer service and sales numbers for Sprint, AT@T, or NexTel?

What if all Compaq computers were forbidden from browsing Dell websites?

You could go on and on with dumb examples.

EULA's are not some type of new law. They can restate parts of the law (copyright notice etc..)but do not make any new ones. If you violate one of the vendors addon's what is the penalty? Voiding the clickthru "contract" and giving your one copy of the software back? Big deal.

If you compete, why would you want BK for free?

[Kaz Kylheku]

Say I work on a competing version control system. Why would I care that they want to play sour grapes and deny me (so called) free use of their version control system?

I do work on a version control system, as a matter of fact. And indeed my only reason for installing BK would be to examine its good ideas and try to incorporate them into my program. Not that I care to do this, mind you, but hypothetically speaking.

Thus they are pretty damn right to demand payment for that kind of use of their product which leads to the potential erosion of their business.

And for actual version control, I use my own program, of course! I think that my program is the greatest thing; but not only that, I *must* use it so that I discover and fix bugs, and so that my experience with it grows and leads me to new directions. It would be counterproductive of me to work on this program, but then turn around and use BK or any other version control system. So I could not care less that BK doesn't want me to have free stuff; I have cooked my own dogfood and am eating that, thank you very much!

Also note that their clause works both ways. Suppose that I'm a developer working at Rational on the ClearCase product. BitKeeper could benefit from my experience; I could make contributions to their code if it was truly free. But, alas, they want me to pay for the privilege of sending them bug fixes. Oops; they will just have to lure me away from the competitor entirely. Knowledge flows both ways; what impedes one direction tends to impede the opposite one too.

Re:Prices for BitKeeper (from BitKeeper) - removed

[Lac]

He probably just means that his sales go up every day.

Owning my comments means...

[Futurepower(R)]

Owning my comments means that I alone can determine how they are used. OSDN, is, sneakily, claiming joint ownership.

Re: Perforce

[ces]

Perforce is a very nice SCM tool for large-scale projects.

They post their price list, have reasonable prices, have a free(beer)limited user version availible, and from my experience conduct themselves professionally.

Why would I want to deal with Larry and BitKeeper?

standard salesweasel bullshit

[Doktor Memory]

Sadly, "confidential" price quotes like this are more or less standard practice. The goal is to make comparison shopping impossible: the salesweasel maintains a monopoly on price information by leveraging first copyright and then contract law (post-sale) to make it impossible to find out how much your peers paid for the item that you are purchasing.

In all likelihood, both "copyrights" on price quotations and gag orders in sales contracts would never ever hold up in an actual court of law, but as you noted, he has more lawyers than you, so you lose. Isn't the american legal system wonderful?

Re:CVS isn't usable (Re:Sure are full of themselve

[ebyrob]

3000 branches?? That sounds like sheer madness... Especially on a project with such a small user base (10,000).

Re:CVS isn't usable (Re:Sure are full of themselve

[Rik van Riel]

The user base of the Linux kernel is MUCH larger than 10000. With the number of active developers on the linux kernel I think 3000 branches would even be on the low side...

Alternative Tools

[tpv]

perhaps you should go out there and write something so that kernel development can go smoothly without the use of commercial tool

I'm going to quote someone else on this one:
Kernel development for the first time becomes dependent on a non-free tool. You can pretend that this not so, that Linus could switch to another version management system at any time, but it just ain't so: SCM tools are a major part of a software development effort and replacing them is not easy once they are entrenched.

It is now incredibly hard for anyone else to develop an alternative mechanism for kernel dev.

1. Even if it is just as good as BK, then there is a cost associated with change, and that will mean that the desire to change needs to be greater than the cost of change. Possible, but not guaranteed.
2. If it is as good as BK, but radically different the cost is higher.
3. If it is not as good as BK, but still reasonablly useful, then the cost is higher still.

AFAICT, Linus never really gave opportunity for anyone to get a useful free solution to him.

Everytime anyone wanted him to use a SCM tool, he rejected it. He didn't want one. Although most people disagreed with him, they respected the fact that he didn't want one, and let him be.

But BitMover eventually managed to convince him that he needed SCM, and that BK was painless enough for him to work with.
Congratulations to them - they managed to convince a guy who was stubbornly ignoring the truth that everyone else could see.

But, Linus never put out a "tender" so to speak. He never said "I've decided that I need to improve this process. Can people suggest ways to help me?"
Instead, he (eventually) bought in on the BK idea, and ran with it.

From what I can see, Linus never really gave much option to a free tool, and now it's even harder to get him to use one.

Re:Has no one here any idea of what a "business" i

[tpv]

determined I'd be unable (unwilling) to have anything to do with Linux kernel development for the forseeable future because accepting BitKeeper's license was effectively a cost of entry that I couldn't (wouldn't) pay.

You don't need to use BK in order to do kernel dev. It probably would make you task easier if you were using BK (because the maintainers are using it) but it is not a cost of entry.

That said, I don't think Linus/Rik/etc should be using BK to work on a project that prides itself on being free.