BK license change
Well, now seems like a great time to discuss this. Ha.
It's come to our attention that commercial companies are abusing BK under the openlogging rules. To avoid paying for the product, they either put in no comments or obscure comments. That is a violation of the license, but good luck proving that they are doing it on purpose.
The real issue is that we know from past history that companies make changes to GPLed software and then delay access to those changes as long as they can (the GPL allows for a "reasonable" amount of lag, whatever that is).
The intent of the openlogging requirement was to allow people to work out in the open on free software, at no charge. The intent was never to allow people to work on free software without giving their changes back. I'm not commenting on people's rights to hide their changes, they can do whatever they want, but I *am* saying that we don't have support closed use for free.
I'm considering a change to the BKL which says that N days after a changeset is made, that changeset (and its ancestory) must be available on a public bk server. In other words, put a hard limit on how long you may hide.
The time period has to be long enough to cover security fixes, DaveM raised that issue. I'm thinking 90 days.
Note: public server is not limited to bkbits.net. Any public server is fine, so long as it is stable, well known, and available ~95% of the time.
I'm well aware that there are a vocal set of people who want complete freedom to do whatever they want; I don't care to hear from them. For the rest of you, would this change be a net positive?
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · Larry McVoy
Well, now seems like a great time to discuss this. Ha.
It's come to our attention that commercial companies are abusing BK under the openlogging rules. To avoid paying for the product, they either put in no comments or obscure comments. That is a violation of the license, but good luck proving that they are doing it on purpose.
Heh, I've seen real comments in the past that sure look like "no comments or obscure comments". This is usually done by people who don't like to or know how to use checking comments correctly, not them trying to hide info purposely :)
Quoted 4 lines
I'm considering a change to the BKL which says that N days after a changeset is made, that changeset (and its ancestory) must be available on a public bk server. In other words, put a hard limit on how long you may hide.
One problem might be having access to a public BK server. I know lots of people who do not want to run BK on a publicly accessible server, if for no other reason of not likening to run _any_ program they don't have to on a publicly available server.
Other companies also have restrictions on allowing programs to be run outside of their firewalls. If they want to use bk on a project, with this license change, they would have to convince the IT group to set up a bk server for their repository, which at larger companies is very hard to do :)
You might have to beef up bkbits.net if this change goes into effect, just to handle the extra repositories that might show up there.
Personally I don't care about the license change, as all my repositories are placed on bkbits.net, and I understand your frustrations with people trying to work around the spirit of your license.
Good luck,
greg k-h
Quoted 24 lines · Larry McVoy
Well, now seems like a great time to discuss this. Ha.
It's come to our attention that commercial companies are abusing BK under the openlogging rules. To avoid paying for the product, they either put in no comments or obscure comments. That is a violation of the license, but good luck proving that they are doing it on purpose.
The real issue is that we know from past history that companies make changes to GPLed software and then delay access to those changes as long as they can (the GPL allows for a "reasonable" amount of lag, whatever that is).
The intent of the openlogging requirement was to allow people to work out in the open on free software, at no charge. The intent was never to allow people to work on free software without giving their changes back. I'm not commenting on people's rights to hide their changes, they can do whatever they want, but I *am* saying that we don't have support closed use for free.
I'm considering a change to the BKL which says that N days after a changeset is made, that changeset (and its ancestory) must be available on a public bk server. In other words, put a hard limit on how long you may hide.
Quoted 6 lines
The time period has to be long enough to cover security fixes, DaveM raised that issue. I'm thinking 90 days.
Note: public server is not limited to bkbits.net. Any public server is fine, so long as it is stable, well known, and available ~95% of the time.
Does 'public server' imply that the server is running bkd for anonymous access? I have several small projects under bk that I keep in repositories that are accesible to people with an account on my server, but not to anyone else - would this be a license violation? (I have no problem with openlogging - it just encourages me to make /intelligent/ checkin comments, or some approximation thereof)
I'd prefer not to have to run bkd on my server if I don't /have/ to. Minimising the number of services available to be cracked, and all that . . .
Simon Fowler
Signature · 4 lines
PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/
Quoted 4 lines · Larry McVoy
I'm considering a change to the BKL which says that N days after a changeset is made, that changeset (and its ancestory) must be available on a public bk server. In other words, put a hard limit on how long you may hide.
More red tape is usually bad. You want to do it to protect your commericial interests? Fine. However, the GPL does not need Bitkeeper to be its robocop. GPL violations have a way of coming to light without this sort of automated enforcement.
Signature · 1 line
Daniel
Quoted 4 lines · Larry McVoy
I'm considering a change to the BKL which says that N days after a changeset is made, that changeset (and its ancestory) must be available on a public bk server. In other words, put a hard limit on how long you may hide.
OK, people have been replying in private to this raising various objections and making good points:
David Mosberger was worried that I was suggesting that not providing access to changes to GPLed code immediately (or ever, if you don't redistribute) is a GPL violation. To clarify: people can make changes to GPLed software and are only required to make those changes available if they redistribute. That's the rule. The point I was trying to make is that I wanted BK to be used for free on work which is done out in the open, not behind closed doors.
Greg KH raised the point that not everyone can have a public BK server, their IT department may not allow that. He said that bkbits.net may need beefing up if we force people out into the open (it needs beefing up anyway, but point is well taken).
Itai Nahshon raised several points about encrypted software, illegal under the DMCA software, etc.
Jonathan Corbet raised the point of exposing software that isn't done yet, which may have security holes, and/or other problems.
There were others, but this gives you a feel. In general, I'm getting the message that forcing everything out into the open isn't always going to be a good thing.
Yet I still have the problem of people abusing the system (not to mention the "spirit" of free software). What I'd like is a way to qualify that "abuse" and put that in the license, and what I'm hearing is that any blanket statement may be a net negative for someone who should not be adversely affected.
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
b) buy closed use seats, or
c) cease to use the product.
and then apply it to the abusers of the system. I understand this is still a scary thing in that there is no guarentee that we won't knock on your door, but the reality is that people always find ways to avoid the intent of licenses and we need some recourse. At least this way doesn't force this upon everyone, you have to exhibit some bad behaviour in order for us to notice.
If you have a better idea on how to shut down the abusers without scaring the legit users, I'm all ears.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 4 lines · Larry McVoy
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
That's going beyond what the gpl requires. Nobody needs to share their changes unless they distribute the binaries.
Quoted 10 lines
b) buy closed use seats, or
c) cease to use the product.and then apply it to the abusers of the system. I understand this is still a scary thing in that there is no guarentee that we won't knock on your door, but the reality is that people always find ways to avoid the intent of licenses and we need some recourse. At least this way doesn't force this upon everyone, you have to exhibit some bad behaviour in order for us to notice.
Quoted 2 lines
If you have a better idea on how to shut down the abusers without scaring the legit users, I'm all ears.
No need to play mall cop.
Signature · 1 line
Daniel
Quoted 6 lines · Larry McVoy
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
b) buy closed use seats, or
c) cease to use the product.
A (IMO -- feel free to debunk me :)) troublesome point is dead software.
What do I do if I start a project under BK, code on it for three months, and abandon the project / slack off / have the manager kill it.
Are they still obligated to make the software public?
Jeff
Quoted 8 lines · Daniel Phillips
Quoted 4 lines · Larry McVoy
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
That's going beyond what the gpl requires. Nobody needs to share their changes unless they distribute the binaries.
But according to the license under which they use BK, they _do_ need to make them public.
Quoted 4 lines
Quoted 2 lines
If you have a better idea on how to shut down the abusers without scaring the legit users, I'm all ears.
No need to play mall cop.
Isn't that you calling the kettle black? ;-)
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Quoted 13 lines · Andreas Dilger
Quoted 8 lines · Daniel Phillips
Quoted 4 lines · Larry McVoy
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
That's going beyond what the gpl requires. Nobody needs to share their changes unless they distribute the binaries.
But according to the license under which they use BK, they _do_ need to make them public.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
If you have a better idea on how to shut down the abusers without scaring the legit users, I'm all ears.
No need to play mall cop.
Isn't that you calling the kettle black? ;-)
Larry's proposing to turn BitKeeper into an automated GPL enforcement machine, even poking it's nose into areas the GPL isn't concerned about. This is a horribly broken reason for adding let more t&c's do the license.
Frankly, I'm finding the whole BitKeeper experience something of a turn-off. This is clearly not 'just for fun'. OK, I'll make a very serious effort to stay out of this now.
When I came into this I had a high regard for BitKeeper and every intention of using/supporting it. That's changed, now that I have a feeling for the mob mentality behind it.
Signature · 1 line
Daniel
Quoted 8 lines · Jeff Garzik
Quoted 6 lines · Larry McVoy
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
b) buy closed use seats, or
c) cease to use the product.
Quoted 6 lines
A (IMO -- feel free to debunk me :)) troublesome point is dead software.
What do I do if I start a project under BK, code on it for three months, and abandon the project / slack off / have the manager kill it.
Are they still obligated to make the software public?
What I had in mind was having BK refuse to build changesets on top of more than 3 month old changesets. So you would get a 3 month window in which to play around and either kill it, leave it alone, or publish it.
I'm not sure it's going to work, I think people have a legit point that there are legit uses for which this doesn't work.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 3 lines · Daniel Phillips
Larry's proposing to turn BitKeeper into an automated GPL enforcement machine, even poking it's nose into areas the GPL isn't concerned about. This is a horribly broken reason for adding let more t&c's do the license.
You didn't read Larry's initial email very close. He isn't trying to turn BK into a GPL enforcing machine, he's trying to turn BK into a BK License enforcing machine. Larry lets certain people (such as linux kernel hackers) use BK for free. He does that specifically for contributors to open source projects. Some people are, in essence, signing up to use the software as though they are working on open source projects but they are never actually open sourcing their work (or are intentionally obfuscating parts of it). Since that violates the spirit of what Larry is trying to do by letting people use BK in a non-commercial manner, he is trying to find appropriate wording and possibly algorithms that can be put into BK to enforce the original spirit of the free use license that BK allows certain people. So, he's not poking his nose into the GPL, he's trying to find a way to make sure that people who claim to be using BK on GPL projects (and free of charge as a result) are actually doing so. That's perfectly within his rights as owner of BK.
Signature · 4 lines
Doug Ledford <[email protected]> 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606
Quoted 8 lines · Doug Ledford
Quoted 3 lines · Daniel Phillips
Larry's proposing to turn BitKeeper into an automated GPL enforcement machine, even poking it's nose into areas the GPL isn't concerned about. This is a horribly broken reason for adding let more t&c's do the license.
You didn't read Larry's initial email very close. He isn't trying to turn BK into a GPL enforcing machine, he's trying to turn BK into a BK License enforcing machine.
Quoted 9 lines · He
The real issue is that we know from past history that companies make changes to GPLed software and then delay access to those changes as long as they can (the GPL allows for a "reasonable" amount of lag, whatever that is).
The intent of the openlogging requirement was to allow people to work out in the open on free software, at no charge. The intent was never to allow people to work on free software without giving their changes back.
It looks like GPL enforcement is the pretext for the changes. Ah well, it's not my concern, he can make BitKeeper as intrusive as he likes, fortunately I am not going to be annoyed by that because I'm just taking a pass on the whole thing. Thanks to the recent discussion, which opened my eyes.
I'm glad it's helping Linus to scale, much as Microsoft Office helps office workers to scale. That's good I suppose. I keep telling myself.
Quoted 6 lines
Larry lets certain people (such as linux kernel
hackers) use BK for free. He does that specifically for contributors to open source projects. Some people are, in essence, signing up to use the software as though they are working on open source projects but they are never actually open sourcing their work (or are intentionally obfuscating parts of it).
Wait. I thought people were perfectly able to do whatever they wanted with BitKeeper, so long as they use the open logging. I guess I was wrong about that. This is getting more anal all the time.
Quoted 5 lines
Since that violates the spirit of what Larry is
trying to do by letting people use BK in a non-commercial manner, he is trying to find appropriate wording and possibly algorithms that can be put into BK to enforce the original spirit of the free use license that BK allows certain people.
It's impossible not to read that as 'add more restrictions'.
Quoted 4 lines
So, he's not poking his nose into the GPL, he's
trying to find a way to make sure that people who claim to be using BK on GPL projects (and free of charge as a result) are actually doing so. That's perfectly within his rights as owner of BK.
Indeed. Just one more reason to build a replacement I suppose.
Signature · 1 line
Daniel
Hi!
Quoted 8 lines
So that leaves a more selective approach. We can add a clause that says we reserve the right to insist you either
a) maintain your changes in public within 90 days of making them, or
b) buy closed use seats, or
c) cease to use the product.and then apply it to the abusers of the system. I understand this is
Heh. According to your license, all you have to do is to get very expensive disk. Then, put offender's file on that disk, and claim that your costs exceeded 00000 (or how much you have in the licence) and that means auto licence termination IIRC.
Oh and btw how can you change licence retroactively? Those "abusers" have right to continue to use old versions under old licences...
Pavel
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 2 lines · Pavel Machek
Oh and btw how can you change licence retroactively? Those "abusers" have right to continue to use old versions under old licences...
BK licenses become invalid as soon as a new BK version is released which contains bug fixes or behaves differently in any way.
Signature · 3 lines
Florian Weimer [email protected] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Hello Florian (&all) , BK is (primarily in this community) used by the kernel maintainers . What happens to the little guy who may make a once a year contribution & uses BK ? Also what methods of announcement for New BK versions are there ? Because as soon as a new version is advertised the copy I am using even if I am unaware of the newer version I do not have a valid license to use it . This is per your remarks below .
I'd -really- like to see what would happen if something like this were placed on the GCC sources . Me thinks linus et-al would be creating their own compiler . Just some food for thought .
Twyl , JimL
Quoted 9 lines · Florian Weimer
Quoted 2 lines · Pavel Machek
Oh and btw how can you change licence retroactively? Those "abusers" have right to continue to use old versions under old licences...
BK licenses become invalid as soon as a new BK version is released which contains bug fixes or behaves differently in any way.
--
Quoted 9 lines
Florian Weimer [email protected] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+Apologies in advance for contributing to this thread, but I think this is a fairly calm and reasonable response which sums up our position. You may not like it, but it may help to understand it.
Quoted 6 lines · Florian Weimer
Quoted 2 lines · Pavel Machek
Oh and btw how can you change licence retroactively? Those "abusers" have right to continue to use old versions under old licences...
BK licenses become invalid as soon as a new BK version is released which contains bug fixes or behaves differently in any way.
The license says that you have to upgrade if your version will not pass the current regressions. In other words, if we have fixed a problem, written a test case for it, shipped the fixed version and the test case, then yes, you need to upgrade. If it was important enough that we wrote a test case for it, it's probably something you'll end up hitting sooner or later.
This is not directed at Florian, but to the whole list:
Another thing to think about is that we need to get something from the people who use it for free. We support them, that support costs money, and if we get nothing back, we're pretty much doomed compared to any other company. What we are asking back is that you test the latest and greatest. Our business model is that we give and get to/from everyone. The free users get an expensive product for free, but they have to give back by helping shake out the bugs from the current release. The paying users have the right to sit on an old version, but they give back by paying.
It's really just an optimization problem. What we've done is to optimize for the most that we can do for the most people. I'm well aware that some free software folks hate that it isn't open source, that's just not realistic for this sort of product.
It seems like every couple of weeks someone says they don't like the BK license and they are going to rewrite BitKeeper. I have two thoughts on that: (A) I doubt it will happen, it's more work than it looks like. If you want to spend a few years working 7 days a week, be my guest. Most people don't have the stomach for it. (B) If someone did write a decent open source replacement, that would actually be OK with me. All of the people who work at BitMover are capable of doing work on much more lucrative endeavors.
In short: go build a better answer, and until you do it, how about easing off on the "BK is evil corporate software" mantra a bit? It's not evil corporate software, it's software built by people from your community, for your community, in the most acceptable we could find which was self sustaining.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
Quoted 12 lines
Quoted 5 lines
Quoted 2 lines
Oh and btw how can you change licence retroactively? Those "abusers" have right to continue to use old versions under old licences...
BK licenses become invalid as soon as a new BK version is released which contains bug fixes or behaves differently in any way.
The license says that you have to upgrade if your version will not pass the current regressions. In other words, if we have fixed a problem, written a test case for it, shipped the fixed version and the test case, then yes, you need to upgrade. If it was important enough that we wrote a test case for it, it's probably something you'll end up hitting sooner or later.
...
Quoted 2 lines
The free users get an expensive product for free, but they have to give back by helping shake out the bugs from the current release.
...and ability to change license under their backs any time you want comes as nice bonus, eh?
Quoted 2 lines
It's really just an optimization problem. What we've done is to optimize for the most that we can do for the most people. I'm well aware that
Its really you with very nice ability to blackmail anyone using BK. "We don't like you, so we are changing licence under your back. Either pay 000, or you have just lost access to your revision histories." [Oh and oone promissed it can not be .000.000 per seat in next version.]
Quoted 2 lines
In short: go build a better answer, and until you do it, how about easing off on the "BK is evil corporate software" mantra a bit? It's
BK *is* evil corporate software, with unique trapdoor capabilities, and with unique ability to take away rights from user any time it wants.
Pavel
PS: No need to reply, but I just could not stand "you have no rights because we can change licence anytime" and "we are not evil" in one mail.
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 5 lines · Pavel Machek
Quoted 2 lines
In short: go build a better answer, and until you do it, how about easing off on the "BK is evil corporate software" mantra a bit? It's
BK *is* evil corporate software, with unique trapdoor capabilities, and with unique ability to take away rights from user any time it wants.
BK is made available to us at no cost; BK is saving Linus and Marcelo a lot of work, making it possible for them to merge more patches into the kernel.
If you only spent 10% of the energy you spent complaining on making a bitkeeper replacement, maybe you'd realise that Larry is making a very useful contribution.
regards,
Rik
Signature · 3 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/
FYI - You won't see me replying to this because he's joined some others in my procmail filter, enabling me to get more work done. I love procmail.
Besides, Rik is doing a great job, thanks Rik!
To underscore Rik's point: it took 4 years of at least 6 day/week efforts by a team that varied in size from 3-8 engineers to get BitKeeper where it is today. Pavel is welcome to try and do better, but he sure as hell isn't going to do it in his spare time. Nobody is, it's a much harder problem than it looks like. I really wish people would try it and find out. Maybe I'm wrong, in which case we can all get on to doing something more fun.
Quoted 22 lines · Rik van Riel
Quoted 5 lines · Pavel Machek
Quoted 2 lines
In short: go build a better answer, and until you do it, how about easing off on the "BK is evil corporate software" mantra a bit? It's
BK *is* evil corporate software, with unique trapdoor capabilities, and with unique ability to take away rights from user any time it wants.
BK is made available to us at no cost; BK is saving Linus and Marcelo a lot of work, making it possible for them to merge more patches into the kernel.
If you only spent 10% of the energy you spent complaining on making a bitkeeper replacement, maybe you'd realise that Larry is making a very useful contribution.
regards,
Rik
Signature · 3 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Larry McVoy <[email protected]>
Date: Mon, 29 Apr 2002 12:45:14 -0700
Larry,
Quoted 5 lines
it is today. Pavel is welcome to try and do better, but he sure as hell isn't going to do it in his spare time. Nobody is, it's a much harder problem than it looks like. I really wish people would try it and find out. Maybe I'm wrong, in which case we can all get on to doing something more fun.
you are not wrong. You have your `truth'. Pavel has his one. Pavel prefers free software and its freedom. Some people here prefer using BK instead of using (objectively worse) similar GPLed software. They have the right to think that and they have the right to say so.
Yes, I too think that using BK for kernel development is politically wrong decision and in the long run it will have bad effects on free software (generally, Linux kernel and the community specially).
Do not take it as a critique. I do not want to criticize you or your colleges. You did a great job!
But releasing BK under free software license would be (for me) much better. Of course, I can not force you to change the license or something similar. You are the creator and you have the right to release your work under license you find the best! I (or anyone else) can not tell you what should be done. But we all can tell you our opinion.
But I do not think that having different `truth' qualifies people to be blackholed. Sorry, but I think you are like small child...
Signature · 4 lines
Pavel Janík
Keep it simple to make it faster.
-- The Elements of Programming Style (Kernighan & Plaugher)