From owner-freebsd-current@FreeBSD.ORG Thu Mar 12 07:54:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4EB0106564A for ; Thu, 12 Mar 2009 07:54:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0A1D8FC12 for ; Thu, 12 Mar 2009 07:54:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5815346B1A; Thu, 12 Mar 2009 03:54:39 -0400 (EDT) Date: Thu, 12 Mar 2009 07:54:38 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Saifi Khan In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: ASL 2.0 based software contribution to FreeBSD code base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 07:54:40 -0000 On Wed, 11 Mar 2009, Saifi Khan wrote: > Is Apache Software License (ASL) 2.0 based software contributions accepted > in FreeBSD code base ? > > Specific case to consider would be: > a. device driver code released under ASL 2.0 > > b. code contributed to kernel (eg. scheduler implementation) > under ASL 2.0 > > c. code contributed to userland (eg. new implementation of > ctags) under ASL 2.0 > > Can some of the experienced members share how things work > within the context of FreeBSD project ? Four points, really: (0) One of the important goals of the FreeBSD Project is to produce a BSD-licensed operating system. (1) The FreeBSD Project is concerned about the level of license proliferation in the tree, and would like to avoid adding new licenses where it can possibly be avoided. There has been some recent effort to consolidate under the simplified (two-clause) BSD license for this reason, but tracking down all license holders on more-clause licenses is non-trivial. We are no longer accepting new code with the advertising clause in the general case, and we are not aware of any major producers of code still using that clause. The advent of licenses such as GPLv3 and CDDL has cost the project real developer time and real money to resolve, and that's really rather a waste. (2) Licenses such as ASL, APSL, and CDDL are significantly more complicated than most existing licenses in the tree, and as such risk being in conflict with each other. For example, can you combine code under arbitrary combinations of two or three of these licenses? Lawyers have to get involved to answer questions of these sorts. We would like not to invoke (expensive) lawyers frequently or at all. (3) In general, base kernel components to be included in the GENERIC kernel cannot be under non-BSD/MIT/ISC licenses. We do have non-BSD licensed code in the base tree, but generally under "exceptional" circumstances -- a truly compelling technical need (we require a compiler, but there are currently only GPL compilers in open source, so we have one). There is a concerted ongoing effort to remove or replace non-BSD licensed components in the system with BSD-licensed ones. The only recent exceptions in this arena have been CDDL code from OpenSolaris -- ZFS and DTrace, and with DTrace there was a significant delay in importing the code while we worked through license issues and made sure that the GENERIC kernel did not include any CDDL code. Several of our large corporate consumers have policies that CDDL code does not ship in their products and so we also have careful source tree separation. So in short: we would heavily discourage code being submitted under non-BSD licenses on the basis that our goal is to produce a BSD-licensed system, license proliferation has real-world overhead especially in terms of constrained developer and lawyer time, makes it harder for FreeBSD end-users to understand their rights and whether or not they can combine components, and when other licenses are used they require very special handling. Robert N M Watson Computer Laboratory University of Cambridge