Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4FC96B01.4080400@apache.org>
Date: Fri, 01 Jun 2012 20:23:13 -0500
From: Pedro Giffuni <pfg@apache.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:12.0) Gecko/20120506 Thunderbird/12.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
 graduation
 process)
References: <1338428718.42092.YahooMailClassic@web113506.mail.gq1.yahoo.com>
 <4FC75BEA.1070808@a-w-f.de>
 <CAKQbXgB3Rs4UJ2=BVbU8BdR4kED671=WSViO2VeM1pxccJ9udQ@mail.gmail.com>
 <4FC790BE.3050008@googlemail.com> <4FC79BA7.1060707@apache.org>
 <CAKQbXgCXRVHLVe3rrOPp0NZLD-aitQ6XQk+jtrAjzfW-RLtF6g@mail.gmail.com>
 <4FC8826B.2090600@googlemail.com>
 <CAKQbXgBcZ96LP273Q6E1SD2GpMDQDLCzAhrg3erp5YA3NbbMAw@mail.gmail.com>
 <4FC894F5.9070900@googlemail.com>
 <CAKQbXgA0s53QWOeL_qh1pBkF9RmT7GHGBGBf9khNsQgRYXu-CA@mail.gmail.com>
 <4FC96773.5090109@apache.org>
In-Reply-To: <4FC96773.5090109@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sorry to highlight something more here...

The draft (which I insist is clearer that the resolved FAQ)
says, under License Categories:

http://www.apache.org/legal/3party.html#criteriaandcategories

/"Even optional works must adhere to this policy if they are included as 
part of the Apache product."/

So even when Category B tarballs appear to be optional,
in practice they are part of the product and we shouldn't
be distributing source code.

cheers,

Pedro.

On 06/01/12 20:08, Pedro Giffuni wrote:
> Hi Ross;
>
> I don't think it's "my turn" since my issues remain unresolved.
>
> However let me recap:
>
> 1) I think just having patches that can or cannot be applied
> to category-B licensed code is OK as long as it is not the
> default.
>
> 2) I don't think we are allowed to distribute source tarballs
> in subversion. The argument in the legal FAQ would seem
> not to be specific enough:
> http://www.apache.org/legal/resolved.html#category-b
>
> " Software under the following licenses may be included in binary form 
> within an Apache
> product if the inclusion is appropriately labeled"
>
> Redistribution of Category B in small quantities is also permitted but
> both clarifications clearly imply including source code the size and
> complexity of Mozilla Seamonkey is prohibited.
>
> The draft on which the policy was based is very clear:
> http://www.apache.org/legal/3party.html#criteriaandcategories
>
> "Although the source must not be included in Apache products, the 
> NOTICE file, which is required to be included in each ASF 
> distribution,*must point to thesource 
> <http://www.apache.org/legal/3party.html#define-source>form of the 
> included binary*(more on that in the forthcoming "Receiving and 
> Releasing Contributions" document)."
>
> I don't think anyone is arguing here that the principle has changed and
> that we can include Category-B software
>
> 3) EPL and other licenses state that we must point to the source code
> used to generate the binary and this has already been pointed out by
> external developers like the COIN-OR guys.
>
> We are currently carrying outdated versions of Seamonkey
> and saxon in SVN and we are unable to point to the sources due
> to 2 reasons:
>
> 1) The specific source code is not available upstream anymore.
>
> 2) If the code is enabled (which is the default in the buildbots),
> the specific source code is patched during the build.
> I sustain that by keeping these sources in our SVN tree
> we are for all purposes forking the code and to some extent
> becoming the new upstream maintainers. Even if the original
> code is available upstream I still don't see a good reason
> to carry that code under version control.
>
> 4) I can't find a precedent among any other Apache Project
> where the ASF distributes Category-B sources in SVN, so I
> think hosting them would require a specific approval by
> legal@.
>
> My understanding is that there is work being done to have
> these issues solved on Monday.
>
> Pedro.
>
>
> On 06/01/12 18:09, Ross Gardler wrote:
>> Just bringing this item back to the top. Nobody has linked to a policy
>> that allows this or disallows it yet. However, Pedro has indicated he
>> doesn't object to this specific case.
>>
>> Can we consider this one done? If so that is good progress (thank you
>> Jurgen for making consensus possible on one specific case).
>>
>> Lets move onto the next one. Pedro raised a concern about a specific
>> case and, if I'm following right there isn't consenus on that one (I
>> wouldn't be surprised if I'm not following right since I'm tired of
>> reading the arguments that go round in circles and stopped as soon as
>> it descended again into non-specific cases).
>>
>> Can we have an equally detailed and clear description about the case
>> Pedro highlights? We only need the facts about the problem being
>> solved and the current solution, not the arguments for/against. Pedro,
>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>> can be up next (sorry to sound like a school teacher, please think of
>> me as a conductor not a school teacher - I'm not trying to patronise,
>> it's just it's very late here and I still have a client deliverable
>> that AOO has stood in the way of for the last two days).
>>
>> Once we have the facts laid out nice and cleanly lets seek pointers to
>> policy that allows or disallows the solution in place. If pointers are
>> not possible lets take the specific case to the IPMC for
>> clarification.
>>
>> Ross
>>
>