Is it just me or is the incompatibility especially absurd given that perf is currently using libbfd, just 1 step removed via addr2line?

I wonder if a patch to addr2line would be accepted which allows the executable to stay running to accept multiple requests through stdin.

This is kind of the crux of a long history of these licensing arguments. That dynamic linking is problematic because it potentially creates a derived work. And then you might distribute that derived work.

But shelling out to something or in some cases having an automated script create or download the derived work automatically is sometimes acceptable.

It’s a bit of a silly line in some ways. But it’s a long story.

I'm skeptical that there's a coherent legal distinction to be drawn between using a dynamic library with dlopen etc and running a similar executable with arguments. It's functionally identical usage of some public interface.

Agreed, I am very skeptical too. I have a long time believed that dynamic linking vs running an executable with arguments will be regarded the same in a court. So either both are derivative works or neither.

My personal belief is that a court will only care about if your code is a wrapper (e.g, libgpg) or if it is its independently useful and just uses the library (e.g. PostgreSQL using libreadline) for a small part of its operation. But I am not a lawyer and this has not been tested in court as far as I know.

They don't seem to claim there is a distinction on the mechanics there? Rather their distinction seems to be "are these part of the same overall program, or two separate ones", however you measure that: https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins

By claiming that using dlopen to load some code makes your program a derivative work of the library it's using, but shelling out to it doesn't, they're implicitly making a claim as to the distinction of the mechanics.

This has always been my perspective as well, but it goes against long-established norms—for example, it's for exactly this reason that the LGPL was created. I don't think either theory has been thoroughly tested in court, though. See https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ for a countervailing position from the SFC and FSF.

License holder grants you permission to do Foo, but not Bar. For example, it may be legal to show a film at site A (e.g. Netflix), but not at site B (e.g. YouTube), because the license holder said so. Functionality of both sites are almost identical.

There's also interpretation that merely linking with compatible interface would be infringing even without distributing two parts together (curiously, used by Stallman): https://news.ycombinator.com/item?id=26606328

addr2line already does this, and it's exactly what TFA is making use of to get the speedup.

Oops. Literally the only line that I didn't read. I thought the author was providing a patch to link against libbfd for users to manually apply (which afaik wouldn't violate the licenses as long as no one redistributes the patched binary).

Kind of ironic that RMS campained against proprietary software to allow reuse of code. Now we have two islands of open source code ... .

RMS advises to use "GPLv2 or any later version", which is compatible with GPLv3, instead of "GPLv2 only" license.

One could also suggest that the BFD project adopt "GPLv2 or any later version" (like it had prior to 2008), which is compatible with the GPLv2, instead of the "GPLv3 or any later version" license.

"or any later" is controversial. It essentially puts your project under the agenda of the FSF, which not everyone wants.

Doesn't "GPLv2 or any later version" mean that you can use the software under the terms of GPLv2 or GPLv3 (or some hypothetical GPLv4)?

It can't possibly add any restrictions to the use of your project, because people can always just use it under the terms of GPLv2 if they want.

I guess it could remove restrictions, if the hypothetical GPLv4 was a total 180 and looked more like the MIT or Apache licenses, so I guess if that's a concern then you have a point.

If a new version of the GPL adds restrictions, that still can be undesirable for the writer if the original software.

If a third party forks a GPLv2+ project, adding features that are GPLv3+ licensed, the result is GPLv3+ licensed.

That means those wanting the GPLv2 licensed project won’t be able to use those new features.

At least you can legally build it locally, just not distribute the result. That's still better than what's possible with proprietary software.

As drran mentioned, I'm sure RMS would say the problem here is that Linux is licensed under v2 only. Linus of course would disagree.

There is proprietary "source available" software that I can compile locally but not distribute the result either. The GPLv2/3 disaster is not an improvement.

Two? Are the AGPL licenses compatible? How about GPL licenses with exceptions for some APIs as used by OpenJDK?

The AGPL licenses are explicitly compatible with the GPL ones. FWIW, this issue is essentially entirely caused by Linus, who refuses to use or accept GPL3.

> FWIW, this issue is essentially entirely caused by Linus, who refuses to use or accept GPL3.

That's a bit disingenuous. Linus has said no to the GPLv3, yes, but his reasons for doing so have merit.

The very fact that the GPL v3 is incompatible with v2 indicates that v2 has something the v3 takes away, no matter how well-meaning that was.

What the GPL3 takes a way is a loophole to violate the spirit of the GPL without violating the letter of the GPL2.

Linus's reasons for causing this issue having merit does not mean he wasn't entirely the cause of the issue: those are unrelated axes.

Unless perf has the standard clause allowing use of later versions of GPL. That would make it GPLv3 if linked against libbfd.

Unfortunately it does not.

That's pretty typical for things in the kernel ecosystem.

Debian could provide a tool which builds it for you, on your system, right? The resulting binary would not be redistributable but you could use it.

I've often wondered why more linux distros don't provide a similar tool to build ZFS into the kernel for you.

Debian nicely offers this with the zfs-dkms package.

Ubuntu just bundles ZFS into the kernel statically - not even as a loadable module - and damn the licensing implications(!).

So this means the distributor can fix this by building this package locally and use the result to link other binaries to? This isn’t uncommon right?

You're right. I should clarify. Thank you!

I’ve wondered about similar situations.

Take Yosys, an open source synthesis platform that allows external commands by adding shred libraries. It’s MIT licensed.

There is the Yosys-GHDL plug-in that allows using VHDL instead of Verilog compilation. It’s an independent open source project that can’t be merged into the main Yosys tree because GHDL itself is GPL 2.0.

Is the author of that plug-in violating the GHDL license? The plug-in glue code is GPL2 as well.

Can the GHDL authors ask the plug-in authors to take down their code (which has been forked many times on GitHub, of course.)

The plugin is potentially a derivative work of both Yosys and GHDL, but that's fine - it's possible to comply with the requirements of both the MIT license and the GPLv2 at the same time. The resulting work is GPLv2-licensed. (To be precise, you also need to preserve any copyright notices from the MIT-licensed project and the text of the MIT license. The MIT license has only one condition, but you do need to follow it, same as if you were building proprietary software with an MIT-licensed component.) If anyone distributes Yosys with the plugin, the combined work must also be distributed under GPLv2, which is also fine.

In this case, perf is (like the Linux kernel, in whose git tree it lives) GPLv2-only, and modern versions of libbfd are GPLv3-or-later, and it's not possible to comply with both at the same time. The GPLv2 has a "no additional restrictions" clause, and the GPLv3 asks for things the GPLv2 does not. So a distributor of a combined system including perf built against libbfd (like a Linux distro) cannot comply with the licenses.

(I suppose perf was written against the libbfd API back when libbfd was GPLv2, avoiding the question of whether perf is an illegal derivative work of libbfd. Or the backtracing API is de minimis, which means the source is fine but a compiled binary as par of a distro that also includes a modern libbfd is not.)

One possible answer here is to ask the perf authors to relicense under GPLv2 or later. Many years ago, at a startup that no longer exists, I wanted to reuse code from the Linux kernel "dm-verity" module in GRUB, which had moved to GPLv3, and I got a pretty quick answer from Red Hat (who was the only copyright holder for those files) saying that would be fine.

Your answer and the one from another commenter mention distribution.

In this spirit, is there any legal issue with downloading perf and libbfd separately, compiling it, and running using it for yourself only? I assume not?

What about using it then as a tool within your company? That might be seen as distribution, and thus not allowed?

There's no legal issue with using it yourself. Debian's problem is that, as a distro, they are creating a single product - the Debian operating system.

Debian could even ship you something that compiles perf against libbfd on your own system. This is the approach they take with ZFS and Linux, which are under incompatible licenses (CDDL and GPLv2): https://bits.debian.org/2016/05/what-does-it-mean-that-zfs-i...

A company is generally a single legal person and so there's no "distribution", but https://www.jolts.world/index.php/jolts/article/view/66/125 is a law review article that discusses the complexities here. If you employ contractors, or if the company as a whole is purchased, the answer is apparently blurrier.

Thanks!

My understanding is that there’s only a problem if the distributor combines the two things: if the main application is one license and the plug-in a different one, it’s not a license violation for the end-user to combine the two (unless they turn around and become a distributor in some way).

I am pretty sure that depends on the intent of your distribution. If your software is useless with the plugin and you go "wink wink nudge nudge use this plugin to make this work" this would probably be infringement. If your software is functional without this, and you just happen to have the ability to load plugins of which this is one of them, then it's much better.

its arguable when it comes to dynamic shared libraries (i.e. the ZFS argument).

How do other distributions handle this? Do they also have a slow perf? Or do they just link perf with libbfd regardless of the incompatible licenses?

DKMS style linking at install time might be an option, but I've never seen it used in practice

Is there not an exception in the license for "system libraries" which libbfd kind of is?

Is it? On my system the only things depending on binutils (which libbfd is part of) are gcc, clang and perf (seems archlinux doesn't care).

That makes it arguably not a system library, so it's fair that Debian would want to steer clear of that interpretation.

What is Clang using it for? I thought it had its own suite of that.

This... is some weirdness in Arch's clang package.

It depends on gcc, for some reason, and that depends on binutils?

(and I have no idea if anything here uses libbfd, since it's just a part of the binutils package and not split out)

Clang uses part of the host compiler toolchain; gcc is the default compiler on Arch included in the base package.

https://stackoverflow.com/a/38291698/4179075

Maybe it depends on gcc so it can use gcc's assebler for inline assembly?

no its for linking. basically clang unless configured in the source it does not know what link options to give. Actually even rust uses gcc or clang to do same thing.

Clang will also use libgcc by default under Linux to allow e.g. stack unwinding to work in mixed Clang + GCC applications.

If we are nitpicking, they can, there is nothing material stopping them. It is "just" at odds with copyright law.

In a society with different laws, there would be no problem. I wonder what would be greater - the productivity gain when we would not have to make workarounds due to licensing, and when we could just legally access the source code of everything. Or the loss, because people might have less incentive to innovate, or they would just keep the source hidden.

If only we were permitted to view the digital IP rights tyranny as another disruptable industry with latent energy that could be unlocked by a savvy founder...

The economic activity & value directly suppressed by IPR is unbelievable. Hard to even mentally scratch the surface. It's extremely economical (for society) to digitally copy and distribute useful information.

Most Western IP laws are draconic in the purest sense of the word.

Unfortunately their is a very influential sect of "corporate-law fearing" IP fanatics at the heart of many FOSS tech traditions (RMS, et al). Not all of it is pragmatic.

> Most Western IP laws are draconic in the purest sense of the word.

IP laws in most countries are also not decided by a democratic process but rather pushed in by trade deals, which also make it almost impossible to change those laws.