On Sat, Nov 08, 2003 at 08:57:36PM -0500, John Belmonte scribbled: > Marek Habersack wrote: > >In fact, I'm considering adding a > >list of files in the library and their associated licenses to the > >README.Debian in the package once it hits Sid (I've uploaded it already). I > >grew aware of problems with licensing while working on Caudium. We, as the > >Caudium Group, don't own the copyrights to all the code, but we do own a > >huge part of it. I usually license my code under LGPL/MPL (considering IPL > >now) but Caudium as a whole is still GPL. In such a crazy situation, it is > >crucial that users/developers have detailed information about what parts of > >a package are licensed under which licenses and, first of all, that there > >exist various licenses to begin with. It really saves one a lot of trouble > >later on. > > To be complete, consider that you'd have to list interdependencies too. > Take the example once more of an application that can't use GPL'd > software. You said it might still use libnettle by linking statically > and only using parts not under the GPL. But what if one of those parts > uses another that is GPL'd? The application author may not even realize That's not direct linking then. If it was to force your application to be GPL, then spawning /bin/bash from your non-GPL application would also mean you'd have to GPL the app (since bash uses libreadline which is GPL). Or, following that example - your shell scripts would have to be GPL. Furthermore, calling down to the kernel code would mean both libc and your app would have to be GPL (that is, if the linux kernel copyright didn't contain the exemption notice for that case). You can always override the GPL by using an LGPL "proxy code" which your application links to. It might be as dumb as a set of function wrappers. And in such instance the knowledge which particular parts of code are under GPL is also valuable - since you can limit the wrappers only to those parts of code while calling the rest directly. > it. Even if he was careful and looked at which object files where > linked into his app, it still doesn't account for the possibility of a > non-GPL'd part using macros, inline code, etc. from a GPL'd part. Inlined code doesn't count IIRC. In any case, if you are concerned with such issues then the proxy idea above is your way to go. regards, marek
Attachment:
signature.asc
Description: Digital signature