LWN: Comments on "Villa: Setting new expectations for open source maintainers"

Villa: Setting new expectations for open source maintainers

Klavs — Wed, 08 Sep 2021 12:43:57 +0000

>But if Sam is pseudonymous and we cannot identify them, then it's just our word against the plaintiff's; one Git history against another. Who knows which one is real?

Isn't this solved by GPG signing all commits and ensuring all public keys of commit'ers is in the sourcecode as well (signed by the party who verified the key they added).

In normal work - its easy to simply tell your git config to sign all commits :)

Villa: Setting new expectations for open source maintainers

mirabilos — Fri, 03 Sep 2021 23:22:29 +0000

Only with the machine-readable copyright file, which is an opt-in and questionable anyway, as it applies to the source package, whereas the copyright file as required by Policy applies to the binary package in question (I’ve had source packages that build different binary packages with different copyright files, and with good reason) and not all that useful.

In the end, perhaps the maintainer also prefers the human-readable copyright file over the machine-readable one?

The machine-readable one is also another 90% solution: it was never intended to even work in all cases in the first place. But it makes things easier for a percentage of the 90% it could be stretched to even apply to.

Villa: Setting new expectations for open source maintainers

marcH — Sun, 29 Aug 2021 19:45:25 +0000

> > Capitalism is really excellent to find a way to produce something for the least amount of investment aka capital.

Absolutely. And it is not "evil" but _blind_:

> Please refuse to do anything which you do not want to do. If our managers are unaware of the real costs of producing these things, then they will just keep asking for them.

Villa: Setting new expectations for open source maintainers

nilsmeyer — Sat, 28 Aug 2021 21:23:27 +0000

Many artists, actors and musicians use pseudonyms as well, both for artistic as well as reasons of safety.

Villa: Setting new expectations for open source maintainers

bkuhn — Wed, 25 Aug 2021 00:57:58 +0000

I admit annoyance with this article, in part because not only does it quote me wildly out of context (using a quote where Fontana is quoting me and clearly says that he's applying something a said to a novel issue I didn't consider in the original quote!), but also implies I use Twitter, which I don't! So, given that Luis was pretty disingenuous to me, and followed the recent trend of Open Source lawyers misquoting me and hoping I just won't find out (I guess?🤷) , I suppose the rest of my comments need to be taken with a grain of salt, but perhaps they're useful nonetheless.

Luis' article just plain misses the point. It's accurate as far as it goes: companies want to get people to do as much work for as little money as possible, and companies priorities don't necessarily serve their users' needs. But, the idea that if we just got people paid to do more of what companies want would make FOSS better is ludicrous.

At this point, FOSS has been so coopted by companies, this kind of approach will just make it so that there really isn't any user-focused FOSS left. If you take a look at projects like Godot and phpMyAdmin over at Conservancy, we have sustainable projects where the developers are being paid a very reasonable wage to work on the software and do it in the public's interest. TideLift seems to have no interest at all in having developer and user-focused projects again, where the individuals who really care about the software and want it to be good for everyone are in control. TideLift seems to just find a way to route more corporate money to projects, which is a big part of what caused these problems in the first place. We can't just make FOSS “work just like VC startups do to get software written”. Well, we can, we'll just finally lose absolutely everything that was good about FOSS in the first place, after already having lost so much.

I want people to be paid living wages for their work on FOSS. But, I don't think trying to make sure FOSS maintainers all get paid the same amount that they'd get working at a VC-funded start-up will be an improvement.

Villa: Setting new expectations for open source maintainers

JanC_ — Tue, 24 Aug 2021 19:23:41 +0000

I wonder how that works when there are many different publishers (as is often the case for open source software)?

Villa: Setting new expectations for open source maintainers

JanC_ — Tue, 24 Aug 2021 19:14:54 +0000

Any later changes to that copied BSD-licensed code would seriously complicate such endeavours. I guess some sort of git integration could be a solution, provided you never commit code with multiple licenses at once…

Villa: Setting new expectations for open source maintainers

oldtomas — Tue, 24 Aug 2021 07:39:34 +0000

No, I'm only using minor Free Software ;-P

Snark aside: no, I'm not happy about how most of corporate world is going about free software. In my eyes it's a dystopian perversion worthy of Huxley's Brave New World.

But I'm aware that you and me disagree in this point. Let's agree to differ.

Villa: Setting new expectations for open source maintainers

pabs — Tue, 24 Aug 2021 01:48:58 +0000

These policies are likely to cause *less* people be willing to help work on open source, especially security researchers, who often go by pseudonyms to help protect their safety online and offline.

I think you mean SolarWinds not Solarflare? Can you explain how greater identity requirements would have prevented the SolarWinds compromises? It seems like it was the SolarWinds build servers that were compromised, rather than developer systems, so it seems to me that if Orion was open source, then reproducible builds would have been enough to detect the compromised build servers.

https://www.crowdstrike.com/blog/sunspot-malware-technica...
https://reproducible-builds.org/

Villa: Setting new expectations for open source maintainers

shemminger — Tue, 24 Aug 2021 00:09:52 +0000

Given the Solarflare compromises, the security community would like to have more developer identity / culpability requirements not less.

Vulnerabilities as a reason for SBOMs

wittenberg — Mon, 23 Aug 2021 15:53:55 +0000

One reason organizations are requesting SBOMs (Software Bills of Material) is to try to know what needs patching. There are many examples of low-level code having vulnerabilities (and a few examples of supply-chain attacks) resulting in vulnerabilities in many higher level programs. With an SBOM, I have a chance of noticing the the new CVE in some code I inherit, but have never consciously though about affects me, and that I'll have to rebuild my system. Without an SBOM, I'm relying on programs like Black Duck to tell me what vulnerabilities I inherit.

This issue is orthogonal to the copyright discussion which has occupied most of this thread.

--David

Villa: Setting new expectations for open source maintainers

carORcdr — Mon, 23 Aug 2021 04:09:26 +0000

"But if Sam is pseudonymous and we cannot identify them, then it's just our word against the plaintiff's; one Git history against another. Who knows which one is real?"

For some time, in the case of an anonymous or pseudonymous author, the copyright conventions and treaties have treated the PUBLISHER as the party entitled to protect the work.

Art. 15
...
For an anonymous or pseudonymous work the publisher whose name is indicated on the work shall be entitled to protect the rights belonging to the author. He shall be without other proof, deemed to be the legal representative of the anonymous or pseudonymous author.

Interntional Convention Relative to the Protection of Literary and Artisitic Works Revising That Signed at Berne, September 9, 1886, etc. Signed at Berlin, November 13, 1908. 1 L.N.T.S. 218; Ante, 226.

Abbreviations.
L.N.T.S. League of Nations Treaty Series.

Villa: Setting new expectations for open source maintainers

NYKevin — Sun, 22 Aug 2021 23:22:53 +0000

Speaking, again, as someone who actually works for one of these big corps (but does not speak *on their behalf*): Please refuse to do anything which you do not want to do. If our managers are unaware of the real costs of producing these things, then they will just keep asking for them. Unless we can say to a manager something like "You can have [X], but it will realistically take six months and three of our own developers, who could otherwise have been doing [Y] and [Z]," they just see it as Somebody Else's Problem.

Villa: Setting new expectations for open source maintainers

rahulsundaram — Sun, 22 Aug 2021 11:21:35 +0000

Unless you aren’t using any major open source software anymore you aren’t passing anything

Villa: Setting new expectations for open source maintainers

oldtomas — Sun, 22 Aug 2021 08:43:11 +0000

"[...] are also responsible for the majority of new OpenSource code"

Yeah, I know. At the known-stellar quality of npm.

Thanks, I think I'll pass.

Villa: Setting new expectations for open source maintainers

kunitz — Sun, 22 Aug 2021 07:41:50 +0000

I had a big laugh reading that. Just heard the official Google Kubernetes podcast interviewing the release manager for version 1.22. A young Indian female engineer, Savitha Raghunathan, who emphasized several times that she only participated in meetings during her work time and did the rest after work. There was a lot of talk -- an awful lot from my point of view -- about burn-out in that podcast.

Imagine that the release management of the hottest piece of software used by all the large enterprises now is done by a young lady in her spare time. Capitalism is really excellent to find a way to produce something for the least amount of investment aka capital.

Recently I was pushed to create a CVE number for a potential DOS vulnerability in my open-source Go module. In Github is not a big deal, but if my software would have more issues like that, it would become work. Reading the article referenced here, it looks like that the system -- the capitalist one -- tries now to outsource the compliance management part of software development to unpaid volunteers.

Villa: Setting new expectations for open source maintainers

IanKelling — Sun, 22 Aug 2021 05:56:13 +0000

Metadata is data about some other data. Of course that can exist in the same file as the other data. A license header is metadata about the source code in a file.

Villa: Setting new expectations for open source maintainers

pizza — Sun, 22 Aug 2021 03:36:43 +0000

You're mostly correct, but all of that "big corporation open source" is built on top of a teetering mass of code that "someone else" wrote. Whether or not that "someone else" is another "big corporation" or a "hobbyist" is irrelevant; the point is that the costs of writing and maintaining that stuff are external.

Villa: Setting new expectations for open source maintainers

Cyberax — Sun, 22 Aug 2021 03:26:44 +0000

These "big corporations" are also responsible for the majority of new OpenSource code. The old model of "hobbyists writing GPL code in spare time" is basically 0xDEAD.

Villa: Setting new expectations for open source maintainers

donbarry — Sun, 22 Aug 2021 03:12:45 +0000

Something tells me much of this is the desire of "large enterprises" to be able to streamline the process of pilfering from the commons (MIT and BSD code) while minimizing the amount of work necessary to be sure it is free from the terrifying (to them) GPL virus. Not all of it, to be sure, but much of it.

All the more reason for those of us who write GPL code to document it (in whatever form, let their preferences for specifics be damned), to protect the commons from that pilfering.

Villa: Setting new expectations for open source maintainers

Wol — Sat, 21 Aug 2021 22:21:01 +0000

More fool the lawyers ... what about all those real people called "John Smith", or "Tommy Atkins", or even "John Doe"?

Cheers,
Wol

Villa: Setting new expectations for open source maintainers

Wol — Sat, 21 Aug 2021 22:17:15 +0000

> If we know who Sam was, then we can subpoena Sam and force them to come in and give a deposition about how they wrote the code.

And how do you know that "Sam" is not a pseudonym? (for example, my nic is a derivation of my name - even though it may look it, it's not random ...)

At the end of the day, what you want is an assurance that a "handle" (for want of a better word) can be associated with a real human being. Whether that handle is a real name, a pseudonym, an employee number, or a random jumble of words is completely irrelevant to the problem.

Cheers,
Wol

Villa: Setting new expectations for open source maintainers

rodgerd — Sat, 21 Aug 2021 20:32:13 +0000

The whole thing is peak choosing beggar territory. "Excuse me, in order for you to give me your labour for free, here is the additional work that I demand you do so I can make money off free labour."

Villa: Setting new expectations for open source maintainers

NYKevin — Sat, 21 Aug 2021 18:10:28 +0000

Look, if you want to go in front of a judge and explain that NinjaRobotCoder43 wrote this code, and that's actually a real person and not somebody you just made up one day, then that's your lookout. But it's plausible that some lawyers might be a bit nervous about the soundness of that strategy.

Villa: Setting new expectations for open source maintainers

Wol — Sat, 21 Aug 2021 16:24:35 +0000

Plus how do you subpoena someone in another jurisdiction? You can *try*, but especially in civil suits there's little chance of success ...

Cheers,
Wol

Villa: Setting new expectations for open source maintainers

sfeam — Sat, 21 Aug 2021 15:33:20 +0000

Copyright defense does not normally depend on issuing a subpoena to the original author. Otherwise it could never extend beyond death. And if the claim of infringement is based on fake "prior" document, again that is a scenario that exists regardless of the name on the legitimate code.

Villa: Setting new expectations for open source maintainers

NYKevin — Sat, 21 Aug 2021 15:25:04 +0000

> If someone claims copyright infringement, the burden is on them to point to an earlier copy attributed to someone else.

So they manufacture a fake Git history.

> If they can do that, BigCompany has a problem regardless of who Sam is/was.

If we know who Sam was, then we can subpoena Sam and force them to come in and give a deposition about how they wrote the code. The fact that we have the ability to do this means that the lawsuit won't get that far in the first place, because the plaintiff doesn't want to get busted for perjury, so in practice Sam doesn't actually have to come in.

But if Sam is pseudonymous and we cannot identify them, then it's just our word against the plaintiff's; one Git history against another. Who knows which one is real?

Villa: Setting new expectations for open source maintainers

sjj — Sat, 21 Aug 2021 15:23:01 +0000

This is a sad and terrible state of affairs. A real badge of shame for the kernel community that this is still something people have to do.

Villa: Setting new expectations for open source maintainers

atnot — Sat, 21 Aug 2021 12:41:12 +0000

I know multiple kernel developers who submit primarily under false male identities to prevent discrimination and increase the chances of their patches being accepted

Villa: Setting new expectations for open source maintainers

pizza — Sat, 21 Aug 2021 12:05:47 +0000

> So what exactly is changed by the use of a pseudonym?

Having a defined policy, and faithfully following it, is the primary corporate defense against accusations of malfeasance.

"We followed our own policy; we can't help it if someone else [1] lied; go after them instead."

[1] eg "one of our suppliers" or "unrelated third party that we have no relationship with"

Villa: Setting new expectations for open source maintainers

sfeam — Sat, 21 Aug 2021 06:29:34 +0000

I am not following argument (1). If BigCompany has code submitted and attributed to SamSomebody with a commit date, how is it relevant what SamSomebody's other identities may be? If someone claims copyright infringement, the burden is on them to point to an earlier copy attributed to someone else. If they can do that, BigCompany has a problem regardless of who Sam is/was. Or are you positing that "Sam" was a bad actor who poisoned their own contribution by pre-publishing under another name? But a bad actor could do exactly the same thing by having a confederate do the pre-publishing and then contributing it also to BigCompany under their own name. So what exactly is changed by the use of a pseudonym?

Villa: Setting new expectations for open source maintainers

NYKevin — Sat, 21 Aug 2021 05:54:28 +0000

The concern is that:

1. If we (some big company) don't know who the developer is, and then someone appears and sues us for copyright infringement, we have no way of proving that the plaintiff is full of shit. In that case, it would be cheaper to settle than to try and litigate, so we just don't want to end up in that situation in the first place.
2. If the developer's copyright license is not clearly and unambiguously recorded, with their legal name etc., then heirs and successors might try to argue that the license is invalid or even fake (i.e. that the developer never actually agreed to it, and somebody else forged the Git history). Who knows what happens next?

Disclaimer: I work for Google, which does both develop and make use of quite a lot of open source code, but I don't know their position on developer ID in particular. The "we" above refers to a hypothetical generic corporation and is not specific to Google.

Villa: Setting new expectations for open source maintainers

Cyberax — Sat, 21 Aug 2021 03:20:20 +0000

Linux kernel has been requiring it since forever.

Villa: Setting new expectations for open source maintainers

pabs — Sat, 21 Aug 2021 02:20:02 +0000

The developer identity requirement is simply unacceptable.

Villa: Setting new expectations for open source maintainers

gray_-_wolf — Fri, 20 Aug 2021 22:37:36 +0000

I wonder how that would look in actually useable format. I can very well just borrow a function from BSD-licensed package, so even file granularity might not be enough. I guess byte ranges for each file for each license? However not sure how to maintain such a database. Would probably need to integrate with git somehow.

Villa: Setting new expectations for open source maintainers

NYKevin — Fri, 20 Aug 2021 22:37:30 +0000

The article refers to "metadata," which certainly does not include the actual text of the file itself.

Villa: Setting new expectations for open source maintainers

IanKelling — Fri, 20 Aug 2021 18:20:06 +0000

> That quote is not about whether or not you have the text of the license, in human-readable format, in a comment at the top of each file.

No, but I wasn't talking about that either.

> Instead, it's about whether or not your packaging solution

That section of the article clearly does not refer to any kind of "packaging solution", it was definitely talking about license headers. GNU recommends a license header on each file, not "the license text." The article mentions another form of license header, SPDX. Both are machine readable, although SPDX is easier to read.

Villa: Setting new expectations for open source maintainers

DrMcCoy — Fri, 20 Aug 2021 17:28:19 +0000

Debian, however, does exactly that with its copyright file, no?

Villa: Setting new expectations for open source maintainers

NYKevin — Fri, 20 Aug 2021 17:13:47 +0000

That quote is not about whether or not you have the text of the license, in human-readable format, in a comment at the top of each file. Instead, it's about whether or not your packaging solution (or wherever your metadata lives) describes, correctly and in a machine-readable format, the license which applies to each individual file. It's a completely different problem altogether, and one which much of the open source world has long ignored (e.g. if you borrow code from a BSD thing and add it to a GPL thing, you just label the whole package as GPL and go on your merry way, you don't try to convince the packaging system that your package is mixed-GPL-and-BSD).

Villa: Setting new expectations for open source maintainers

IanKelling — Fri, 20 Aug 2021 15:37:39 +0000

From the article:

> Traditionally, open source communities like GNU, Debian, and Fedora believed (with good reason) that the default level of mandatory licensing metadata was at the package level, with per-file licensing information often disfavored at best and unrepresentable at worst.

No, GNU has always recommended per file licensing data: https://www.gnu.org/licenses/gpl-howto.en.html . And of course GNU does not call itself or want to be considered an open source community, but a free software community.