incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Sat, 02 Jun 2012 13:41:15 GMT
FWIW, part of migrating to a TLP involves relocating
your svn tree to top-level, thereby breaking any links
to svn urls in 3.4.0's source tarball.  No we do not
support redirects for svn.a.o, and I doubt Subversion
does either.

I trust 3.4.1 will therefore address this issue properly
going forward.

> From: Rob Weir <>
>Sent: Saturday, June 2, 2012 9:37 AM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <> 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.
>> 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:
>> " 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:
>> "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 <>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message