On Fri, Dec 30, 2011 at 11:13 AM, Mattmann, Chris A (388J) <chris.a.mattm...@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.
