incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Sat, 02 Jun 2012 14:02:07 GMT
Ack.  To avoid complications we could do the
svn promotion as a 2-stage copy + delete, where
the delete happens post 3.4.1 release.




>________________________________
> From: Rob Weir <robweir@apache.org>
>To: ooo-dev@incubator.apache.org 
>Sent: Saturday, June 2, 2012 9:55 AM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
> 
>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message