Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Eben Moglen talks about this at length (author of the license). The rough lines are drawn as per how closely the works couple and interdepend on each other.

For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.

If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.

There's a lot of literature out there about static versus dynamic versus microservice abstraction. That's mostly nonsense. Lawyers don't care about that. You can't get around the AGPL (or even the original GPL) that way, by isolating the GPLed code into a corner over a network service.

(disclaimer: not legal advice, get a laywer if you want legal advice).



> For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.

> If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.

So why does the LGPL/Linking Exception exist at all? Software which links against libc doesn't have a mutual dependency; libc is quite happy to run crt0 as long as there's a main symbol somewhere, and yet apparently linking against libc would be enough to constitute a derivative work were it not for the exceptions in the LGPL.


Wrt. GPLv2 what counts as derived work is a mess.

LGPL mainly exists because statically linking a library into a binary (especially with link time optimizations enabled) will somewhat modify the binary code of the linked library in the way it is placed in which some lawyers use to argue that static linking is always a derived work.

So LGPL let's you rest in peace if you need static linking.

(I also have read arguments that even dynamic linking is derived work or that it's totally independent of the linking method but on how the linked code is used. All from lawyers, through not all from US lawyers. Also that was quite a while ago, some curt might have clarified such aspects.)


I think that RMS was fairly clear that he thought that linked code was a derived work as far as the GPL was concerned, and that’s why the LGPL was created.


A license and its drafters can't decide or change what is considered derived work - that's a core concept of copyright law where any nuances could be dependent on the jurisdiction but not on any particular licence.

What LGPL can do is to reassure people by providing specific permission to use the code in some resulting work, no matter if it turns out that it actually is derived work (in which case the licence would grant you the rights you need) or not, in which case you don't need the permission, but it doesn't hurt to have it.


> So why does the LGPL/Linking Exception exist at all?

Because RMS wanted a long time ago to have a bright line in the sand that differentiated between a single derivative work and two works that simply communicate with each other. As the story goes he initially thought that linking was two works communicating with each other, but after consulting with a lawyer, the lawyer presented the following scenario. A person goes in front of a judge and say: this piece of software which can not start without my work, (if statically linked) can't be compiled, can't do anything useful by itself, is not an independent work. What will the judge say?

RMS then agreed with that scenario and decided that this served as a good line for enforcing the GPL, and for projects like the standard library and similar tools an exception was needed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: