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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
