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:55:53 GMT
On Sat, Jun 2, 2012 at 9:41 AM, Joe Schaefer <joe_schaefer@yahoo.com> wrote:
> 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.
>

The build doesn't use svn to retrieve the tarballs.  They are stored
in svn, but they are copied down via http, using wget.    So we could
probably solve this via a redirect.  But it would be good to avoid
that additional complexity if possible.

> I trust 3.4.1 will therefore address this issue properly
> going forward.
>
>
>
>
>>________________________________
>> From: Rob Weir <robweir@apache.org>
>>To: ooo-dev@incubator.apache.org
>>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 <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