Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 5 Oct 2002 11:51:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 5 Oct 2002 11:51:58 -0400 Received: from smtpout.mac.com ([204.179.120.89]:33233 "EHLO smtpout.mac.com") by vger.kernel.org with ESMTP id ; Sat, 5 Oct 2002 11:51:56 -0400 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 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 X-Mailer: Apple Mail (2.546) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@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 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. 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/