Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 209.85.210.47 as permitted sender)
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
In-Reply-To: 
 <CAEk_X4ZwGxCO9qXn9wQ=ubHptupibHDniu5NCupjvYErZwwQtw@mail.gmail.com>
References: 
 <CAE9L6G0J7QygJDg9zOA546cai6tExQcDwyPYus9svSSfbup-BA@mail.gmail.com>
	<CAEk_X4ZwGxCO9qXn9wQ=ubHptupibHDniu5NCupjvYErZwwQtw@mail.gmail.com>
Date: Tue, 17 Jan 2012 14:28:47 -0600
Message-ID: 
 <CAE9L6G2Qmxp32AQ7yvPpRDQSqM=scU-A2GHB8mLySmRwDESiPw@mail.gmail.com>
Subject: Re: IP clearance for compatibly-licensed software WAS Re: DeltaSpike
 IP clarifications
From: Matt Benson <gudnabrsam@gmail.com>
To: "ralph.goers @dslextreme.com" <ralph.goers@dslextreme.com>
Cc: general@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the simple example, Ralph.  :)

Matt

On Tue, Jan 17, 2012 at 2:25 PM, ralph.goers @dslextreme.com
<ralph.goers@dslextreme.com> wrote:
> I don't have the link in hand at the moment, but lets pretend that someon=
e
> wrote some code under the GPL, LGPL or some other non-Apache license.
> Someone else takes that code and simply changes the license header to the
> Apache license. You then, with all good intent, pick up that software and
> commit it to an Apache project. This would open up the project to lots of
> bad consequences.
>
> We require IP clearance to prevent exactly this situation, or variants of
> it.
>
> Ralph
>
>
> On Tue, Jan 17, 2012 at 12:11 PM, Matt Benson <gudnabrsam@gmail.com> wrot=
e:
>>
>> This thread brings up another issue. =C2=A0During this process we have
>> encountered the sentiment that the ASF's insistence on (arguably)
>> extensive documentation to import e.g. ALv2-licensed code seems to
>> express a lack of confidence in "its own" license on the part of the
>> ASF. =C2=A0My response has been, paraphrased, that the ASF, in the inter=
est
>> of protecting its projects, may go "above and beyond" with regard to
>> IP clearance. =C2=A0With his permission, I'll paste what Red Hat's Richa=
rd
>> Fontana had to say on the matter:
>>
>> RF:
>> > > I must say that I am in strong agreement with those who expressed
>> > > puzzlement at the apparent insufficiency of the Apache License 2.0 -=
-
>> > > I understand this to mean that the ASF has no confidence in its own
>> > > license, at least when that license comes from third parties. If the
>> > > ASF isn't confident in that license when it comes from others, why
>> > > should anyone be confident in that same license when it comes from t=
he
>> > > ASF? =EF=BF=BDI don't want to make a big deal out of this, I just wa=
nt to add
>> > > my support as a lawyer to a viewpoint you're hearing from
>> > > developers. I have, in fact, raised this very question before, in a
>> > > number of contexts.
>>
>> Now, before anyone says "how dare he!" he also went on to say:
>>
>> RF:
>> > I don't mind the ASF choosing to have such IP policies,
>> > because of the unique role of the ASF and my very high degree of trust
>> > and confidence in the ASF. It's really in non-ASF contexts where I've
>> > raised the issue (for example, I recently made some comments along
>> > these lines on the OpenStack developers' mailing list). And we've been
>> > criticized on the other side, for example with Fedora. =C2=A0I guess t=
he
>> > only points of tension come about in situations like this where we
>> > have Red Hat code migrating to Apache incubator status. But, as a
>> > personal matter, and as a Red Hat employee, I am very pleased to see
>> > this happening
>>
>> So I am satisfied to accept that this is "the way it is," toe the
>> line, and put on the brave external face. =C2=A0But so I don't look like=
 an
>> idiot saying "it is what it is," is there an authoritative explanation
>> of the motivation behind our policies to which future querents should
>> be directed?
>>
>> Matt
>>
>> On Tue, Jan 17, 2012 at 1:54 PM, Sam Ruby <rubys@intertwingly.net> wrote=
:
>> > On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com
>> > <ralph.goers@dslextreme.com> wrote:
>> >> I didn't mention CCLA's on purpose. A corporation will have a CCLA on
>> >> file
>> >> to either a) declare that certain employees are permitted to contribu=
te
>> >> software or b) declare that certain software is contributed to the AS=
F.
>> >> =C2=A0A
>> >> CCLA that is on file that only includes Schedule A doesn't grant the
>> >> ASF
>> >> permission to use specific software created by the company. If the
>> >> company
>> >> is donating the software they need to specify it. If the software is
>> >> being
>> >> contributed via an ICLA then the CCLA simply says the company is givi=
ng
>> >> the
>> >> contributor the right to contribute software that normally the compan=
y
>> >> would own. However, an individual should never contribute software
>> >> under
>> >> their ICLA that they didn't author, unless they have explicit
>> >> permission
>> >> from the other authors. For a "significant" contribution a software
>> >> grant
>> >> is typically the best way to do it.
>> >
>> > I concur.
>> >
>> > Either an (additional|updated) CCLA with a concurrent software grant
>> > (Schedule B) for the code in question -or- simply a separate Software
>> > Grant would be appreciated.
>> >
>> > If RedHat is on board with this (and everything in this conversations
>> > indicated that that is indeed the case), then that shouldn't be a
>> > problem?
>> >
>> > - Sam Ruby
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>

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