Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 3588 invoked from network); 11 Oct 2005 08:53:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Oct 2005 08:53:35 -0000 Received: (qmail 35402 invoked by uid 500); 11 Oct 2005 08:53:31 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 35231 invoked by uid 500); 11 Oct 2005 08:53:30 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 35220 invoked by uid 99); 11 Oct 2005 08:53:29 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 01:53:29 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [205.178.146.50] (HELO mail.networksolutionsemail.com) (205.178.146.50) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 11 Oct 2005 01:53:31 -0700 Received: (qmail 21597 invoked by uid 78); 11 Oct 2005 08:53:06 -0000 Received: from unknown (HELO ?10.41.4.201?) (62.17.137.250) by mail14.netsol.inquent.com with SMTP; 11 Oct 2005 08:53:06 -0000 Received: from 127.0.0.1 (AVG SMTP 7.0.344 [267.11.14]); Tue, 11 Oct 2005 09:53:12 +0100 Message-ID: <434B7D77.3050505@cryptall.com> Date: Tue, 11 Oct 2005 09:53:11 +0100 From: Dermot Dunnion User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: harmony-dev@incubator.apache.org Subject: Re: [legal] Bulk contribution barrier to entry References: <96F9F03B-12DD-4439-87A0-870195DEE8D9@apache.org> In-Reply-To: <96F9F03B-12DD-4439-87A0-870195DEE8D9@apache.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Ooh, my first post. I've been lurking for a few weeks. It seems to me that you don't need the permission of every author, what you need is permission of every copyright owner. So, if Sun gave you full rights to use J2SE source in any fashion, you would not also need permission from every Sun employee and contractor that ever wrote any code for J2SE. The permission from each author is more applicable to an OSS-developed codebase. This distinction may help to define what we need to accept code. My personal viewpoint is that if we receive code for which we can't get clear permission, it's a significant risk to use it and we shouldn't. However, other may be less risk-averse and therefore we should vote. My idea of an outline process is: - get code - verify our right to use - one of the following: accept (clear right to use) reject (tainted code or (unclear permissions and moderate-value) ) vote(valuable code and unclear permissions) Dermot Dunnion ddunnion@cryptall.com Geir Magnusson Jr. wrote: > We've now accepted three contributions so far, and I think we have a > small problem that isn't easy to solve. > > The problem is that for a bulk contribution - something created > elsewhere and being contributed to harmony - we require that all > authors of that work are Authorized Contributors, meaning that they > hadn't been exposed to implementations of Java that weren't either > available under an open source license, or were owned by an entity > willing to give the author permission to work on other > implementations elsewhere. > > See http://incubator.apache.org/harmony/ > bulk_contribution_checklist.html Part III > > This is a very high standard, one that helps ensure clean IP > provenance for our codebase. > > However, I suspect it will be too high of a standard. For example, > suppose the Kaffe project wanted to offer a copyright license to > their codebase to Harmony? I bet it can't be done - we'd have to > chase down every contributor to the codebase and get the signed > agreement. Suppose Sun wanted to donate J2SE? :) I'm betting they > couldn't provide the necessary documentation either... > > So what do we do? > > We need to balance a few things: > > 1) Make this flexible enough that the project can choose to accept > software for which ACQs aren't obtainable from all authors. > 2) Make this strong enough that we don't put the project at > unreasonable risk, and that the consumers of the software have > confidence that the codebase is clean. > > Suggestions? One possibility is that for those that can't satisfy > the status quo framework, we have a set of questions that allow us to > understand the source of the code and the manner in which it was > developed. We'd like this to be somewhat objective yet still give > the project room to reject if it doesn't "feel right", we want the > process used and information obtained to be available to the public > so that any interested consumer of our software can understand where > it came from. > > Ideas? > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.14/128 - Release Date: 10/10/2005