[Python-3000] C API for ints and strings

[Larry Hastings]

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