incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Fri, 13 Jan 2012 13:51:49 GMT
On 13 January 2012 13:23, Joe Schaefer <joe_schaefer@yahoo.com> wrote:
> It's certainly an edge case, and I'm not completely convinced
> that I agree with you about it Ross.  The ASF's position on
> svn distributions is that you can put anything in there that
> you like, provided we have the legal authority to redistribute
> it.  There are no other conditions to my knowledge, which is
> why we've had GPL code amongst other code in there.

Thanks Joe. It is useful to confirm this is an edge case and thus
needs proper guidance (prior to graduation, not prior to release) from
legal@ as suggested by Pedro.

For the benefit of PPMC understanding there are many factors affecting
whether this would be OK, these include, but are not limited to:

- is the source modified
- is there a good reason not to pull the source from upstream
- is there good reason why we don't make binaries available
(preferably via upstream)
- is the component a required component

In general, it is my understanding that, the ASF prefers not to host
code that the ASF does not own unless it is the only sensible option.
So the question is whether it is the only sensible option.

Ross

>
>
>
> ----- Original Message -----
>> From: Ross Gardler <rgardler@opendirective.com>
>> To: ooo-dev@incubator.apache.org
>> Cc:
>> Sent: Friday, January 13, 2012 8:17 AM
>> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>>
>> On 13 January 2012 12:31, Rob Weir <robweir@apache.org> wrote:
>>>  On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
>>>  <rgardler@opendirective.com> wrote:
>>>>  On 13 January 2012 01:31, Rob Weir <robweir@apache.org> wrote:
>>>>>  On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>>>>  <rgardler@opendirective.com> wrote:
>>>>>>  It was said in reply to the VP Legal
>>>>>>  affairs saying "That [holding MPL code in SVN] normally is
>> highly
>>>>>>  discouraged / not allowed."
>>>>>>
>>>>>
>>>>>  You are putting words in Sam's mouth.    The topic there was
>> about
>>>>>  forking MPL components, i.e., having an Apache project act as a
>>>>>  maintainer of a fork of MPL and doing MPL development.
>>>>
>>>>  If I am putting words in Sams mouth then I apologise. However, the
>>>>  goal posts appear to be moving here. I thought I was safe quoting from
>>>>  that thread since you referred to it yourself, indicating that it gave
>>>>  approval for what you want to do. It can't be relevant in your
>> defence
>>>>  and not in mine.
>>>>
>>>>  Are we talking at cross-purposes?
>>>>
>>>
>>>  I'm trying to develop understanding.
>>
>> ...
>>
>>>  That is why it would be particularly useful if you could articulate
>>>  some reasoning behind your statements
>>
>> OK.
>>
>> The ASF chooses a very permissive licence so as to enable downstream
>> developers of the code to do whatever they want with it.
>>
>> We have strong IP policies to prevent that licence being inadvertently
>> contaminated with more restrictive licenses.
>>
>> One of those policies is to only distribute weak-copyleft in binary form
>>
>> This insistence on weak copyleft is to remove the possibility of an
>> ASF project containing modified code with more restrictive terms.
>>
>> The inclusion of source code in a ASF products is counter to this long
>> held ASF policy. The policy is documented under "How should so-called
>> "Weak Copyleft" Licenses be handled?" at
>> http://www.apache.org/legal/resolved.html
>>
>> The question then arises as to whether holding source tarballs in SVN
>> and distributing only binaries with AOO releases is counter to this
>> policy or not. In my opinion it is. I have confirmed this, to my own
>> satisfaction, and provided references to discussions on the topic in
>> this thread.
>>
>> Some argue that this is not the case, or at least is too restrictive
>> for the project. Fine - then go and ask if the policy applies in this
>> case. The advice of your mentor is that it does apply.
>>
>>
>>>
>>>>  ...
>>>>
>>>>>  You might check out this thread for another angle on the subject,
>> also
>>>>>  from Sam, dealing with dev tools:
>>>>>
>>>>>  http://markmail.org/message/jnuec5saca7wjoue
>>>>
>>>>  It's interesting that you should refer to that thread. Notice that
>> it
>>>>  is me who started that thread. I spent my personal time on the
>>>>  legal-discuss thread because my position [1] as a mentor was not
>>>>  accepted as being correct by the community. Funny how I find myself in
>>>>  exactly the same position again and again.
>>>>
>>>
>>>  <snip>
>>>
>>>>
>>>>  I'm really not sure why Rob thinks this thread supports the
>> position
>>>>  that no policy of "no copyleft in our servers". I'm sure
>> I must be
>>>>  missing something. I therefore looked back at Pedro's original
>>>>  objection and realise that he his objecting to both a release and
>>>>  graduation. Perhaps this is the point of confusion.
>>>>
>>>
>>>  You are getting lost in the weeds.  The point about that thread, or at
>>>  least what I hoped would catch your eye, was Sam's statement, which he
>>>  says in several other threads, so I'd consider it to be something
>>>  worth understanding as a general rule, is that technical workarounds
>>>  to ASF policy are not acceptable.  Specifically, if something is out
>>>  of policy for a release, then moving it to another host does not solve
>>>  the problem.
>>
>> I am not arguing against that point. I'm not sure why you think I am.
>> I make it clear below what my argument is.
>>
>> ...
>>
>>>>  My support is for Pedro is limited to the graduation point. AOO can do
>>>>  a release from the incubator in this way, but in order to graduate it
>>>>  needs to either get approval for hosting of copyleft code or it needs
>>>>  to remove it.
>>>>
>>>
>>>  In other words, you agree with me, that this is not a problem for our
>>>  release.
>>
>> I do.
>>
>>>  I realize there are additional graduation requirements.
>>
>> Good.
>>
>>>  There were shorter ways of saying this.
>>
>> Ho Hum...
>>
>> Ross
>>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Mime
View raw message