incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: [Vote] Incubating Project Policy
Date Sat, 03 Feb 2007 10:41:02 GMT
On 2/2/07, James Margaris <jmargaris@nexaweb.com> wrote:
>
> Doesn't this fall under the general "develop on the list" practice? I
> would assume that developing on the list includes mentioning when you
> are going to do something like swap out a library for a newer version.
>
> Can someone articulate what problem this new policy proposal is
> addressing and how it addesses it?
>
> It is very difficult for me to see what the goal here is and if that
> goal is being achieved.

i see at least two different aspects here (as often happens at apache,
bill's trying to address number issues with a single rule)

others have done a good job of explaining some of the community
building reasons. i'll do my best to explain some of the legal ones.
hopefully others will jump and correct any mistakes...

from a legal perspective, original code developed by a committer is
covered by the CLA and contributed submitted through JIRA are covered
by clause 5 in http://www.apache.org/licenses/LICENSE-2.0. developers
(whether committers or contributors) who do not have the required
rights cannot lawfully make contributions.

committers need to ensure that they have the necessary rights for any
works they submit.

documents which are not covered by the above agreements need to be
handled carefully. code developed elsewhere which imported using a
software grant can be treated as if it were original code. but if a
project relies on only a compatible license then special treatment is
required to ensure that both the committers and apache are protected
from potential legal action. apache is a not for profit foundation so
there is also an ethical perspective: we should respect other licenses
and not cut corners legally. in short, code with compatible licenses
needs to be managed differently from code submitted under a
contribution agreement.

committers who commit code from others without having the right legal
structures in place are exposing themselves and others to considerable
legal risk.

the easiest way to kill an open source project is to target release
managers by legal means. without releases, the open source
infrastructure would fall apart. release managers accept considerable
legal risk.

for example, i live in the UK. if a committer on a project i release
makes a mistake and commits code for which they do not have rights, i
face sequestration of assets and five years in an overcrowded english
prison. so yes, i care about ensuring that the released codebase is
clean.

apache tries to find ways to moderate these legal risks. we try to
keep rules and structures to the minimum required to ensure acceptable
moderation of these risks.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message