Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

Posted Sep 26, 2020 1:53 UTC (Sat) by pizza (subscriber, #46)
In reply to: Toward a "modern" Emacs by dvdeug
Parent article: Toward a "modern" Emacs

>> And there is a barrier to pulling your code: enforcing copyright when you don't own the copyright is significantly harder.
> The Linux kernel seems fairly successful in that.

Huh? If anything, the Linux kernel is a poster child for _poor_ copyright enforcement, because nearly everyone in a position to actually enforce it has deliberately (and publicly) chosen not to.

And even when they want to enforce their rights, the sheer size of Linux versus any one individual contributor's portion makes it considerably harder -- this is a large part of why the VMWare suit failed.

to post comments

Toward a "modern" Emacs

Posted Sep 26, 2020 18:54 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (12 responses)

> Huh? If anything, the Linux kernel is a poster child for _poor_ copyright enforcement, because nearly everyone in a position to actually enforce it has deliberately (and publicly) chosen not to.

This is a Good Thing. It means the Linux kernel developers are exercising personal agency over their code, rather than blindly allowing people who have contributed nothing to the kernel's development to make decisions on their behalf. It means that enforcement is more a matter of community norms and less a matter of "Here's what the FSF/SF[L]C/[somebody else who didn't write the kernel] says the GPL means."

I realize this frustrates Free Software activists to no end, but the desires of Free Software activists are not LKML's primary concern. Their goal has always been to have a kernel that (mostly) works and is (mostly) portable, and their licensing decisions have enabled them to accomplish that goal (by getting compatibility patches back, and mainlining them where it is appropriate and practical to do so). It is not reasonable to declare their process a failure when it is working exactly as they intended.

"Surely they cannot have intended widespread violations of the GPL?" you might ask. That's the wrong question. If they're unwilling to enforce, that means they don't think it's a violation in the first place, or at least not a violation that they actually care about. You may disagree on either or both of those points, but it's up to them to decide how and when they enforce their copyright.

> And even when they want to enforce their rights, the sheer size of Linux versus any one individual contributor's portion makes it considerably harder -- this is a large part of why the VMWare suit failed.

This is potentially a more serious problem - but it ultimately comes down to the same community norms. If you go around trying to recruit individual developers for a lawsuit, you are probably going to face issues getting a critical mass of people to sign up. You need to reach out to the community as a whole and convince them that the lawsuit is in the best interest of the project, and then you should be able to come up with enough plaintiffs with (between them) enough code contributions to demonstrate infringement.

That's rough when the project doesn't care about Free Software values. Too bad, it's not your code. You don't get to tell them how to enforce their copyrights. If most of them didn't want to sue VMWare, then maybe suing VMWare wasn't in the interest of the project after all. Or maybe it was, but the SFC did a bad job of reaching out to the community; I haven't adequately investigated this specific case to say what happened there. I will note that the SFC's FAQ conspicuously fails to mention any direct and explicit outreach to LKML for additional plaintiffs, but perhaps they didn't even realize it would be necessary or useful to do so, or perhaps they did reach out, but felt it would be unnecessary to record such a discussion in their FAQ. Hopefully, going forward, such outreach will be standard practice when dealing with GPL violations involving the kernel.

Toward a "modern" Emacs

Posted Sep 26, 2020 19:29 UTC (Sat) by pizza (subscriber, #46) [Link] (2 responses)

> This is a Good Thing.

As the copyright holder for a couple of (mostly obsolete) chunks of the Linux kernel, I strongly disagree.

> I realize this frustrates Free Software activists to no end

Who gives a crap about what nebulous "free software activists" want? I, as an *end user*, want the complete corresponding source code I was promised. That's it.

Toward a "modern" Emacs

Posted Sep 27, 2020 6:20 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

> I, as an *end user*, want the complete corresponding source code I was promised. That's it.

This is a gross misunderstanding of the GPL, and of copyright law generally. No promise was ever made to any end users, so there is nothing for them to demand in the first place.

Rather, a promise was made to the original copyright holders. While the GPL may have been intended to give rights to end users, that is not what it actually does, nor is it what Linus (at least) wanted out of the GPL anyway (see https://www.youtube.com/watch?v=PaKIZ7gJlRU). And this is fine. People can use the same license to very different ends. This is cold comfort when you're the end user trying to get the source that you just *know* the XYZ company is required to provide, and nobody on LKML cares, but it's their code. If they want to let people steal it, that's their choice. Perhaps it is an unwise choice, but a choice nonetheless.

> As the copyright holder for a couple of (mostly obsolete) chunks of the Linux kernel, I strongly disagree.

If you can find people infringing on those specific chunks, you are free to do as you see fit, in your role as the copyright holder for those chunks. But not in your role as an end user, because end users are not parties to the GPL.

Toward a "modern" Emacs

Posted Sep 27, 2020 7:57 UTC (Sun) by dvdeug (guest, #10998) [Link]

> This is a gross misunderstanding of the GPL, and of copyright law generally. ... While the GPL may have been intended to give rights to end users, that is not what it actually does,

So, yeah, if you want what the GPL was intended to give you, it doesn't seem a gross misunderstanding of the GPL to expect that.

> No promise was ever made to any end users, so there is nothing for them to demand in the first place. ... People can use the same license to very different ends.

It seems you're making RMS's case for him. Above you say:

> You have the code, it is fully GPL-compliant, and (as a result) it's already licensed under the same terms as upstream.

But then you say that functionally it's licensed under very different terms, that functionally an end user has no right to expect creators of a derivative work to offer source code for the work. RMS wants Emacs, and by Emacs I mean the whole thing the FSF distributes in one tarball, to be free software with end users provided with source code for derivative works.

My problem with such a treatment of licenses is a free content provider; as an uploader of photographs to Commons, every time someone slaps the CC-BY-SA on their photo and then lets people use it as if it were public domain, it reduces the value of my CC-BY-SA on my photograph. If everyone is treating CC-BY-SA as being public domain, then I'm being unreasonable when I demand the works be treated as per the license. If one or two copyright owners of GPLed works get tetchy about distribution of their code against the licence, the rest of us are likely to be treated as unreasonable nuisances when complaining about license-infringing distribution; if many copyright holders so act, then normal (not pirates, not carefully conscientious) distributors will make an effort to follow the license.

Toward a "modern" Emacs

Posted Sep 26, 2020 20:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

> This is a Good Thing. It means the Linux kernel developers are exercising personal agency over their code, rather than blindly allowing people who have contributed nothing to the kernel's development to make decisions on their behalf.
The lack of enforcement means that bad actors have competitive advantage over good actors.

Toward a "modern" Emacs

Posted Sep 27, 2020 6:33 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

The problem with the word "bad" is that it's ridiculously subjective. Canonical is, to the best of my knowledge, still shipping ZFS binaries, which may or may not be a GPL violation depending on which group of lawyers you ask (e.g. the SFC and the SFLC disagree), and as far as I can tell, nobody has sued them or expressed any interest in doing so. We may never get a legal resolution to this case, and we may never know whether this is a violation or not.

Is Canonical a "bad actor" within your definition?

Toward a "modern" Emacs

Posted Sep 27, 2020 6:38 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Canonical is not a bad actor. A smart device manufacturer that doesn't supply the kernel source is one of them.

A couple of jobs before, we had a NAS appliance that ran a copy of Linux with special RAID drivers and device management drivers (cooling, temperature sensors). Without any source code provided. This is another example of a bad vendor.

Toward a "modern" Emacs

Posted Sep 27, 2020 18:29 UTC (Sun) by marcH (subscriber, #57642) [Link] (5 responses)

> The lack of enforcement means that bad actors have competitive advantage over good actors

Just like they have with a permissive license.

I think the tl;dr is "The kernel uses the GPL in a more permissive way". Nowhere near as permissive as a BSD license of course but more permissive than Emacs and other FSF software. I can understand the frustration of the "real" copyleft fans seeing their (world-domination...) tool used in a weaker way than intended.

Toward a "modern" Emacs

Posted Sep 27, 2020 19:05 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> Just like they have with a permissive license.
No, it's not.

GPL has very real compliance costs that a good actor has to pay. This will increase the price of the product and/or make it more complicated (for example, you might have to move your "secret sauce" from kernelspace to userspace). A bad actor can just ignore these costs.

With permissive licenses the compliance cost is usually trivial. So all vendors are on the level playing field.

Toward a "modern" Emacs

Posted Sep 28, 2020 10:04 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (3 responses)

As the grand parent wrote, the notion of a bad actor very subjective. For a consumer of the device who saved some money because that actor passed some of the savings from not complying to GPL to the consumer that actor is good.

And again, the license alone just sets an upper bounds on efforts to comply. The real required efforts depends on copyright holders. And in case of Linux those effectively decided that it is better to have Linux on more devices even if the collateral is that in a lot cases the device manufactures do not follow GPL.

Toward a "modern" Emacs

Posted Sep 28, 2020 16:17 UTC (Mon) by marcH (subscriber, #57642) [Link]

> As the grand parent wrote, the notion of a bad actor very subjective. For a consumer of the device who saved some money because that actor passed some of the savings from not complying to GPL to the consumer that actor is good.

Good and bad can be subjective but I think you're stretching that a bit too far. I doubt violating software licences for profit is considered "good" in any culture. I'm sure it's "not as bad" in some or can yield precedence to some higher cause in others but "good"?

Now of course most consumers will have no idea that their device violates the GPL but that's ignorance not subjectivity.

Toward a "modern" Emacs

Posted Sep 28, 2020 16:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

OK. Change the word "bad" to "software license violator" then.

Toward a "modern" Emacs

Posted Sep 28, 2020 19:17 UTC (Mon) by dvdeug (guest, #10998) [Link]

The licenses you have on a piece of software set the requirements you have for distributing that software. You can argue an implied license, but arguing that it's okay to copy a whole work with no possible fair use argument just because you don't think you'll get sued is simple piracy.

In the case of Linux, like any other work with so many copyright holders, it's clear that at least some copyright holders don't agree with this implicit license, even if they don't always have the will to go through with a court battle. That's why we have explicit licenses, so all the copyright holders on Linux can get together and agree on the terms.