community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Apache Extras Question
Date Fri, 30 Dec 2011 16:25:32 GMT
On Fri, Dec 30, 2011 at 11:13 AM, Mattmann, Chris A (388J)
<chris.a.mattmann@jpl.nasa.gov> wrote:
> Benson,
>
> You honed in on PRECISELY the 2 points I was trying to make.
> Thanks for making them so succinctly. One thing I will comment
> on explicitly (read below):
>
> On Dec 30, 2011, at 7:52 AM, Benson Margulies wrote:
>
>> There are two aspects of this situation that I want to highlight:
>>
>> First, there's a policy tension at the heart of the whole Apache
>> Extras concept that has me puzzled.
>>
>> I could point to a raft of messages from board members expressing
>> extremely vehement views in opposition to 'circumventing license
>> restrictions via github.' The idea that a PMC might take active steps
>> to put code elsewhere to address license restrictions was, at least in
>> the rhetorical moments in question, anathema. Having read that email,
>> if I were a PMC chair, I wouldn't what's proposed here without an
>> explicit board approval. The implicit policy on 'extras' seemed to be
>> that it was a place for outsiders to park code that, for whatever
>> reason, wasn't contributable -- NOT a place for PMCs to park code that
>> couldn't live in Apache source control.
>
> Your "for whatever reason that wasn't contributable" to me is precisely
> a reason to "park code that couldn't live in Apache source control". The
> reason it wouldn't be able to live there in my case is that it has compilation
> and run-time dependencies on LGPL code.

On this list, I think the big problem is this language in the policy:

"Projects hosted on Apache Extras are not considered official Apache
Software Foundation projects and they are also not associated, allied,
or otherwise organizationally related to The Apache Software
Foundation."

"Associated, allied, or otherwise organizationally related" is broad
enough, if you ask me, to exclude what you plan here. It's very, very,
broad. If some group of non-committers turned up on your dev list and
wanted to coordinate releases or APIs, this policy would bump them out
of Extras to github (at least as I read it).

So, this leaves me with two questions: could comdev write a less
comprehensive set of verbs here within the existing board@ mandate?
And is there any point to a discussion on board@ about the starting
point of all this: committers want to build glue-code to LGPL without
violating policy.

I will now go off on a tangent of an alternative approach that, for
some reason, I think sidesteps this whole business.

Let's imagine that OODT is built with Maven. Let's further imaging
that there's a profile that is off by default, that has a big fat
comment on it: "Activating this profile will incorporate LGPL
dependencies into your build." Heck, further imagine that turning it
on makes the build print out a warning and wait for the user to say
'yes' before proceeding.

It has been my understanding that this sort of thing is permissible.
I've discussed it on legal-discuss@, I've seem it used on other
projects: e.g., a w3c test suite with a restrictive license. heck,
that build didn't even stop to ask before downloading and using it in
the tests. In short, that you can't put LGPL materials into Apache
svn, and you can't make them mandatory dependencies, but there's
allowance for making them optional dependencies. If there's no other
litmus test, if downloading and building the Official Release Package
doesn't touch the LGPL stuff by default, it's good.

I imagine that Ross would like us to go get some other venue for this
discussion, so I'll stop here.

Mime
View raw message