Furthermore addressing this issue from a legal perspective misses the point- the org will certainly permit you to distribute Category-B sources for things that only are useful when compiled on the target host. The point is that you should be distributing dependencies from either the mirrors using a deps (source) tarball, or you should fetch them from their non-apache original locations. Longstanding infra policy is that *only* our mirror system is appropriate for distributing source releases and their dependencies. Distribution of "tarballs" in support of a release directly from svn.a.o violates infra policy just as much as distribution from any other apache.org website would be. I'm not sure we've written this down anywhere but it is certainly well-understood as infra policy for as long as I have worked here as a contractor.
HTH >________________________________ > From: Joe Schaefer <joe_schae...@yahoo.com> >To: "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org> >Sent: Saturday, June 2, 2012 9:41 AM >Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the >graduation process) > >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 <robw...@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 <p...@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 >>>> >>> >> >> >> > >
