Enforcing the GPL - Kernel hackers get involved
h-online.com
h-online.com
So, Linux kernel is basically under LGPL: it's OK to take it, bundle with some proprietary closed-source userspace code, and include it in binary form to some TV set top box, router, or other hardware appliance. As long as source code for the kernel is provided for free download on hardware vendor's website, GPL is not violated, Linus' exception for GPL works and viral nature of GPL does not extend to userspace subsystem, which can be kept close-sourced.
Do I understand it right? Any opposing opinions?
The Linux kernel is not LGPL, because you may not statically link it to proprietary code and then distribute the result.
There is no requirement for a work that merely links to a GPL'd work to itself be open-source, except under very particular conditions where the linking is obviously being used to try to evade the law.
And GPL adds more to this basic "do not close the source" LGPL level.
LGPL exists to have lesser GPL without viral nature. They both forbid static linking with proprietary code and distributing solely resulting binary file.
The LGPL permits static linking of an LGPL'd work into a proprietary binary, as long as there is some way for the user to modify the LGPL'd portion and re-link. As I said, that is why the LGPL exists. The objective of the LGPL is to simplify the process of distributing proprietary applications, as a statically-linked binary is much easier to distribute than a binary which dynamically links against system libraries.
Both the GPL and LGPL permit proprietary applications to dynamically link against system libraries. The GPL takes great pains to state this, to try to reduce misunderstandings propagated by people like you.
Neither the GPL nor LGPL are viral.
Consider that if copyright could transit over a dynamic linking boundary, that every single application would need to include copyright clauses for every BSD/MIT library it dynamically linked with.
Why do you think OpenOffice is under LGPL? Who is going to statically or dynamically link with that "library"? They are using LGPL because they don't want copyleft to infest every code bundled with their code in the 'collective', or 'derived' work.
That is the difference between strong copyleft and weak copyleft, and you should have educated yourself before using downvote button.
Obviously, you are one of the many people being paid to spread propaganda about the GPL/LGPL. Please find another line of work, one which is less harmful to the programming community and the world at large.
I fail to see how can I do any harm to the programming community (and the world at large) just by explaining GPL/LGPL difference, or strong/weak copyleft difference.
Discussion is beneficial for all parties: now you know that static linking of LGPL library into solely distributed binary EXE file is impossible, now I agree that GPL can't expand itself from DLL to EXE if DLL is packaged and installed separately and makes sense on its own (used by other applications), now you know that GPL will expand itself from DLL to EXE if they are in single downloadable/installable package, and now I know that we should bundle our proprietary code in the next product with FreeBSD kernel, not Linux. How open, public discussion can do any harm to anyone?
Yes I'm not FSF/GNU/RMS/copyleft zealot, so what?
And yes: you're correct that the official interpretation of the kernel license does not treat userspace programs as derived works. So merely running something in userspace does not require releasing that the code be licensed under GPL-compatible terms.
Note that there's a lot more GPL software than the kernel that you will need to package, however. The kernel is merely the biggest single piece.
the news is, that now the software freedom conservancy has some kernel and samba copyright holders, so it can enforce the gpl even when busybox is replaced for infringing devices.