Nikolaus Rath <nikol...@rath.org> writes:
> Russ says that it's only necessary "there are licensing reasons", but
> I'm not sure what that means. It seems that pretty much every open
> source license requires you to make the source code available (including
> Cython), so I'm not sure why e.g. in the above case it's not necessary.
libgcc does not require this.
You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes. You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules.
The inline code in glibc headers is an interesting question, and I wonder
if the FSF should have some sort of position on that (or start using the
Runtime Exception for that code as well). Right now, all of eglibc (in
unstable right now) is covered by the LGPL 2.1, which has the following:
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.
The above is the term that we've generally been using to avoid having to
include the source of the exact version of eglibc that the binary package
was linked against. But the inline code in the glibc headers is, of
course, not loaded via shared library linkage, but instead is embedded
directly in the binary.
I think the situation for statically linked binaries is clearer: we really
do need to provide the source for the corresponding eglibc version, and
hence need Build-Using for static binaries.
> Also, I was expecting that Built-Using would also be important to figure
> out which packages need to be recompiled when there's e.g. a security
> update of the binary package from which sources were included. Am I
> mistaken about that?
Yes, we should also capture that use case.
The main thing we want to avoid is having Build-Using for every single
package in the archive because of libgcc, because that seems pointless and
annoying. Similarly, I doubt we need that for the inline code in eglibc
headers, given that no one else does that and hasn't for years and years,
so regardless of the specific license text, it's pretty clear this isn't a
general upstream expectation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lia2ft7z....@windlord.stanford.edu
