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/
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
