incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Sat, 02 Jun 2012 14:46:08 GMT

--- Sab 2/6/12, Rob Weir <robweir@apache.org> ha scritto:
...
> 
> 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.

I think the issue is strictly policy related.
The "approved policy" is not a Bible, and even
the Bible requires to be put into context. 

AOO is not a special case in the ASF where we
interpret things we can or cannot do. I would
prefer if someone qualified (from the IPMC
perhaps) would explain to us if the policy has
changed and we are now fine with including
the sources of SeaMonkey and maintain patches
for them in SVN.

This said, I think the discussion is losing
relevance in light of the developments. I would
think the discussion has shifted from

"SHOULD we remove Cat-B tarballs from SVN" to
"HOW will we remove Cat-B tarballs from SVN".

I think this is a positive advance for the
project.

Pedro.


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

Mime
View raw message