On Tue, Aug 10, 2004 at 12:33:14PM +0200, Freek Dijkstra wrote: > You indeed can not do that. But I hope you can do the reverse: take > propriatory code, push it into a loadable module, making your GPL code use > it, and make them into two seperate downloads.
This is the same thing; they link against each other. The GPL doesn't care which portions of code are in a library, a module, or an executable, or which code initiates dynamic linkage. I prefer that; it only leads to confusion, complication and unaccounted-for cases when licenses start talking about specific technologies. In practice, there are some implicit boundaries that are generally agreed on in practice; for example, the kernel tends to act as a magic licensing firewall, such that GPL code isn't "linked" against the kernel or to other, unrelated processes. (I can't offer a legal grounding for this, though.) > As a side-note. What I want is already common practice. In particular this > is what happens in kernel development. The GNU/Linux kernel is GPL-licenced, > while a lot of hardware drivers (the loadable modules) have non-GPL > compatible licences. Because Linus offered an "interpretation" to allow it. (I personally don't believe he has the right to do that, but it's not a battle I have the time or inclination to wage beyond casual discussion.) > But I will probably use LGPL (or the MIT licence you mentioned) for my > projects in the future. The LGPL also has problems: it effectively prohibits use of code on proprietary architectures, such as (AFAIK) SymbianOS and most gaming consoles (eg. Xbox). I think the FSF wouldn't consider that a problem, but it leads to the same reimplementation waste that the GPL does. -- Glenn Maynard