[Python-3000] C API for ints and strings (original) (raw)

Larry Hastings larry at hastings.org
Tue Sep 11 08:09:29 CEST 2007

Nicholas Bastin wrote:

As for the user-replaceable shared library part, that's up for considerable debate. It's unlikely that static linkage legally creates a derivative work (that would be pretty unreasonable in computer science terms), but it's never been tested in court, so static linking would probably be out for distributors without a legal department.

I guess anything is debatable, but the LGPL explicitly defines programs statically-linked with LGPL code as being "derivative works":

*5.* A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled
or linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because
it contains portions of the Library), rather than a "work that uses
the library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

I feel it's intellectually dishonest to ignore the LGPL's restrictions on the basis that its definitions haven't been tested in court. You seem to suggest that, were Python to incorporate LGPL code, organizations which redistribute a statically-linked Python should ignore the LGPL-induced restrictions--is that really what you mean?

I for one am relatively happy with the existing Python license. I would be quite irritated if Python were to incur more restrictive licenses, whether or not they had been tested in court.

/larry/

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20070910/775bfdb6/attachment.htm

More information about the Python-3000 mailing list