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 11:16:33 GMT
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?

...

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

My original question in that thread was:

"What I'm interested in at this point is getting an authoritative
answer to the specific question of having GPL software in an
incubating projects SVN and, subsequently, in a TLPs SVN. This
information will feed into the wider discussions about whether having
it there is the optimal solution."

Note this is about GPL not about MPL. There are similarities but it
would be wrong to assume the conclusions there necessarily apply here.
However, the policy in question is indeed the same one so some lessons
may be drawn from that thread.

After a few false starts from other commentators Sam said:

"One of the purposes of incubation is IP clearance.  What that means is
that in order to exit incubation the distribution must conform to our
policies, which includes not distributing code under the GPL license.
Is it the intent to resolve this prior to exiting incubation?"

Elsewhere in this thread Rob states that the MPL source in question is
not in the distribution. Since the ASF *only* distributes source
releases I don't really see how this can be the case. If it is true
then why is it in our SVN?

Furthermore, in my opinion our SVN is a form of distribution (I'm not
sure if this view is also held by the VP Legal).

Back to the legal-discuss thread. In response to Sams question above I
clarified that this was the root cause of the conflicting advice the
AOO podling was getting:

"This is ultimately the question. One view is that the GPL build tool
dependency would need to be removed in order to graduate (or would be a
separate download from non-ASF hardware). However other advice is that as
long as it is not distributed in a release (source or binary) it is OK to
have a build dependency on GPL code that is stored on ASF hardware."

So, we can see this is a similar issue. It does refer to GPL rather
than MPL, so it can (and should) be argued that it is not the same
issue. Nevertheless since Rob provides this thread as evidence to
support his counter argument to Pedro lets continue...

"My expectations are that this podling would not successfully graduate
with a dependency as you described it." (Sam Ruby)

Some more unimportant distractions and I try to bring things back on
track with a closing statement:

"Jurgen has indicated that there is a plan to move away from this GPL
code before graduation, however on the dev list this plan has not yet
been finalised and my assertion that we do not, as a matter of policy,
have GPL code on our servers has been questioned by the OOo community.
I was seeking a clarification on this specific case as a test case for
other similar issues relating to GPL dependencies that will come up in
the near future (in fact have already emerged on the OOo-dev list).

I now have the clarification that I needed in order to enable the
OOo-dev discussion to proceed (thank you Sam)."

Note how I explicitly state that this issue was taken to the
legal-discuss list as a test case for similar issues. Here we are,
revisiting it with a similar case. It's interesting that the advice
from the legal team was the same advice I gave in the original
contested  thread [1].

Finally, for completeness allow me to quote from the part of the
thread Rob links to. I'd hate to appear to be ignoring the specific
evidence provided:

"In the short term, everyone agrees that checking the source of this
into ASF SVN is not acceptable." (Benson)

A statement that was, in my opinion too strong, Sam responded:

"I for one never said that.  If there is a demonstrable need coupled
with a credible plan then we could discuss how to address the issue."

Sam concludes with "Automatically installing GPL code on developer's
machines is the issue to be worked.  Once the plan is in place to
address that issue, we can
work backwards and see what we can do in the interim.  Those
discussions can be held with the larger ASF Legal board committee."

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.

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.

>> As we've said many times before the ASF is not a place where every
>> rule is written down. This has its advantages and its disadvantages.
>> The nearest I can provide is the one you linked to in your mail in the
>> above discussed thread. It can be found at
>> http://www.apache.org/legal/resolved.html#category-b
>>
>
> I understand that.  That's why I asked if you could not point to a
> policy, whether you could make a cogent argument for why something
> like this would be problematic.

If you understand that not everything is written down then you should
also understand that as a mentor I *am* the policy book. I'm certainly
an imperfect one, that's why there are other mentors and why we refer
to others where necessary.

I grow tired of arguing about policy, every other ASF podling I work
with spends time understanding why policy exists and then finds ways
to either work within it or ask for changes. Why is that not the case
here?

...

> Fine.  And if Pedro or anyone else wants to go hunting for this policy
> that may or may not exist,

The policy *does* exist. It is being expressed here by a mentor. It is
also expressed in the very threads you link to. If the policy needs to
change then make the case to those able to make those changes (the
larger ASF Legal board committee).

Pedro does not need to put effort into supporting his objection to
graduation without approval because I support his position based on
the evidence before me at this time. It is the PPMCs collective
responsibility to work to remove that objection. Each individual in
the PPMC therefore has a choice:

a) work within the policy
b) get approval for exceptions to the policy
c) ignore it and hope someone else resolves the problem before graduation
d) demonstrate to the community that the objection is not valid

I think Rob is working towards d), but either I am fundamentally
misunderstanding something or I am unconvinced. Since the last bit of
evidence is a thread I started in order to clarify the situation the
last time this arose I have nothing more to say, and hope that if
others can see my mistake they will point it out so that I may change
my opinion.

In the meantime I see different people starting to work with Pedro to
explore the options around a) and b) (thank you).

Ross

[1] http://markmail.org/message/xerohd43bh7giipk

Mime
View raw message