plugins with some excluded licenses

[Ross Gardler <rg...@apache.org>]

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

Re: plugins with some excluded licenses

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> Ross Gardler wrote:

...

> 
> Can i please get clarification about the outcome.
> The proposed solution evolved to the following:
> We have bridge code as AL2 in our SVN, all discussion
> and development can happen our asf mailing list.
> The optional "binary" is not the concern of the
> Forrest project.
> 
> Ross is that how you see it?

Yes.

Optional binaries can be distributed from the Sourceforge project.

That project may chose to distribute binaries of custom Forrest builds 
as well. That is builds in which the LGPL stuff is not optional. This 
means there may be some build files in the SF SVN repo. However, there 
will be *no* Forrest code there.

Anyone voted in as a committer to Forrest can get committership to the 
SF project just by asking.

The SF project will not accept any plugin code (other than binaries) 
unless the Forrest project has voted *against* its inclusion in Forrest SVN.

Ross

Re: plugins with some excluded licenses

[David Crossley <cr...@apache.org>]

Ross Gardler wrote:
> Cliff Schmidt wrote:
> >Cliff Schmidt wrote:
> >
> >>I give you the long answer for two reasons: a) to give you an  
> >>understanding for the ideas behind all those rules, and b)  to make  
> >>sure I'm not misleading anyone into thinking that distributing an  
> >>LGPL library within an Apache product would cause us to all go to  FSF 
> >>jail (or worse, JBoss jail!).  The reason we don't distribute  LGPL 
> >>jars in our products is because our users have come to  associate the 
> >>Apache brand with (among other things) commercially- friendly 
> >>software, and the LGPL places restrictions on how they can  license 
> >>software that links to the library, which most would  consider not as 
> >>friendly as they would like.
> >
> >Actually, there was another reason I gave the long answer: I'm always  
> >looking for feedback from people on this policy.  When it's simply a  
> >matter of the legality of a particular action, I can usually make  that 
> >decision easily enough on my own (and with the help of our  generous pro 
> >bono lawyers); but when it's an issue of figuring out  the right policy 
> >for Apache, I really want as much feedback as possible.
> >
> >I hate to think that this policy would risk dividing a development  
> >community unless absolutely necessary.  So, if any of you have  thoughts 
> >on the utility/importance of drawing lines to ensure that  the Apache 
> >brand has some well-defined licensing definition (such as  I've tried to 
> >do with this policy to create something that is  "commercially 
> >friendly"), please let me know.  I'm don't want to  hijack the 
> >short-term issue, but I want everyone to know the big  picture and that 
> >I'm always open to hearing potentially better ideas.
> 
> Since it is I who has the "problem" with the LGPL libraries I ought to 
> state my opinion.

Yes but we extended it to find a general solution
for other potential cases.

> I fully understand the intent of this policy.
> 
> I fully support the intent of this policy.
> 
> I do not believe that our proposed solution will divide the community 
> since we will only be providing the binary download from a third party 
> distribution site.
> 
> Cliff, thanks for all your efforts in formulating a clear policy for us 
> to follow. It makes life much easier.

Can i please get clarification about the outcome.
The proposed solution evolved to the following:
We have bridge code as AL2 in our SVN, all discussion
and development can happen our asf mailing list.
The optional "binary" is not the concern of the
Forrest project.

Ross is that how you see it?

-David

Re: plugins with some excluded licenses

[Ross Gardler <rg...@apache.org>]

Cliff Schmidt wrote:
> On Jul 10, 2006, at 4:34 PM, Cliff Schmidt wrote:
> 
>> I give you the long answer for two reasons: a) to give you an  
>> understanding for the ideas behind all those rules, and b)  to make  
>> sure I'm not misleading anyone into thinking that distributing an  
>> LGPL library within an Apache product would cause us to all go to  FSF 
>> jail (or worse, JBoss jail!).  The reason we don't distribute  LGPL 
>> jars in our products is because our users have come to  associate the 
>> Apache brand with (among other things) commercially- friendly 
>> software, and the LGPL places restrictions on how they can  license 
>> software that links to the library, which most would  consider not as 
>> friendly as they would like.
> 
> 
> Actually, there was another reason I gave the long answer: I'm always  
> looking for feedback from people on this policy.  When it's simply a  
> matter of the legality of a particular action, I can usually make  that 
> decision easily enough on my own (and with the help of our  generous pro 
> bono lawyers); but when it's an issue of figuring out  the right policy 
> for Apache, I really want as much feedback as possible.
> 
> I hate to think that this policy would risk dividing a development  
> community unless absolutely necessary.  So, if any of you have  thoughts 
> on the utility/importance of drawing lines to ensure that  the Apache 
> brand has some well-defined licensing definition (such as  I've tried to 
> do with this policy to create something that is  "commercially 
> friendly"), please let me know.  I'm don't want to  hijack the 
> short-term issue, but I want everyone to know the big  picture and that 
> I'm always open to hearing potentially better ideas.

Since it is I who has the "problem" with the LGPL libraries I ought to 
state my opinion.

I fully understand the intent of this policy.

I fully support the intent of this policy.

I do not believe that our proposed solution will divide the community 
since we will only be providing the binary download from a third party 
distribution site.

Cliff, thanks for all your efforts in formulating a clear policy for us 
to follow. It makes life much easier.

Ross

Re: plugins with some excluded licenses

[Cliff Schmidt <cl...@apache.org>]

On Jul 10, 2006, at 4:34 PM, Cliff Schmidt wrote:
> I give you the long answer for two reasons: a) to give you an  
> understanding for the ideas behind all those rules, and b)  to make  
> sure I'm not misleading anyone into thinking that distributing an  
> LGPL library within an Apache product would cause us to all go to  
> FSF jail (or worse, JBoss jail!).  The reason we don't distribute  
> LGPL jars in our products is because our users have come to  
> associate the Apache brand with (among other things) commercially- 
> friendly software, and the LGPL places restrictions on how they can  
> license software that links to the library, which most would  
> consider not as friendly as they would like.

Actually, there was another reason I gave the long answer: I'm always  
looking for feedback from people on this policy.  When it's simply a  
matter of the legality of a particular action, I can usually make  
that decision easily enough on my own (and with the help of our  
generous pro bono lawyers); but when it's an issue of figuring out  
the right policy for Apache, I really want as much feedback as possible.

I hate to think that this policy would risk dividing a development  
community unless absolutely necessary.  So, if any of you have  
thoughts on the utility/importance of drawing lines to ensure that  
the Apache brand has some well-defined licensing definition (such as  
I've tried to do with this policy to create something that is  
"commercially friendly"), please let me know.  I'm don't want to  
hijack the short-term issue, but I want everyone to know the big  
picture and that I'm always open to hearing potentially better ideas.

Cliff
  

Re: plugins with some excluded licenses

[Cliff Schmidt <cl...@apache.org>]

David,

Sorry for the slow reply to this one.  I've just now crawled out of  
the build-up of legal emails that I ignored during ApacheCon Europe.

Short answer: I didn't see any problem with the approach suggested in  
this thread.

Long answer:
The big picture here is actually much less about legal requirements/ 
risk and more about consistency of the licensing aspect of the Apache  
brand.  That big, long, third-party licensing policy doc is primarily  
trying to achieve one thing: a consistent theme to the licenses of  
stuff that goes in an Apache product.  While we do need to be careful  
about how we link to GPL works, linking to an LGPL Java library poses  
only a minimal risk that we would have to license our project code  
under something other than the Apache License.  Most of those "You  
MUST NOT" and "You MAY"s were my attempt at placing bounds around  
what a user has to deal with when they grab a product "off the shelf"  
that has the "Apache" brand on it (don't get me started on my grocery  
store metaphor...).

I give you the long answer for two reasons: a) to give you an  
understanding for the ideas behind all those rules, and b)  to make  
sure I'm not misleading anyone into thinking that distributing an  
LGPL library within an Apache product would cause us to all go to FSF  
jail (or worse, JBoss jail!).  The reason we don't distribute LGPL  
jars in our products is because our users have come to associate the  
Apache brand with (among other things) commercially-friendly  
software, and the LGPL places restrictions on how they can license  
software that links to the library, which most would consider not as  
friendly as they would like.

Cliff

On Jul 3, 2006, at 10:55 PM, David Crossley wrote:

> Hi Cliff, we are having a discussion on the Forrest dev
> mailing list about how to cope with plugins where our
> developers want to use third-party products from the
> http://people.apache.org/~cliffs/3party.html#category-x
>
> Re: plugins with some excluded licenses
> http://marc.theaimsgroup.com/?t=115192023200002
> Message-ID: 44A8E7F1.1020508 () apache ! org
>
> Some background ...
>
> Forrest has its main core and then a "plugins" system
> to enable various extra optional functionality. We have
> a growing list of plugins that we manage in our SVN.
> When we make a release, we add the sources for all the
> plugins.
>
> The user can also use the plugin system to download
> plugins that are not held in the Forrest SVN, e.g. from
> their own development site.
>
> So far we have managed to avoid using Category X third-party
> products (e.g. supporting jars such as database connectivity)
> in any of our plugins. However it was bound to happen.
> Now we have a definite use case.
>
> I hope that you can help. I am stumped about the best way forward.
>
> -David

Re: plugins with some excluded licenses

[David Crossley <cr...@apache.org>]

Hi Cliff, we are having a discussion on the Forrest dev
mailing list about how to cope with plugins where our
developers want to use third-party products from the
http://people.apache.org/~cliffs/3party.html#category-x

Re: plugins with some excluded licenses
http://marc.theaimsgroup.com/?t=115192023200002 
Message-ID: 44A8E7F1.1020508 () apache ! org

Some background ...

Forrest has its main core and then a "plugins" system
to enable various extra optional functionality. We have
a growing list of plugins that we manage in our SVN.
When we make a release, we add the sources for all the
plugins.

The user can also use the plugin system to download
plugins that are not held in the Forrest SVN, e.g. from
their own development site.

So far we have managed to avoid using Category X third-party
products (e.g. supporting jars such as database connectivity)
in any of our plugins. However it was bound to happen.
Now we have a definite use case.

I hope that you can help. I am stumped about the best way forward.

-David

Re: plugins with some excluded licenses

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> There is a very relevant post on cocoon-dev today.

Yeah, I saw that. Looks like our interpretation of the FAQ was correct. 
So what to do?

Incidentally, my OSCommerce plugin will not be created at this time. 
We've decided to take another route, which does not involve Forrest. I 
know Brian is progressing with a version that uses the Database plugin 
in whiteboard, maybe he will be able to contribute that when he has got 
past his deadline.

However, I still want to resolve this issue. I have two plugins (s5 an 
MSOffice) sitting on my hard drive that I would like to get out there. 
Users have requested these plugins and it seems a shame to have them 
wasting away on my hard drive.


Ross

> 
> Torsten and Sylvain spoke to Cliff at ApacheCon
> about a similar scenario for Cocoon.
> 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=115201663025186
> http://thread.gmane.org/gmane.text.xml.cocoon.devel/65071/focus=65163
> Message-ID: 44AA60CD.9000706 () apache ! org
> 
> -David
> 
> 

Re: plugins with some excluded licenses

[David Crossley <cr...@apache.org>]

There is a very relevant post on cocoon-dev today.

Torsten and Sylvain spoke to Cliff at ApacheCon
about a similar scenario for Cocoon.

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=115201663025186
http://thread.gmane.org/gmane.text.xml.cocoon.devel/65071/focus=65163
Message-ID: 44AA60CD.9000706 () apache ! org

-David

Re: plugins with some excluded licenses

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> 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.

I understand that, and I have the same concerns, that is why I have 
raised it here before actually doing anything. However, as well as being 
an Apache Forrest PMC member I am an independent developer. I have to 
satisfy my customers needs as well as those of the ASF. Since I cannot 
do all of the work I need to do under the ASL I need to find a way 
around it with minimal impact on the Forrest community.

The alternative is to not release the work as Open Source. This is the 
third plugin I have built that falls into this category, all three have 
been requested by our users. I think finding a way of allowing these 
plugins to exist as Open Source is going to strengthen the community, 
not split it.

So lets keep working at it...


> I will ask for Cliff's advice.

Thanks for doing that. I'll be following the thread.

Ross

Re: plugins with some excluded licenses

[David Crossley <cr...@apache.org>]

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

It is my understanding that LGPL and GPL are in the
same category. Reading that above snippet in context
http://people.apache.org/~cliffs/3party.html#options
(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.

-David