incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Fri, 13 Jan 2012 14:43:27 GMT
On Fri, Jan 13, 2012 at 8:17 AM, Ross Gardler
<> wrote:
> On 13 January 2012 12:31, Rob Weir <> wrote:
>> On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
>> <> wrote:
>>> On 13 January 2012 01:31, Rob Weir <> wrote:
>>>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>>> <> 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
> 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.

It is worth considering how storing the source in tarballs with MD5
hashes, as opposed to individual files in a directory tree, and
clearly segregating them into a directory that is separate and
distinct from the products core ALv2-licenced code, both prevents us
from easily modifying that source code and causing such problems.  And
by not including them in releases, we ensure downstream consumers are
not confused either.

I'll suggest a few other policy considerations that are at play here as well.

One is the desire to be a good community participant, in the larger
open source community.  Regardless of license, a podling that takes
code from another OSS project and maintains a separate fork of it has
some explaining to do.  Why is it necessary to fork?  Why aren't
patches being upstreamed?   This should be an IPMC concern even if the
forked code was category-a.  This is not necessarily forbidden, but it
should be explained, since things generally work better if we don't
unnecessarily divide efforts.  A PPMC that does not have good
relations with its component providers (upstream components) may have
other difficulties with the larger ecosystem.  I'm not saying this is
the case with AOO, but this should be treated as a general policy
consideration, "How Apache projects interact with upstream component
projects and communities"

Also, Apache projects do their development work under the Apache
license.  So regardless of license category, it would odd if an Apache
project was carrying out development work on a component under a
different license.  This would be a concern even if the license were
category-a.  For example, if we forked an MIT-licensed component and
maintained our fork under the MIT license, this would be a deviation
from policy.

As you can see, both of the above are independent of license.  The
threshold questions are:  1) Are we actively working with upstream
supplies of components to ensure that they have our patches?  and 2)
Are we, as a project,  developing software under non-Apache licenses?

The "solution" of moving our MPL code outside of Apache to Google Code
does nothing at all to remove these concerns.  It is just changing
appearances, not addressing the fundamental orientation of the project
to 3rd party components.

If I were on the IPMC, and AOO came up for graduation, I wouldn't be
too concerned out the MPL license category being in SVN, so long as
the releases were in policy and so long as the PPMC could demonstrate
how they are addressing good practices related to code segregation,
etc.  I'd also want to see a demonstrated effort to upstream patches
made to 3rd party components regardless of license, and attempts made,
over time, to reduce the need for such patches.  I'd also want to be
sure that in the case of category-b components, that patches were done
only where necessary, for things like security patches, to resolve
library incompatibilities or similar, and that no active "feature
development" was being done in those components at Apache.

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

View raw message