forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject plugins with some excluded licenses
Date Mon, 03 Jul 2006 09:48:33 GMT
This thread was started on the PMC list, but has been moved here without 
any real discussion - see below for the reasoning.

David Crossley wrote:
> Ross Gardler wrote:
> 
>>[This is sent to the PMC initially so we can formulate a proposal before 
>>discussing in the open. I've done it this way as it affects the growth 
>>and mangement of Forrest and would like for the PMC to reach agreement 
>>before we move to the dev list.]
> 
> 
> It is a hard call, but this discussion really should
> happen in the open. The community will wonder that
> stuff gets discussed in secret.
> 
> 
>>I'm working on an OSCommerce plugin (see mail thread with Brian). This 
>>plugin has a dependency on Hibernate which is LGPL and therefore cannot 
>>be housed here in Apache.
>>
>>I've requested a project "Forrest Plugins" on Sourceforge to house this 
>>work. I will also put the s5 plugin up there. I'd also like to 
>>generalise the OSCommerce plugin (when time permits) so that it provides 
>>a generic framework for input plugins pulling data from relational 
>>databases.
>>
>>The idea of housing the source code here, but requiring the user to 
>>download LGPL jars independently did occur to me, but that would break 
>>the auto install feature of plugins. So a separate distribution location 
>>makes sense, at least to me.
> 
> 
> Is that such a big problem? It would be an obvious
> configuration failure.
> 
> See http://people.apache.org/~cliffs/3party.html#options
> 
> This is an optional plugin so i don't see the problem
> with having the code here and making the remote jar
> their responsibility.

Yes. It is a problem. My users (as opposed to Forrest users) would not 
want to have to deal with such failures, that's why I built the 
auto-install facility in the first place.

> We can automate its download if i read that above doc
> correctly as long as we make them aware and show the
> license.

Yes, this is something we have discussed in the past. It is something 
that I intended to implement (and to an extent still do). However, there 
is a problem. Each time the plugin is upgraded (or at least a lib it 
depends on) the instalaltion would have to be repeated.

This is not a problem is the user has write access to the Forrest 
install directory, but we have seen from our user lists that this is not 
always the case. So the auto-install/upgrade features would not work.

>>My question to the community is how to manage this SF project.
>>
>>I can make it a completely distinct project from Forrest, with its own 
>>mailing lists and committer list. Or I can just use it to house the 
>>plugins that can't live here.
>>
>>My own preference is to have it as a home only and keep all discussion 
>>and community work here in Forrest. I would like to give commit access 
>>to the SF project automatically to anyone who is given commit access to 
>>Forrest (but not necessarily the other way around).
> 
> 
> I don't see how this can work.
> 
> See Cliff's draft Third-party Licencing Policy.
> http://people.apache.org/~cliffs/3party.html#options
> Down the page there is sub-section "PMC Actions":
> "
> * YOU MUST NOT modify, assemble, or release a prohibited work as
> an action of an ASF PMC.
> * YOU MAY independently develop, assemble, or release software under
> an excluded license as an individual who happens to be an ASF
> committer/PMC member, but only when such action is not identified
> as being associated with or sponsored by the ASF.
> "

> So if we have the mailing lists and docs here,
> make decisions about those plugins here, then
> we would be associating with it.

Docs are not a problem:

"YOU MAY reference a prohibited work (e.g. with text or hyperlinks) from 
an apache.org web page"

The mailing list issue is more of a problem. Having discussion here will 
give the impression that the ASF is supporting the plugin which we 
cannot do.

>>What does the PMC think?
> 
> 
> I would prefer that we don't do this if there is a way
> around it. 

So would I.

I'm open to suggestions but I am not in a position to do this work in 
such a way that will force my users to work with a broken auto-install 
feature.

Would this work?...

The code is here in our SVN and is managed by Forrest as normal. But the 
distribution point for the project is the SF project. The relevant 
points in the legal faw are:

"YOU MAY include code within the Apache product necessary to achieve 
compatibility with a prohibited work through the use of API calls, 
"bridge code", or protocols, provided that the compatibility code was 
contributed under a CLA. However, any such code used for compatibility 
with a third-party work that is licensed under terms that violate 
criterion #2 ("must not place restrictions on the distribution of 
independent works that simply use or contain the covered work."), such 
as the GPL, requires review and explicit approval of both the PMC chair 
and the Legal Affairs officer. This review will ensure that the Apache 
product takes only the necessary steps to achieve compatibility."

This one is no problem in my opinion, the code in questions is LGPL.

"YOU MUST NOT modify, assemble, or release a prohibited work as an 
action of an ASF PMC."

This means that we cannot build and release the *complete* plugin as a 
PMC. Since I am the one who needs this code to work as an auto-install, 
I will undertake to build and release the plugin as an individual over 
on the SF project. Discussion and votes for release will take place on 
the SF projects mail lists. The Forrest PMC will only be resonsible for 
the bridge code (as described above). This would, in my opinion, come under:

"YOU MAY independently develop, assemble, or release software under an 
excluded license as an individual who happens to be an ASF committer/PMC 
member, but only when such action is not identified as being associated 
with or sponsored by the ASF."

In summary we would develop the bridge code here in Forrest, but *I*, as 
an individual, will assemble and release the plugin in the SF project.

The end result of this would be that any developer can build the latest 
plugin from our SVN sources by manually downloading the LGPL 
dependencies. Later we may automate this retrieval of LGPL binaries.

Users will be able to obtain the plugin by using a "a documented, 
non-default, build option to allow users to explicitly insert a 
prohibited work into a single binary package with the Apache product code."

In my view the only thing we need to do for this is add a "licence" 
element to the plugins.xml file and make this very clear on the plugin 
index.

Ross


Ross

Mime
View raw message