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