forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: plugins with some excluded licenses
Date Tue, 04 Jul 2006 05:50:17 GMT
Ross Gardler wrote:
> >
> >>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.

As an individual, as a PMC member, and as the PMC chair,
i am concerned that our project is small and might not
cope with a split in its community.

Some project discussion would tend to happen "over there".
Another concern is that new people would become committers
at SF and we would start to have inequality. Another concern
is that the SF project might become the default place for
adding new plugins because it is easier to become a committer
even for plugins that don't have such legal issues. Those are
just fears and whoever manages that SF project can be vigilant.

Anyway lets try to find a solution where we do not need
this separation. More below ...

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

It is my understanding that LGPL and GPL are in the
same category. Reading that above snippet in context
(section "Scenarios Involving Prohibited Works =>
Inclusion within the product"):
I read that as being that the bridge code cannot
impose restrictions on downstream packagers.
Your suggestion should be fine if we produce all
bridge code under the Apache License.

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

However, what about the "modify" part?

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

I will ask for Cliff's advice.


View raw message