>       yes, that's a good workaround. Likely also the route Steve's
> customer should take in this: any modifications to NH, extension
> classes to
> NH, place that in an LGPL-ed assembly and the bigger app isn't
> affected.

Modifications yes. What are extension classes? Neither derived, injected or any 
other classes of your own authorship must be LGPL. Extension methods neither. 
The key is that the modified LGPL code must still compile and work as a module.

> > The web services part is for the AGPL, not the GPL or LGPL, IIRC.
> > There are explicit ways to break the links, anything that is out of
> process
> > (cmd line, pipes, etc).
> 
>       Oh! you're right, I forgot about that one, indeed. AGPL (A stands
> for aggressive? ;)) was the insane one.

A stands for Affero, the original inventor. The name was kept so that - guess 
what - the license condition "Affero GPL 2.0 or higher" would work for the "GNU 
Affero GPL v3" ;-)

But you're confusing two things here. The AGPL does not say that copyleft 
extends over web service boundaries. It only says that if you provide an 
modified AGPL app "as a service" (in the SaaS sense, not necessarily 
SOAP-like), you must provide the source code. The GPL alone would not protect 
the authors from a third party "stealing" and extending their code and selling 
it as a service without giving back the code. That makes perfect sense.

The AGPL is also the preferred license for dual licensing (we do that).

> system links to it... violation? Judges really won't understand that,
> most
> of them can barely handle modern things like keyboards and mice. ;)

They will use an expert witness. Good luck, still...

> > Actually, that scenario is safe. You aren't distributing your
> changes.
> 
>       if you create the website for a client, you do. Many consultants
> don't get this, but creating software for a 3rd party IS distribution.

No, the GPL permits you to have a contractor build private stuff for you -> no 
need to give away the source code.

> > IIRC, the MySQL stance is that if you can use the app with more than
> 1 db,
> > it doesn't apply.
> 
>       Interesting. A new view on the matter. All their lawyers ever
> could
> tell me was 'of course you're in violation in that situation. You can
> overcome that by becoming a VAR'...

Here's a lot of room for interpretation. If you use a standard interface, 
you're not infringing on any concrete implementation's copyright. If you, 
however, distribute that implementation along with yours, it gets complicated. 
That's why some OSS SW requires you to get other OSS modules from the original 
source, like Moonlight and the free codecs...

There are other grey areas. E.g., the FSF's GPL FAQ says this:
"If the program dynamically links plug-ins, but the communication between them 
is limited to invoking the 'main' function of the plug-in with some options and 
waiting for it to return, that is a borderline case."

Reply via email to