But that is all. It works exactly like copyright in that regard. To be subject to it you need to have received a copy of program.
So no, running the program in the cloud is not distribution.
(Of course I work for Red Hat and the cult thinks all code should be free :-)
(I work for Red Hat also :-)
I was originally just being silly but figured I would add something of substance here. I think the GPL goes a little too far but I like the spirit of it. As a user if I pay for an application, I should get a copy of the code for personal use as well. I don't think that gives me the right to distribute it because it's still somebody's property, but applications should be distributed to customers with their source IMHO.
No. That's formally wrong, and it doesn't imply what you think it implies.
Using copyleft code means that if you distribute the resulting binary, you also have to distribute the corresponding source code. If you can't do that, you can't distribute the binary.
Is that a problem? No. You distribute object files and libraries, accompany the copylefted libraries with their source code, and let the end user link them together statically. Problem solved. Arguably, that's how all software installation on Unix should work; it solves so many other problems, too.
IIRC you can write proprietary kernel modules, which are loaded at runtime.
> Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.
Because the kernel is licensed under GPLv2. If you statically link to the kernel, then all interpretations of the GPL are that your work is a derivation and must be GPL'd (at least assuming it is "distributed").
>NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".
(even without actual syscall, you can consider unikernels as normal use of kernel)
> Unikernels are typically statically linked.
The note you're quoting is about regular software performing regular syscalls which is runtime dynamic linking to the kernel (so much so that multiple OS (e.g. SmartOS, Windows) implemented linux persona which allow running unmodified Linux software against a non-linux kernel).
It does not apply in a scenario where you would statically link to the kernel.
That's not the interpretation everyone else uses.
It's a well-defined axiom of the original comment, and we're discussing logical consequences of that axiom. If you want to disagree with the original axiom then go and do so to the original comment.
Indeed but then you’re kinda missing the point of unikernels.
Unikernels are viable even if they don't allow you to do that, for many reasons - performance, workload isolation, ease of installation.
Linux is licensed under GPL-2.0 WITH Linux-syscall-note.
>NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".
More generally can link LGPL code statically without making resulting binary subject to copyleft or releasing the source code. Increasing number of programmers don't know what object file is anymore (they didn't learn to program in C/C++) and this causes endless confusion.
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
> For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
> (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
GP provided a clear scenario in which their warning is categorically true.
> Linux is licensed under GPL-2.0 WITH Linux-syscall-note.
The note clarifies that syscalls are interpreted as a form of dynamic linking, which would be quite obvious in retrospect given you can run unmodified linux software on non-linux kernels (https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux).
> More generally can link LGPL
You do realise the LGPL and the GPL are different licenses with different requirements and constraints right? And the linux kernel is not licensed under the LGPL? And that what you quote specifically notes that even under the LGPL, static linking results in a derived work?
No. You can provide object files without source code and it does not become covered work. This is for example how using LGPL in Qt works.
That you don't have the rights to it, and / or that the code was written under a contract or grant which prevents its release.
Sometimes the same thing that prevents you from giving away all the results of your work for free. Can I have a copy of the code you're writing for your employer now? Surely everything you work on is made freely available to the public in its entirety. I hope you weren't just virtue signaling but doing the opposite in exchange for a salary.
Free software is great, but not everyone is in the position where they can release all of their code all the time.
For a unikernel to be viable it can't have copyleft code in it.