<br><br><div class="gmail_quote">On Dec 3, 2007 12:09 PM, Chuck Swiger <<a href="mailto:chuck@codefab.com">chuck@codefab.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>...however, this fails to consider the actual text of GPL(v2) clause<br>#2, part of which reads:<br><br>"These requirements apply to the modified work as a whole.  If<br>identifiable sections of that work are not derived from the Program,

<br>and can be reasonably considered independent and separate works in<br>themselves, then this License, and its terms, do not apply to those<br>sections when you distribute them as separate works."<br><br>If you distribute a binary which runs just fine by itself as a

separate work, but which might optionally use a GPL'ed work like GNU readline via dynamic linking, then GPL clause 2 says that the terms of the GPL do not apply to that binary.</blockquote><div> To be fair, I disagree with the FSF's characterizations of when a derivative work exists.  I just figured that it is worth bringing up their pov.  That was the reasoning they used to pressure Apple to release their Obj-C extensions to the GCC (since it never went to court though, we don't know if any lines were actually crossed by Apple).

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br></div>We've discussed this particular issue before in some detail in a

<br>thread here:<br><br>   <a href="http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12232:200701:eekjfkiiplhjdkoabfid" target="_blank">http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12232:200701:eekjfkiiplhjdkoabfid</a><br><br>

Quoting myself:<br><br>"I've even seen people claim that the only reason why proprietary<br>software running on Linux can avoid being "forcibly relicensed under<br>the GPL" is because GNU libc is under the LGPL.  They seem to forget

<br>that the original standard C library was written by Kernighan and<br>Richie back around 1971, some twenty years before Roland McGrath<br>started writing GNU libc circa 1992.<br><br>Just because a program calls printf() does not mean that it becomes a

<br>derivative work of GNU libc when dynamically linked on a Linux<br>platform, any more than that same exact same program source code<br>becomes a derivative work of the original C library on a BSD platform,<br>of Microsoft's Visual-C++ DLLs when dynamically linked on Windows, and

so forth for every platform that supports an ANSI-C library."</blockquote><div> For that matter, when you use the MySQL ODBC drivers to create a spreadsheet in Excel pulling data from  a spreadsheet, Excel doesn't suddenly become a derivative work of MySQL's client libraries.

<br><br>My own thinking is that linking itself is never sufficient to imply derivation even if there is a requirement that it use a given version of a given library.  This would seem to me to be no different than using out-of-process interfaces (for example, XML-based web service API's).  Consider the following:

An author writes a scientific article regarding element formation in stars.  They include references to other papers, not only as a whole, but to specific paragraphs with a clear intent that the user goes, obtains, and reads those other paragraphs as well.  Is that article a derivative of the referenced sources?  Not by any reading of the statute I can come up with (but IANAL).  However, this seems roughly analogous to out of process API usage.

A few years later, a publisher gets the anthology rights to each of the articles in question and puts them all in a book together.  Now, you just have to jump forward and back to find your information and not switch publications.  Is the new paper now a derivative of the older ones?  I still don't think so.  But this seems to me to be pretty clearly equivalent to function calls of libraries in process.  Because linkers often remove unused elements of statically linked libraries, but only do so along purely functional lines, that doesn't seem to suggest that it is any different in this case regarding derivative works (because the transformation isn't creative).

Secondly in terms of questions of expressive nonliteral content, it seems to me that XML DTD's for web service API's contain a *lot* more expressive content than linking maps.  However, this is not the FSF view.

<br><br>Best Wishes,<br>Chris Travers<br></div></div><br>