On Sat, Jun 2, 2012 at 9:41 AM, Joe Schaefer <[email protected]> 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 <[email protected]> >>To: [email protected] >>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 <[email protected]> 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 >>>> >>> >> >> >>
