Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

Posted Sep 25, 2020 22:14 UTC (Fri) by IanKelling (subscriber, #89418)
In reply to: Toward a "modern" Emacs by NYKevin
Parent article: Toward a "modern" Emacs

Its not a CLA. Its a copyright assignment to a nonprofit dedicated to free software. US nonprofits can't be bought, they are bound by law to follow their mission, and FSF is ultimately run by by a volunteer board who would never stray from that mission. And there is a barrier to pulling your code: enforcing copyright when you don't own the copyright is significantly harder.

> ignore the current state of the industry

Give me a break. Here's a related link.
https://www.gnu.org/philosophy/words-to-avoid.en.html#Sof...

to post comments

Toward a "modern" Emacs

Posted Sep 25, 2020 23:30 UTC (Fri) by sfeam (subscriber, #2841) [Link] (3 responses)

I am assuming that CLA here means "contributor license agreement". Can you explain how a formal copyright assignment is not an example of a CLA? I agree with the OP. If a contributor has already released code under GPL, that should be sufficient for any GPL project to incorporate it. Anything beyond that is an unwanted burden.

Toward a "modern" Emacs

Posted Sep 26, 2020 6:46 UTC (Sat) by eliz (guest, #94829) [Link] (2 responses)

> Can you explain how a formal copyright assignment is not an example of a CLA?

You need to read the assignment agreement text to understand that.

Basically, you assign the copyright to the FSF, and the FSF gives it back to you, so that you still have full copyright of the code you wrote, and can do whatever you want with it, including distributing it on whatever terms.

The paperwork is important only to the code that is part of Emacs, not to your original work. Authors always have full rights for the code they wrote.

Toward a "modern" Emacs

Posted Sep 26, 2020 11:13 UTC (Sat) by DeletedUser128680 ((unknown), #128680) [Link] (1 responses)

My understanding was that you do not get back the copyright, that you are instead granted a non-exclusive license to do what you want with your contribution. That is an important distinction: it determines who can take legal action against infringers, that was one of the reasons for having the copyright assignment in the first place. I looked for examples of the copyright assignment papers and found Free Software Foundation Copyright Assignment Form, which supports my understanding. Have things changed since then?

Toward a "modern" Emacs

Posted Oct 2, 2020 10:42 UTC (Fri) by kpfleming (subscriber, #23250) [Link]

No, they have not, this is correct. It is not possible to assign your copyrights to another party and then for them to 'assign it back to you'. If that were possible, the net effect of that document would be zero.

You assign your copyrights to the FSF, and they grant you a broad license (beyond the terms of the GPL or any other FSF software license) to continue making use of your contributions in any way you wish (as long as that use does not conflict with the FSF's use of the same contributions).

Toward a "modern" Emacs

Posted Sep 25, 2020 23:55 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

> US nonprofits can't be bought, they are bound by law to follow their mission, and FSF is ultimately run by by a volunteer board who would never stray from that mission.

You missed the word "bankruptcy." If they go bankrupt, they may have no choice in the matter. This is precisely what happened to Sun.

> And there is a barrier to pulling your code: enforcing copyright when you don't own the copyright is significantly harder.

If I would agree with the upstream's enforcement action, then they can ask me to sign onto it at the time it actually happens. If I would not agree, then I see no reason to give them permission in advance. Regardless, they have the legal right to use the code. From my perspective, their personal preferences regarding how a purely hypothetical enforcement action would proceed are not my problem.

> Give me a break. Here's a related link.

Your link does not appear to be relevant to my argument, but instead merely states a preference to avoid the use of a specific term because it carries certain connotations, connotations which my argument does not depend on and which are entirely unrelated to this discussion. Since it is not relevant, I am ignoring it entirely.

Toward a "modern" Emacs

Posted Sep 26, 2020 0:27 UTC (Sat) by mohg (guest, #114025) [Link]

The issue of bankruptcy has been previously addressed at eg
https://lwn.net/Articles/582472/

Toward a "modern" Emacs

Posted Sep 26, 2020 0:00 UTC (Sat) by dvdeug (guest, #10998) [Link] (14 responses)

US nonprofits can be dissolved or assigned, or change their interpretation of their mission. They can also sell off assets to fund their mission; museums do this all the time, and any larger nonprofit has gotten rid of a building or two when it was time for a change. As for a volunteer board who would never stray, lots of people and groups have evolved over time.

> 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. And the structure of Emacs should aid in that; whether or not a Lisp package is owned by the FSF should be irrelevant if they infringed on Emacs, a complete tool without that Lisp package. It wouldn't give them control if that Lisp package was infringed alone, but that's life, and I would think that's pretty far down the list of things the FSF should be worrying about.

Toward a "modern" Emacs

Posted Sep 26, 2020 1:53 UTC (Sat) by pizza (subscriber, #46) [Link] (13 responses)

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

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.