Hacker News Reader

Comment by oaiey | Hacker News Reader

> Yes but the BSD license allows a lot more. So this isn't really a problem.

ahm .... is not that the exact problem that a code with a higher amount of restrictions to be transferred into a licensed environment with less restrictions.

View on HN

Yep it is. You don't want GPL code in your BSD/MIT licensed project or suddenly your whole project is under GPL.

Unless you are fine with this and your only concern is that your code is permissively licensed and you don't care that much about further restrictions applying to the whole project.

I believe the *BSD care and want to keep their projects licensed under BSD though. Some GPL code in the BSDs would suddenly prevent use case that are possible today.

But that's only if you want to mix code. It's fine to mix software which is usually what's done. The BSD kernel layer is very small.

Personally I think the whole license thing is a bit overrated anyway. It's more the GNU crowd making this a huge thing, whereas the BSD approach is more like "do whatever you want". Another thing why the BSD camp fits me better.

Personally I don't really care about licenses, it's just some legalese to me (I never bother to read or obey EULAs either for example). And if I share some of my code as FOSS I don't even assign a license. But that's just my personal thing.

> But that's only if you want to mix code.

Yes, although any GPL program in the BSD land cannot grant the same freedoms than BSD programs and will have to be filtered out for some use cases, which weakens the point of the BSD distributions a bit. That's not only the kernel, it's also userspace tools.

> It's more the GNU crowd making this a huge thing, the BSD approach is more like "do whatever you want"

I don't believe this to be the case. Some people in the BSD world are adamant that their code should not be contaminated by the GPL for instance because suddenly, they could not grant the rights to their users to take the code and put it into a proprietary product.

Some people in the BSD world have a strong opinion on how permissive licenses are the right way to do open source / free software.

> the GNU crowd making this a huge thing

I believe this to be a huge thing though. It is a huge thing. You should care what people can and cannot do with your code. Maybe you care that people can do "whatever you want" with your code. I think it's worth stopping and thinking about this stuff and the consequences for a moment, at least once. The world is very little "don't care, whatever", things have consequences and maybe you care about some of them. Surely you deeply care about some things? (of course there's no bad answer, you can answer no)

I myself think the GPL is the better option in most cases, because I care that the end users' freedom is guaranteed. I pretty much don't want developers to do "whatever they want" with my work, I want them to respect their own users' freedom. This is highly political/philosophical of course.

(there are exceptions, for example for codecs you might want the code to be as permissive as possible so the free codec itself is spread and is not replaced with a proprietary one for instance)

> The world is very little "don't care, whatever", things have consequences and maybe you care about some of them. Surely you deeply care about some things? (of course there's no bad answer, you can answer no)

Yes I care very much about people making their own decisions in their own lives (e.g. LGBT, abortion etc) and with ever more restrictive laws (even here in Europe) I kinda just have given up on the law in general. I just shrug at it while the extreme-right tries to curtail our rights (in my country a quarter of people voted extreme-right in our last election). I just don't think legalese is the way to protect this. It's not working anyway.

Also I'm just totally not a 'team player' so I don't care about loyalty to a party, group or country.

> I myself think the GPL is the better option in most cases, because I care that the end users' freedom is guaranteed. I pretty much don't want developers to do "whatever they want" with my work, I want them to respect their own users' freedom. This is highly political/philosophical of course.

I don't think the GPL is very good at this. The BSD license is seen as more friendly to business but in practice it gives users more freedom. Especially because the GPL protects the rights of all contributors including corporate ones, the corporate market loves GPL much more and thus is more involved. Which always comes with more strings attached. I view GPL more as protection of the authors, not the end users.

The few times serious tinkering was done by commercial entities in BSD it was basically a huge disaster: https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...

> I care very much about people making their own decisions in their own lives (e.g. LGBT, abortion etc)

Totally with you on this

(and that's why I think the software industry should be producing free software for people. So they can make their own decisions without depending on their original providers. Of course, free software is not a sufficient condition to this.)

> I kinda just have given up on the law in general.

Okay, but I hope you'll understand many of us don't see this as an option.

> I don't think the GPL is very good at this. [...]

I don't see how end users have more freedoms with BSD programs and how the GPL comes with more strings attached for the user (who doesn't intend to build proprietary software - of course I'm against this so if you see this as an attached string, I see this string in good light).

> I view GPL more as protection of the authors, not the end users.

I think you are wrong on this. The user owes nothing to the author of a GPL program. They can modify it without contributing back. The authors are not guaranteed to see the improvements to their code, also users are guaranteed the freedoms that come with free software, even for the derivatives (this is where the GPL shines, in my view, compared to permissive licenses).

2021 became boring some time ago, don't cha know, daddy-o?

> commercial entities

iXsystems, Inc.: sponsored commits in three FreeBSD source trees:

https://gist.github.com/grahamperrin/eb0bf1a03b64e14d9288cbd...

Created last week, a snapshot of that point in time, I don't intend to update it.

> Some people in the BSD world are adamant that their code should not be contaminated by the GPL

Yes, and? They want people to be able to use their code freely, without limitations. Check golang packages, they are mostly BSD/MIT.

Thats why BSD is in Playstation and Macs. You think there would be linux GPLed code? There is a usecase for everything and linux doesnt cover them all.

>> Some people in the BSD world are adamant that their code should not be contaminated by the GPL

> Yes, and?

And? Nothing. I'm making an observation, I'm not judging here. They have a strong stance on this, often because they deeply thought about the consequences. I don't agree with them, and I don't care for helping Apple and Sony make their proprietary products, I think we'd probably be in a better world if they participated in improving the commons and that's actually how Linux succeeds, but I respect this stance when it's well thought out.

I think that there is completely different reason why they dont participate in improving the linux. As its fundamental mantra of "move fast, break things" is creating bigger and bigger gnordian knot, while FreeBSD mantra is being well though, designed and stable. SystemD will never get into FreeBSD. Docker is still behind FreeBSD jails (released 2000!) that are a security feature since the start. And so on. And people using and developing it, like such system, which linux is absolutely not.

For fun check this beauty: https://man.freebsd.org/cgi/man.cgi?query=setfib&apropos=0&s...

This why we use FreeBSD. As not only its kernel but also its userspace is well designed.

The *BSD have their merits beyond licensing matters indeed, including technical, design, organizational. That's what would make me look into them.

> Yep it is. You don't want GPL code in your BSD/MIT licensed project or suddenly your whole project is under GPL.

That's not true. The GPL cannot re-license other project's. You just have to write a file with (for example):

We use GPL-Software XY, and here you can find our changes to it...that's it,

Most proprietary consumer-router-firmware handle gpl just like that, Android has the Linux-kernel and is (over all) NOT GPL.

You are talking about separate programs with separate licenses put together in a package of software meant to run together.

I'm talking about putting some GPL code in a program whose code is BSD licensed.

Putting a GPL program in a BSD software distribution would not make the whole package GPL

(However GPL restrictions will apply to the GPL parts and you may not want this in your package of BSD-licensed software)

Of course you can run GPL software on your BSD system, the same way you can run proprietary software on Linux (and BSD).

Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. Now you can always distribute your BSD-licensed kernel and make your users compile some GPL code into your kernel themselves.

It's just that the GPL code unavailable to people that want to build some proprietary product from your BSD distribution, and as a BSD distribution, you might not want too much of this.

>Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL.

NO, absolutely NOT. Not you nor the GPL has the right to re-license someone else code. There are many modules who are not GPL like Nvidia and not even AMD-GPU -> MIT...and still the kernel is GPL, and even the kernel itself has many different (but compatible to GPL2) licenses.

If you change GPL code you have to show your changes (if you redistribute the code) if you have MIT/BSD you don't have to make that step, it really has nothing todo if you mix that stuff (if compatible). The maybe ~problem with CDDL/GPL (ZFS) however is, that you redistribute it in binary form.

You can link MIT code to a GPL kernel just fine, the whole thing would be under GPL (though of course you can take the MIT part use it permissively). But I'm talking about the opposite thing. Distributing a BSD kernel with a GPL module. This would be under GPL as well (but again, you can take the BSD part and use it permissively). This is exactly what people talk about when they say the GPL "contaminates" and this works with the BSD and the MIT licenses because these licenses are known to be GPL-compatible. This is also by the way what people mean when they say a license is compatible with the GPL. While you don't relicense other people's code, the package you create by mixing GPL and MIT code is under GPL. You of course don't have all the rights the MIT grants on the whole package, only the rights common to the GPL and the MIT, which are exactly the rights that the GPL provides since the GPL is strictly more restrictive than the MIT.

You are mentioning NVidia and this actually illustrates my point: nobody distributes the Linux kernel with the NVidia driver because you can't, because of the GPL that forbids you from linking GPL with proprietary code and distributing the result. Instead, you make the user download the kernel, download the nvidia driver and then compile the module locally. That's why we have DKMS. It's a hack around the distribution limitations. Of course it doesn't please the Linux kernel developers too much and that why they have the GPL-only symbols (things that only work if your module is GPL-compatible).

The CDDL/GPL issue of ZFS is the same thing: you just can't distribute the whole thing together if you consider that the licenses are not compatible or don't want to take the risk. Ubuntu certainly does take it but not the rest of the world.

Also no need to get upset, let's have a calm argument, please?

>Also no need to get upset, let's have a calm argument, please?

Yes and i am totally fine with your latest explanation, however you wrote:

>Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL.

And that's just wrong, just because i run a GPL-Driver on Windows make Windows not GPL, and just because i run a GPL-Driver in a BSD makes BSD not GPL, it just means, that package has many licenses and the most restrictive but compatible is (for example) the GPL, so you probably want to follow it's rules.

The more careful and accurate phrasing of my sentence:

>Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL.

Would be: "Any distribution of a kernel with a GPL driver needs to be under GPL and requires the kernel to be under a GPL compatible license."

(I implied distribution because as long as something is not distributed, nothing matters in terms of licensing when it comes to free software licenses.)

Since installing yourself a GPL module in any kernel doesn't constitute a distribution, the direct consequence is that the module and the kernel are distributed separately in such incompatible cases. Which would also be true of GPL drivers on Windows, but the kernel is always distributed alone by Microsoft and the GPL driver by the vendor (while for Linux, distributions could decide to compile the kernel with third-party modules - not sure how the BSD world works in this regard) so the situation is somewhat easier to understand.

Now, distributing GPL code explicitly meant to be linked to the Windows kernel might be a grey area and probably requires all the authors to agree to this. Like, it's not 100% clear to me whether you can take some random GPL code and put it in a GPL driver explicitly intended to be linked to the Windows kernel even if you don't distribute the result yourself. I guess that would be somewhat similar to the ZFS on Linux project though: while everyone writes CDDL code, ZFS on Linux is clearly intended to be linked to the GPL'd Linux kernel.

Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated.

>Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated.

Well you did the same to me, so i have to thank you too ;)

BTW: Absolutely on par with you last comment.

IANAL, but Oracle's lawyers are, and they see no problem distributing GPL 2-licensed Windows drivers for VirtualBox[1], in both source and binary form, so, in the absence of evidence to the contrary, neither do I.

I suspect Windows driver signing requirements may conflict with GPL 3, however, because running Windows in test-signing mode interferes with the normal operation of popular Windows software (e.g., games that require anti-cheat software deliberately incompatible with test-signing mode in general).

OTOH, Windows itself runs just fine in test-signing mode, and surely the fact that other software deliberately chooses not to run if a test-signed driver is installed doesn't imply that Windows is incompatible with test-signed drivers, and therefore GPL 3, so it's hard to say, but I'd personally talk to a lawyer before creating or distributing a GPL 3-licensed Windows driver.

Here's a copy of the click-through license from the latest Windows Driver Kit installer, which, to my non-lawyer eyes, doesn't appear to place any restrictions on use or distribution of drivers created with it, in source or binary form:

https://jasomill.at/wdk-license.html

Obviously any individual or project using proprietary headers under this license to build a driver would have to accept its terms, but this is no different than, e.g., using proprietary headers under the Xcode license to build GPL software for macOS, and the FSF, at least, seems to be fine with this, given that the Emacs project recommends[2] a macOS binary distribution[3] that does precisely this[4], so I assume it's okay.

[1] https://github.com/mirror/vbox/blob/master/src/VBox/Addition...

[2] https://www.gnu.org/software/emacs/download.html#macos

[3] https://emacsformacosx.com/

[4] https://git.savannah.gnu.org/cgit/emacs.git/tree/configure.a...

> IANAL, but Oracle's lawyers are, and they see no problem distributing GPL 2-licensed Windows drivers for VirtualBox[1], in both source and binary form, so, in the absence of evidence to the contrary, neither do I.

But did they take third party GPL code from someone else? If they are the only authors of the code or if all the contributors have directly contributed to the drivers (thus knowing full well their code would end up being linked to the windows kernel), then there can't be any issue.

I think the problem is more the other way around. Look at all the loopholes the Linux crowd has to do to get ZFS in the kernel.

On FreeBSD you can run GPL software without issues. It's all userland anyway. FreeBSD has now separation between kernel and installed software than Linux (where usually if you want rolling userland you must have a rolling kernel too)

ZFS is probably the exception. The problems come from OpenZFS being licensed under the CDDL, not a BSD license.

There's no problem incorporating BSD-licensed code into GPL-licensed software, though.

Reply on news.ycombinator.com