On 04/02/2013 05:07 PM, Alexander Kobel wrote: > This certainly applies to compiled code, with the GPL'ed library statically > linked, and also (I stand corrected) with dynamic linkage, AFAIU. I still > cannot see how it /could/ possibly apply to source code:
Well, the examples you cite consider a particular case -- which is a program using an API which has multiple different implementations, some under copyleft licenses, some not. In that case, I don't dispute your case that the source code could be distributed standalone without any obligation in respect of its licence. (Of course, anyone wanting to distribute it linked against a particular copyleft library would have to obtain their copy under a compatible license.) But many (most?) cases of using a library involve using a _specific_ library, of which there is only one implementation, and there that library's licensing does come into play. For example, if I write a program that calls functions in the GNU Scientific Library, which is GPL'd, it doesn't matter if I distribute only source code; it's still a derivative work of the GNU Scientific Library under the terms of the GPL, and must therefore be released under a GPL-compatible license. Note, "GPL-compatible license", not necessarily the GPL itself. This actually adds a lot of flexibility in licensing choices. > In that sense, I have the feeling that the source code license cannot > interfere > with the library license, unless parts of the library are copied in the source > code. The source might be useless without the library, but still. E.g., is > it > really the case that the boost project would never be allowed to include > wrappers to GPL'ed libraries? The Boost license is GPL-compatible, so there's no issue for them. Your point is accurate though inasmuch as, if the wrappers weren't used when my program was built, there would be no copyleft obligation on it. > I see your point, but I don't see how what you explained to be the GPL notion > could actually be enforced... I'm not sure I understand you, but anyway, this is getting to the point where it should probably be taken off list if we want to take the discussion further. Let's focus on the case which is of concern -- Lilypond input files. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
