incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Sat, 02 Jun 2012 13:37:37 GMT
On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <pfg@apache.org> wrote:
> Hi Ross;
>
> I don't think it's "my turn" since my issues remain unresolved.
>

I think Ross's idea was to stop batting this back and forth at a high
level, and instead focus on a specific file.  So get into the details
rather than talking about generalities.

So if you had to pick a single tarball that best makes your case for
it being a violation of policy, what would it be?  Which one best
illustrates your concern?

Then we can talk about the details of that file.

-Rob

> 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