Ralph Goers wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still don't get why mocks are
a problem - this license stuff sucks
so badly *grrrr*
In order to create a mock you have to copy a specific class
interface that someone designed.
I don't think that this solved the problem. If you download e.g. some
LGPL library you will use it somewhere in your code, otherwise it is
useless. The problem is the *use* IIUC ...
no, the problem is the 'redistribution' of derivative work.
To be on the safe side, we will have to wait for real blocks as they
can cut all direct dependencies (--> one block only has a requirement
on a block interface and not on a block implementation.)
correct: if you have a 'database' block interface and a block that
contains GPL stuff and implementat those interfaces (say the mysql
jbdc driver, for example), you can make the entire block GPL and
distribute that from, say, sourceforge or ibiblio and you are just
fine, because you hook to the JDBC API which are not GPL and you don't
distribute anything and the only 'contract' is the class name, which
is a configuration therefore not a viral dependency.
This is the *only* way (without changing licenses!) to allow us to
distribute safely GPL and LGPL code.
NOTE: the requirement is that the contract API should *not* be GPL,
otherwise that doesn't work, as our code will be a derivative work,
therefore needs to be GPLed as well.
A (sneaky? immoral?) way to route around the problem is to use runtime
classloading: if your compiler can compile the block without the GPL
code being visible to the compiler, you are fine.
The nice thing about blocks (or other component models, is that the
link between roles and classnames is a configuration file), so the
compiler doesn't need to depend on them.
The problem remains when your code implements an interface which is
licensed under the LGPL, as it's unclear whether or not an interface
implementation is considered a derivative work of the library, or a
'use' of the library itself.
the ASF board is working hard with the FSF to resolve these issues,
but don't hold your breath. For now, it's easier to route around the
problem as I mentioned above.
Please see (if you haven't already)
http://www.gnu.org/licenses/lgpl-java.html.
Yes, I've been talking to David for months now :-)
--
Stefano.
