Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unikernels are typically statically linked. Using copyleft code means the whole resulting binary is subject to copyleft.

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.



Depends what you're using it for. If you're just running it as a server then (non-A) GPL code is fine since you're not distributing the program.


But what about the cloud and auto scaling wouldn't that count as distribution (through for internal use only)?


The GPL is all about giving rights to individual users of your program, not the world in general. It does so by turning copyright upside down, instead of restricting rights it grants rights (it’s like the opposite of those FBI warnings you get on DVD-discs) to those, and only those, who you give a copy of the program to.

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.


It's an interesting point. I wonder if sending a binary to AWS counts as distribution to a third party?

(Of course I work for Red Hat and the cult thinks all code should be free :-)


Yes 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.


Internal use is not distributing.


> Using copyleft code means the whole resulting binary is subject to copyleft.

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.


You can write proprietary kernel drivers. Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.


> You can write proprietary kernel drivers.

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").


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".

(even without actual syscall, you can consider unikernels as normal use of kernel)


The original comment specifically put forward the following scenario:

> 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.


> It does not apply in a scenario where you would statically link to the kernel.

That's not the interpretation everyone else uses.


That's completely irrelevant to this discussion.

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.


So if your "userspace" payload is dynamically linked and loaded at runtime, it's no longer a problem? I don't think that there is a big performance hit for dynamic loading. Probably something like LTO won't work.


> So if your "userspace" payload is dynamically linked and loaded at runtime, it's no longer a problem?

Indeed but then you’re kinda missing the point of unikernels.


I thought that main point of unikernels is to avoid cost of kernelspace-userspace switch.


Well yes, if you want to distribute binaries to people and keep the source private (like in 90's), copyleft unikernels isn't the way to do that.

Unikernels are viable even if they don't allow you to do that, for many reasons - performance, workload isolation, ease of installation.


This is not categorically true.

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.


> This is not categorically true.

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?


> 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.


[flagged]


> What prevent you from releasing code "all the time"?

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.


> What prevent you from releasing code "all the time"?

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.


Very often corporate wants to keep the application code private.


Show me where Microsoft releases all of the source for Windows, or Apple, for Mac OS and iOS.

What's preventing them from releasing code "all the time"?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: