Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <434BC2A2.7060904@kaffe.org>
Date: Tue, 11 Oct 2005 15:48:18 +0200
From: Dalibor Topic <robilad@kaffe.org>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [legal] Bulk contribution barrier to entry
References: <96F9F03B-12DD-4439-87A0-870195DEE8D9@apache.org>
 <20051011091011.GA21839@localhost.localdomain>
 <0895DA70-5FB9-4A89-B8FC-178662EE91C2@apache.org>
In-Reply-To: <0895DA70-5FB9-4A89-B8FC-178662EE91C2@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Geir Magnusson Jr. wrote:
> The issue is "did those that write this have access to an 
> implementation for which the owner of that implementation could claim 
> an interest in our code if written by those people."  For example, 
> suppose some key Sun HotSpot people came to work on a JIT here....

They'd be welcome to, afaict, as long as they don't break their
contracts with Sun Microsystems, violate their employer's trade secrets,
and do other unreasonable things, which I'd assume noone would really
want to do anyway.

Since an outsider can hardly know what the employment contracts of Sun
Microsystems and a particular individual contain, it'd be hard for them
to make the call which behaviour is legally fine, and which is not.
There is no way the outsider can be completely sure that the other party
is not acting outside of their legal framework. Somewhere trust needs to
come into the game, since it is impossible to prove that a person has
not ever looked at proprietary source code, for example, with the
current state of neural technology. :)

I believe the problem you're trying to adress has to do with 'transitive
trust': we have to trust that all pieces of a contribution chain are
legally fine. One way to get the trust is to make sure that people sign
contribution agreements, where they state that they actually have the
right to contribute the code. One also needs to trust them that their
decisions are OK.

That's somewhat simple when people are contributing their own code
they've written without looking at proprietary implementations.

It can get nicely complicated for $BIGCORP , with different licensing
schemes for different proprietary source code bases, employee migration
between different teams etc.

Again, trust has to be somewhere in the process: you have to eventually
trust either the $BIGCORP that their contribution is fine, legally, or
to trust one step further, that the copyright holders of the proprietary
source code bases potentially used by $BIGCORP are fine with $BIGCORP's
ASL2.0 licensed contribution. I don't think there is a 100% certainity
to be achieved there, without essentially knowing everything about the
legal arrangements of $BIGCORP and copyright holders of proprietary
source code bases, who worked for whom when under which contracts, etc.

I think there are two ways to deal with that (hypothetical so far, since
no $BIGCORP has donated any code, afaik) situation:

a) trust $BIGCORP to know what they are doing, and remove their code if
they screw up. Trust that the proprietary copyright holders will speak
up when they see stuff hapenning that they have doubts about. Same
procedure as usual.

Pro: Stuff happens now. $BIGCORP has skilled legal staff that can figure
out their own contractual obligations best.

Con: Possible legal issues later, may have to pull sour code, if
$BIGCORP turns out to have screwed up.

b) Get $BIGCORP to get a document from proprietary copyright holders
that says that their contribution is not infringing, and trust
proprietary copyright holders on that. For example, Sun Microsystems has
been improving on one of their source code licenses to draw a clearer
line between infringing and non-infringing use of their code, so it may
be possible for $BIGCORP to get such a statement without too much fuss.

Pro: Proprietary copyright holders give their thumbs up for
contributions, making them safe from potential submarine issues.

Con: Gives proprietary copyright holders an effective veto over what
goes into the project. Proprietary copyright holders may have no
financial interest in digging through piles of third party code and old
contracts to figure out what's OK and what's not, so they may prefer a
laissez-faire approach until they are aware of an actual, provable
violation of their contracts.

I'd suggest going with a) and relying on the proprietary copyright
holders to know best how to protect their own interests, while relying
on contributing $BIGCORP to know best what their legal arrangements
allow them to do. If code turns out to be sour, it would be purged out
of subversion repo and rewritten. There is no shortage of good runtime
code out there, or people able to (re)write it.

Something unpredictable, bad and unlikely from an unrelated third party
can happen anyhow, anytime (WWIII, Microsoft starting nuclear software
patent winter, Star Wars VII).

cheers,
dalibor topic