On Fri, Jun 1, 2012 at 9:23 PM, Pedro Giffuni <p...@apache.org> wrote: > Sorry to highlight something more here... > > The draft (which I insist is clearer that the resolved FAQ) > says, under License Categories: >
Pedro, your logic violates every principle of interpretation. If something was in a draft and then was removed from the draft, that suggests that there was not consensus for it to remain. You cannot use its removal as evidence that it is applicable. Please stick to the text of the approved policy. -Rob > http://www.apache.org/legal/3party.html#criteriaandcategories > > /"Even optional works must adhere to this policy if they are included as > part of the Apache product."/ > > So even when Category B tarballs appear to be optional, > in practice they are part of the product and we shouldn't > be distributing source code. > > cheers, > > Pedro. > > > On 06/01/12 20:08, Pedro Giffuni wrote: >> >> Hi Ross; >> >> I don't think it's "my turn" since my issues remain unresolved. >> >> 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 >>> >> >
