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:08:03 GMT
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