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 <[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 >>> >> > > >
