On Tue, Mar 30, 2004 at 01:49:16AM -0800, Justin Erenkrantz wrote:
> This would add a new build and run-time dependency that I think we
> have to be very careful about handling. I really wish this could be
> made optional rather than being a mandatory requirement. As an aside,
> we would have to disable static linking if we import gettext as LGPL
> forbids any static binaries created with LGPL functionality. (Hmm,
> we'd have to do the same for neon - are we?)
This isn't accurate. The LGPL does not disallow static linking. It
restricts you to complying with a certain set of terms if you statically
link. There are some cases where statically linked binaries are not
going to be allowed. So let's look at the key sections that apply here,
Sections 5 & 6:
>>>>
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.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
<<<<<
subversion's license doesn't conflict because of static linking. It is
possible to statically link and still comply with both licenses with
regards to the linking stuff. subversion's license doesn't require
including the source, but there's nothing stopping you from doing so.
The exception here is Windows or potentially other commercial platforms.
If you use non-free compilers and libraries in making your statically
linked binary, then you can't comply with the LGPL because you can't
make those tools/libs (or their source code) available.
You can make executables that dynamically load the LGPL library, but
statically link to the non-LGPL libraries. The LGPL has cases for
including portions of the library or not including portions of the
library but Section 5 makes an exception for cases where only in essence
the header files are used. So dynamically loading the LGPL lib would be
possible under Section 5 on these platforms, but full statics would fail
the requirements of Section 6 on these platforms.
On other platforms the copyright statement's need to be modified if we
statically link to mention the LGPL licensed software and their
copyright statement.
Frankly, I don't think any of this is a concern for us except for the
binaries that we distribute. We should not be distributing binaries
that statically link LGPL libs for any platform. But this is a concern
for the packager not this project. I would argue that attempting to
disallow this might open us for liability for packagers which don't
comply with the LGPL.
However, the LGPL does still present the same potential problem that the
GPL does:
>>>>
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
<<<<
The FSF has (controversially I'll add) held that clauses like our 3, 4
and 5 are adding additional restrictions. If you accept this
interpretation then we conflict with the LGPL just as much as we
conflict with the GPL.
CollabNet's stated policy on this is (someone correct me if I misstate
this):
1) They don't believe they conflict with the GPL because they don't
accept the FSF's interpretation.
2) They will not object if someone links subversion against GPL licensed
code (and under CollabNet's interpretation of the GPL) is thereby
relicensed under the GPL (and by extension has the extra clauses
removed). I'm guessing they're okay with the LGPL as well since they
include code that links against libneon which is LGPL.
Regarding the situation with libintl. I don't think it is really
different than the issues with libneon. Binary packagers should be
reading the licenses of the tools we're using and considering their
licenses carefully before they build statics. I don't think we should
try and limit ourselves to software that might create problems for some
particular packaging cases.
If we do anything we might want to include a comment in our INSTALL
document point out the potential issue with static linking, maybe making
an option in our configure/Windows build system to build things in a way
that does comply with the license.
So in summary:
Static linking is permitted, but care must be taken to comply with the
license. On platforms such as Windows, it will not be possible to
create a fully statically linked executable, you must dynamically link
the LGPL libraries.
CollabNet doesn't agree with the FSF about the additional restrictions
problem and so is ignoring the issue.
I hope this clears up the licensing issues.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 07:18:48 2004