jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smuts, Aaron" <Aaron.Sm...@travelocity.com>
Subject RE: Official jcs release?
Date Thu, 22 Sep 2005 14:21:59 GMT
If Jisp is GPL, then I'll cut it out in the next day or so.  It was only
in an experimental directory as an optional plugin and never seemed to
work very well anyway.

The jgroups is now in a directory called jdk1.4 extensions along with a
Berkeley DB disk cache plugin.  We can keep both out of the distribution
for now.  

The core of JCS should have almost no dependencies outside of Jakarta
except for util concurrent.  

Thanks,

Aaron

> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Thursday, September 22, 2005 8:45 AM
> To: JCS Developers List; hps@intermeta.de
> Cc: turbine-jcs-dev@jakarta.apache.org
> Subject: Re: Official jcs release?
> 
> On 9/22/05, Henning P. Schmiedehausen <hps@intermeta.de> wrote:
> >
> > Actually, we should do a bit more than just listen. We don't want a
> > project to fall into the licensing trap.
> 
> +1
> 
> > Aaron: The problem is, that there are severe licensing issues
> > surrounding GPL code:
> >
> > - We must not use any GPL licensed code inside an ASF project. GPL
> >   licensed means "viral" and would spread the GPL onto our code. So
> >   if you rely on code that is just GPL licensed (not dual-licensed),
> >   you _must_ pull that code out. No jar bundling, no class
extension,
> >   no imports, nothing. GPL is evil and we avoid it.
> 
> All good, cept the evil bit. GPL is viral and we avoid it. You can use
> it, but very indirectly (I'll mention below how).
> 
> > - Lesser GPL (LGPL) is sort of blurred. As this license is not
viral,
> >   we might use it in ASF code (import statements, extend classes
etc.)
> >   but due to Apache policy, we cannot _ship_ any LGPL licensed code
> >   from Apache servers. This is one reason why Maven put its
repository
> >   on ibiblio and it is also necessary that we control binary
> distributions
> >   (like those built by maven) to not contain any LGPL licensed jars.
> 
> Currently the public ASF statement is that LGPL is to be treated as
> viral for Java, in fact as exactly the same as GPL. You can use it if
> it's through a plugin interface, but the plugin part cannot be
> distributed from the ASF. This is based on the opinions of our lawyers
> and not a bsd vs gpl thing. It's different for C, but for Java the
> licence is just poorly worded.
> 
> Let's say JCS used a regexp library. You could allow for gnu-regexp to
> be used, but it would have to be via a generic regexp interface, the
> classes for gnu-regexp in particular would have to be hosted outside
> of the ASF and you would have to either have an alternative (oro for
> example), or it would be an optional feature not necessary for normal
> operation of JCS.
> 
> Better example perhaps is a JDBC driver. It's fine for us to encourage
> usage of mysql's jdbc driver, provided we only compile against the
> JDBC API. In this case our plugin API is a Java standard, and the *GPL
> project in question have written the other side already.
> 
> Privately, a lot of work has been put into trying to work with the FSF
> and lawyers into allowing the LGPL to be more usable. We might be able
> to slightly relax the situation at some point soonish (order of
> months).
> 
> > You might ask now: Why the fuss? Because the ASF wants to make
_sure_
> > that any of our projects can be used by anyone. Unconditionally.
> > Everyone can download an Apache project, integrate it into a bigger
> > system and needs not to worry about viral licenses. That is the
promise
> > of the ASF license and unfortunately it is the job of the Apache
people
> > to keep up to this promise.
> 
> Yup. That's the gist of it.
> 
> So Aaron, is there a *GPL dependency to be worried about?
> 
> If so we have to cut it out etc asap; but start by just describing the
> situation.
> 
> Hen
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org


Mime
View raw message