Date: Sat, 5 Oct 2002 10:57:57 -0500
Subject: Re: New BK License Problem?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: linux-kernel@vger.kernel.org
To: Larry McVoy <lm@bitmover.com>
From: tom_gall@mac.com
In-Reply-To: <20021005081039.Z835@work.bitmover.com>
Message-Id: <37733660-D87B-11D6-A2D4-0003939E069A@mac.com>
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3694
Lines: 94


On Saturday, October 5, 2002, at 10:10 AM, Larry McVoy wrote:

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

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

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

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

> 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.

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.

> 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.

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 
<someuser@bitmover.com>
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.

> 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.

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

> 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.  <snip>

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

Thanks

Tom

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/