New BK License Problem?

I Am Not A Lawyer, but AFAIK the anti-trust laws in no way obligate a business to aid its own competitors.

Restraint of trade occurs when two competitors conspire to crush a third competitor. Who is Larry's co-conspirator in your scenario?

I can tell that this issue isn't going away quickly so here are some thoughts.

If the only thing that happens is a pile of complaints about how bad the license is, the license isn't going to change.

Try and think about this from our point of view. We provide a complex yet useful product for free. While doing so accomplishes our goal of helping the kernel community, it also puts us at far greater risk that someone will just reimplement the software. Creating this software was quite difficult and we are not in the business of providing a roadmap to our competitors, they get to find their own way.

If you want to suggest license changes do so showing that you understand why we did what we did and show how your changes accomplish that in a better way. Suggestions like "you guys are idiots, just GPL it and you can make money from support" just get ignored. Suggestions which increase, rather than decrease, our risk also get ignored.

If someone has a magic way of saying "you can use the software if and only if your use of it does not put BitMover at financial risk" I'd love to hear it. So far, however, what I'm hearing is "your license screws me and I want you to change it". I hear your complaints, but they are just noise because they are one-sided.

There are other ways to work out the problem. For example, the openlogging stuff doesn't work for researchers. We make a standard practice of providing waivers to institutions or groups who are doing pure research (not work for hire for BigFatCompany, Inc). There is no reason we can't do that for you for the non-compete clause. We're in the process of developing that language for IBM's Linux Technology Center, we can reuse it for anyone else.

Unless someone can come up with language which protects us, the license stands as is. We'll do waivers for kernel developers who happen to work at Rational or whatever as needed. It's no different than dealing with patents by Red Hat or whoever, if you are concerned about it, you can ask us to make our intentions clear to you personally in writing.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

That's somewhat analogous to the situation with Trolltech's QT, before it was GPLed.

You could do what Trolltech originally did, before they GPLed QT, and grant free licenses to developers who are developing free software - no matter who they work for. I.E. If they work for BigFatCompany, Inc, but work on kernel patches in their lunch break, they get to have a free Bitkeeper license, whether they use it on the work computer or their own laptop.

John.

I think it can go away quickly. It just a matter of how you want to address it.

The license on the whole is a good license. It's just that one claus the gives me pause.

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.

If we can fix this problem somehow, I would be a very happy camper.

How about this:

(d) Notwithstanding any other terms in this License, this License *MAY* not be available to you if you and / or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabilities of the BitKeeper Software or in the reasonable opinion of BitMover, competes with the BitKeeper Software.

For those individuals who work on Open Source Software, that is software as defined by being under a license meeting the Open Source Definition as defined on www.opensource.org, may apply for a waiver to <[email protected]> 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.

It is good to hear that you're open to being flexible. I hope that might include this case as well.

Well if you would, please have a read, Hopefully my idea sounds reasonable to you.

Thanks

Tom

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

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.

That said, what you outlined is more or less our current practice anyway. It's not clear to me that changing the license in any way other than GPLing it will shut up the whiners, so my preference is to leave it the way it is and let you ask for a waiver. The effect is the same both ways.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

The main complaint I've heard now is "if I develop a product that competes with bitkeeper, won't I be able to grab <free software project available in BK> any more ??"

A fix for this would be "make patches available from bkbits.net".

This way everybody can still get the free software, they just won't have the benefits of bitkeeper's version control or other nice luxuries.

regards,

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  [email protected] [email protected]

bkbits.net is a free service. It costs us about $1600/month in cash to run it, that doesn't count any salaries, that's just fixed costs. If rsync and/or ftp didn't use about 100x as much bandwidth to do what BK does we'd have already done what you are asking. We simply can't afford it.

But as I said to someone else, why doesn't someone register "nobkbits.net" and use BK to mirror the repos and then provide the tarballs/patches as you see fit.

I'm quite happy to help someone set this up, I'm just not willing to foot the bill. The bandwidth costs will kill you. kernel.org could do this and that would be fine with me.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

I can do this on NL.linux.org. I'm already doing it for the
2.4 and 2.5 Linux kernel trees and am willing to run the script for other bitkeeper trees too.

If people want it, just let me know.

regards,

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  [email protected] [email protected]

If this turns into a serious thing we could polish up the bkbits.net infrastructure and provide it with one extra URL that lets you get gnu style patches. I already have the code for this, I just have it disabled for bandwidth reasons.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

So are you saying I could look at Linus's tree on bkbits.net and click on a changeset and get a GNU diff?

That would be amazingly good of you, Larry.

Robert Love

No, I'm saying that I could give you the technology to do that if you wanted to host on your server. Bandwidth == money. We already have a T1 line for the kernel, we're not buying another one.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

BTW, you could save more bandwidth by compressing every data that goes out, html diffs, changelogs, patches... You are in some ways lucky to have one site which hosts really compressible data.

And concerning the hosting of the gnu patches, you could put them on another port on the same physical server, and then cap the bandwidth based on the port so that it wouldn't slow down your main activity, and still be available without upgrading your T1.

Just a few thoughts...
Cheers,
Willy

Read about the essential facilities doctrine.

A single company is considered a conspiracy under the anti-trust laws.

Hans

I'm not a lawyer either but I spend about 40% of my working hours on legal issues, such as contracts and IP law. So I'm not uninformed about the topic either.

In order for the essential facilities doctrine to apply, we have to have control of some "essential facility". If anyone wants to bring suit attempting to claim that we have control over such a facility, I wish them luck. I'm pretty sure that if I claimed BK was such a thing you'd all fall over laughing and so would a judge. That may change in the future but for now, not a chance of a judge or a jury seeing it that way, in my opinion. Feel free to sue if you feel differently.

It would be interesting case law since the suit would be over something that we give away for free. Might not matter but then again it might. I doubt the courts can compel a business to give away their products. If we were a monopoly they could compel us to sell them but I really don't see how a court could say "you have to give this away for free".

If anything, the courts seem to be going in the opposite direction. There was an interesting case recently where the courts upheld that it was illegal to take a competitor's product, play with it, and then copy the features. It was an old case, the decision just came down, but if we went to court over this stuff, that would be the first thing we'd hold up as case law which supports our position.

Unlike the slashdot kiddies, the courts seem to recognize that the real work is in the initial creation of a product, not in the replication of that product. The courts are quite supportive of that point, as well they should be. They tend to switch sides as one becomes a monopoly, but as things stand to day, that is a problem that we'll worry about if and when it happens. I have a feeling I'll be retired before then so you can argue with someone else about it.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Hi,

So labor isn't worth anything anymore?

bye, Roman

Someone's going to get sued over BK use eventually. (Probably not until after Larry retires). But I don't want it to wind up a 'scorched earth' mess where nobody can 'legally' use BK or develop on the kernel for it while some messy lawsuit is going on.

But until Larry retires, I have found it much easier to think of the Bitkeeper license as the "don't piss off Larry license". Don't antagonize Larry, or directly mess up his business model, and you'll all get along find ;P

Troy Benjegerdes | master of mispeeling | 'da hozer' |  [email protected]
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Another way to say it is "don't bite the hand that feeds you". We work hard to help the kernel team, we make the decisions we make based on the premise that we have to be healthy to continue to help the kernel team as well as our other users, and it's disheartening to get yelled it for it.

It's worth noting that the kernel's use of BK has and will continue to expose either weaknesses in BK or missing features. We already know of enough things that need engineering for the kernel (and any other kernel sized project) to keep us busy for a couple of years. If we GPLed BK today it would do two things:

1) make you stop yelling at us
2) stop BK development

It costs a lot of money to do what we are doing, we know exactly how much, and a GPLed answer won't support those costs. We have to do what we are doing in order to support the kernel team and our other users. We see no other choice and not one of you have presented a viable alternative in the last 5 years.

The reason we don't want to help our competitors is that they want to imitate us. That's fine on the surface, a GPLed clone solves the immediate problems you see, but it doesn't address how to solve the next generation of problems. You'd need a team of at least 6-8 senior kernel level developers working full time for several years to get BK to the point where it won't need to be enhanced in order to support something like the kernel for the next 20 years (or more). If we GPL it or we allow clones, all that does is stop the development. It's not a question of is there the ability in the community to do what we do, there certainly is. It's a question of will they. And the answer is no they won't or they would have already. The problems that we solve aren't new at all. They just aren't that all fun to solve. Our user base is small, they are very picky, there isn't a lot of money or fun here, so why would anyone do what we do?

You can argue all you like that I'm wrong, I'm misguided, I don't have a clue about opensource or whatever. The problem is that if I did what you'd like to see, GPL the code, and it turns out I was right, there is no turning back. That's a gamble I'm unwilling to make because I am positive of the outcome. And given what I've been doing for the last 5 years, my knowledge is probably more complete than your for this particular space. I know it isn't a popular position to take, I'd love to be the guy everyone loved instead of hated, but I'm not going to screw up BK's future and our ability to support our users to win a popularity contest.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Roughly how much would you want to raise, in order to GPL Bit Keeper? Seriously, this was done with Blender...

John.

My guess is that it would take about another $12M to do what we are planning to do. So if you were just trying to raise enough money to cover salaries, it's in that range. On the other, you need to consider that we'd like to get back more than salaries for our efforts. We're not greedy but I walked away from $60M of Cobalt stock to do BK. I also walked away from Google when there were three people there (the full story is that I din't know it was $60M at Cobalt, I was guessing more like $5-12M million, but I was fully aware of what I was giving up at Google and it was certainly more, at least it is in my opinion).

Other people here also gave up a lot. The first three years, we didn't pay anyone, we all lived off of savings. It's not unreasonable to want that back.

If we decided to GPL it, I don't see how it would make sense for us to do so for any reasonable price. Noone is going to give us $12M to then give away the IP. They want their $12M back with a return on the investment.

I hate to burst your bubble, but that's what it takes to do this stuff. Most of what we do you don't directly see, it's bugs that you never hit because we've fixed them, writing regression tests, stuff like that. It's not very fun work, but it has to be done, it's what makes BK useable. BK isn't done by volunteers because there is *no* way that anyone would do this work for free.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Oh, somebody is crazy enough to write extensive regression tests for his GPLed SCM system...

Florian Weimer 	                  [email protected]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898

Not only that, but GPLing bitkeeper while you still have a large TODO list seems like a bad thing for the software.

Once the TODO list has shrunk to zero and the whole bitkeeper team wants to move on to new and exciting things, maybe then it might make sense to GPL bitkeeper ...

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  [email protected] [email protected]

*Exactly*. And don't forget the followon stuff like integrated bug tracking. That's not done yet either. I wasn't pulling that $12M number out of thin air, it's very real.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

I can quite believe that. I wasn't thinking it was a practical suggestion straight away, but there are obviously people on this list who won't be happy until, either we stop using BK or it is GPLed, (OK, or put under another free license).

I am staying out of that argument, but if you're not entirely against the idea of, in a few years, trying to get a few large corporations to sponsor the opening of the source, that might satisfy a few people, and _maybe_, just _maybe_, put an end to this huge thread. :-)

John.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[email protected] wrote:

|>You can argue all you like that I'm wrong, I'm misguided, I don't have
|>a clue about opensource or whatever.  The problem is that if I did what
|>you'd like to see, GPL the code, and it turns out I was right, there is no
|>turning back.  That's a gamble I'm unwilling to make because I am positive
|>of the outcome.  And given what I've been doing for the last 5 years,
|>my knowledge is probably more complete than your for this particular
|>space.  I know it isn't a popular position to take, I'd love to be the
|>guy everyone loved instead of hated, but I'm not going to screw up BK's
|>future and our ability to support our users to win a popularity contest.
|
|
| Roughly how much would you want to raise, in order to GPL Bit Keeper?

Seriously, this was done with Blender...
|
| John.

Blender's parent company, NotANumber, went bankrupt.
That's not the case of bitmover I think...
And I think Larry wants to keep his own business, he has the right to do so...

- --

F. CAMI
- ---------------------------------------------------------- ~ "To disable the Internet to save EMI and Disney is the moral equivalent of burning down the library of Alexandria to ensure the livelihood of monastic scribes."
~ - John Ippolito (Guggenheim)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9oIdPuBGY13rZQM8RAggpAJ9D50jP8mJcU5MByXDraZzXgscw6QCggxDW IoCRUPTOKU5/lMtIhj5IuWk=
=XCXU
-----END PGP SIGNATURE-----

Hi,

You get what you asked for, promoting a nonfree product in a free environment will never be fun.
Can we all stop the whining now? Everyone using nonfree software should know, that he can get screwed.
BK won't be the only (distributed) source management system forever and if there should be any interoperability problems caused by BK, Linus has hopefully a good filter on his inbox.

bye, Roman

As usual, I agree with this point and think it's worth highlighting.

The GPL fanatics can flame me all they want, but that's not going to change the reality. The only thing that _will_ change the situation is a team of people getting together to develop a GPL alternative to bitkeeper.

Subversion isn't it, we can't work from the same repository with tens of thousands of people, any BK replacement would have to be a distributed system.

PRCS2 might become a suitable system, if somebody gets around to picking up its development. Arch might work too, but I remember talking to some Arch fans a while back who "were about to" import the whole kernel history into an Arch repository ... the fact that I never heard from them again makes it look like maybe Arch couldn't yet handle a repository the size of the kernel.

In short, until somebody builds a free (as in RMS-free) source control system that's as good as bitkeeper for what the kernel needs, bitkeeper is the only available tool for the job.

If you (for random values of you) care enough about bitkeeper not being free, you should probably implement something as good as, or better, than bitkeeper ;)

regards,

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  [email protected] [email protected]

Okay, settled. The bitkeeper license is the "don't piss off Larry license", and Larry agrees.

Nice to have that sorted out. Moving on...

Rob

Hi!

And

3) make me use it.

and

4) have widely-usable CVS replacement.

Even if *you* stopped developping bitkeeper, there would be plenty of other people to develop it, into way better product.

If you don't think GPLed bitkeeper can not be developed, then I do not know why you are trying to kill subversion.

Aha, you addressed that:

By the time it takes to clone you you should have "next generation" ready. If not, then you are doing something wrong.

Pavel

When do you have heart between your knees?

Subversion is a CVS replacement already.

Why aren't you using it, Pavel ?

Pavel, I know you want to kill bitkeeper. However, whining isn't going to achieve that. Turning subversion into a better tool than bitkeeper might...

I think Ben Collins already has a script to extract changesets from the kernel tree using just CSSC as a tool. Why don't you help him get those changesets imported into Subversion ?

regards,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>