On 9/22/05, Henning P. Schmiedehausen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to