Hacker News Reader

Comment by tiffanyh | Hacker News Reader

> This repository represents the reference implementation, provided as an open-source dual BSD and GPLv2 licensed C library

Dumb question, why dual license? Why not just provide it as BSD (the more permissive of the two)?

View on HN

As non-author of any work, you can't relicense it no matter how permissive the license is.

When linking BSD code with GPL-licensed code, you have to have all the code follow the terms of GPL, which means effectively relicensing it. This is why some companies require copyright assignment even if they plan to stay open source.

Only the public domain code allows free mixing and matching.

Not a lawyer though, so take the above with a bowl of salt.

Edit: in theory, this allows using zstd in GPL2 projects, for instance, in the Linux kernel.

> As non-author of any work, you can't relicense it no matter how permissive the license is.

There are some licenses such as MIT where you can. But GPL is very much the code has to be GPL. But I also think it infects your code and forces your code to be GPL, but that may only be if you make a modification and change it and not just use GPL code within your code.

If you redistribute it, not change it.

> it infects your code and forces your code to be GPL

Does this dual license satisfy companies who have a policy of “no GPL” code?

It should. They would take the BSD option. (Corp lawyers can be paranoid, and might still object. But in theory they should be able to accept this under the BSDL.)

The GPL v2 requires that any code that this code is linked to is also released as GPL.

For example, if I want to use Pango, which is GPLv2, in my application, then the GPL requires that I also release my application's source code as GPLv2, or another compatible license.

It also requires that if I make changes to Pango and redistribute it then I need to release the source code for that as well. In other words, if I fork Pango then my fork also has to be GPLv2.

It's not so much that it 'infects' your code as that it's not compatible with closed source (or some open source licenses).

A while back, Microsoft decided to abandon their awful TCP/IP stack and use a better one - FreeBSD's TCP/IP stack. Since FreeBSD is BSD-licensed, it was possible for them to take that code, use it, modify it, and redistribute compiled versions of it, without having to give back any changes or optimizations to the open-source community.

By choosing the BSD license for their code, the project was implicitly saying that they were okay with this code sharing, and so they don't look at this as a bad thing. Microsoft's OS got better, and it didn't cost anyone else anything.

Some groups, however, think that open-source should only benefit open-source, because that's beneficial to users and the world as a whole. This is the purpose of the GPL: you can use our code, but only if all of us benefit and not just you.

To be clear, the GPL does not say anything in particular about "linking;" that's a common interpretation of what it means to be a derivative work. Wikipedia has a blurb on this:

> This key dispute is whether non-GPL software can legally statically link or dynamically link to GPL libraries. Different opinions exist on this issue. The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL. Ambiguity arises with regards to using GPL libraries, and bundling GPL software into a larger package (perhaps mixed into a binary via static linking). This is ultimately a question not of the GPL per se, but of how copyright law defines derivative works.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...

Few people mention it, but whether (dynamically) "linking" to a library makes it a derivative work is closely related to the GOOGLE v. ORACLE case. The issue with dynamic linking is basically "copying the API (and ABI)". Unfortunately the USSC didn't really give a clear ruling on this one.

A more obvious case is the one of Linux (GPLv2 licensed) closed source binary modules: Linus has specifically said that he is not opposed to such usage, so it's never been tested in court either.

> in theory, this allows using zstd in GPL2 projects, for instance, in the Linux kernel.

More than theory, there is actually an implementation of zstd in the Linux kernel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The commit history shows the GPLv2 was added as an option the same time they removed the PATENTS.txt file. React's former "BSD + PATENTS" licence had been criticised, being replaced with the MIT (Expat) licence. Similar motivation here presumably.

Maybe it is for patent protection? I think BSD licenses do not grant explicit patent licenses but GPL does.

Just venturing a guess - may be that libraries that link this would want the option of GPL whereas commercial/non-libre software might prefer BSD?

GPL code can already link BSD libraries without an explicit GPL license option.

Isn’t BSD flavour with advertisement clause + GPL problematic? Specifically that GPL requires no further hindrance to distribution.

Approximately no one uses the 4-clause BSD (the problematic one). The one Zstd uses has three clauses: https://github.com/facebook/zstd/blob/dev/LICENSE

https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_...

There are derivates of the 4 clause BSD, like PHP License, which bave some relevant users. Considering Facebook has some historic use of PHP things (while rewritten to Hack, but that uses some PHP libraries) pure GPL might cause issues for them.

Still doesn't explain why pure BSD won't work for them, though

In case somebody still reads this a theory: Maybe they want to get standard into GNU coreutils, so it natively works with tar etc. for that GPL may make things simpler politically.

Reply on news.ycombinator.com