Re: Bug#709382: Built-Using, libgcc, and libc_nonshared
Russ Allbery dixit:
>If we do need to preserve source for the libcc and libc components
>incorporated into binary builds, that's going to mean Built-Using for
>nearly the whole archive, and a lot of complexity on the DAK side. That's
>obviously not very desirable. We would rather decide that we don't need
I’ve tried to draw up an argumentation why this is probably only
necessary if the package contains statically linked files, see
the discussion in the mentioned bugreport, but IANAL, just have
some history in dealing with (mostly OSS) licencing as a hacker,
BSD project lead and employee, so TINLA.
Interestingly enough, even then, differences from the libcs used
can ensue; for dietlibc (GPLv2) it’s pretty clear, but statically
linking against klibc *may* and dynamically linking against it
*will not* invoke the GPL on the result. (The “may” is because
most parts of klibc aren’t GPL, and a quick git grep shows that
the C library itself is probably free of GPL code, but I did no
throughout analysis except for dietlibc and – for mksh – linking
with which libc involves files from which packages.)
>Also, if we're going to decide that we're not going to track source code
>for that sort of inclusion, we need to know what the boundaries of that
>exception or decision are
That’s probably the difficult point and why escalating this looked
like the best option at that moment.
Sorry for raising not just one but two legal issues in one day
(but the Creative Commons thing is handled on the upstream side
right now, I just asked them to keep us in the loop).
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
Reply to: