incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Sat, 02 Jun 2012 01:23:13 GMT
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
>>
>


Mime
View raw message