Keep the maintainers in mind [LWN.net]

Keep the maintainers in mind

Posted Sep 12, 2021 18:27 UTC (Sun) by halla (subscriber, #14185)
In reply to: Keep the maintainers in mind by mirabilos
Parent article: SPDX Becomes Internationally Recognized Standard for Software Bill of Materials

Yes... That's what I was thinking, too. Only recently, someone went to all the trouble to create patches for Krita to replace all the headers with this stuff. Hours of work. I spent time reviewing it. Then I spent time fixing fall-out. Then I spent time asking our contributors to follow this... And in the end, is there anyone who wants to paint a bit in Krita a bit better off for all this?

Nope.

And since there is no corporate sponsorship, we've been paying for this with our own time, eating into the time we could have spent fixing bugs.

Keep the maintainers in mind

Posted Sep 13, 2021 5:17 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (6 responses)

But why did you even do it then?

What advantage does making this chance brings?

(I'm honestly asking, not being sarcastic)

Keep the maintainers in mind

Posted Sep 16, 2021 2:54 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (5 responses)

As someone on the corp side, I am curious about this myself. How did my great grandboss (and their friends) convince all of these people to do all of this work for free, when it basically only benefits giant corporations and governments? I wish I could get free stuff just by asking nicely...

Keep the maintainers in mind

Posted Sep 16, 2021 7:53 UTC (Thu) by ncm (guest, #165) [Link] (4 responses)

Typically committee members are sent by the corporations interested in the resulting Standard, and are thus paid.

Depending on circumstance, they may vote (1) their own opinion; often (2) the collective opinion of a company committee; sometimes (3) the collective opinion of a National Body representing a government (often a committee made up of designated experts chosen however that government likes, and deciding how the government likes, often by internal vote); and sometimes (4) as directed by management not interested in their opinion.

Standards are made by a process resembling that for sausage. Quality varies according to how much of it participants are willing to pay for.

Keep the maintainers in mind

Posted Sep 16, 2021 10:00 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (3 responses)

Ok it's a standard but… so what?

Why do unpaid open source developers care to implement a standard that helps giant companies reuse their code without wasting time to read the license?

I guess there is some advantage to using the standard in an open source project? But what's the advantage? I don't know… thus my question.

Keep the maintainers in mind

Posted Sep 16, 2021 11:45 UTC (Thu) by ncm (guest, #165) [Link] (1 responses)

Standards have one main purpose: interoperability.

Sometimes equipment interaction, or substitutibility. Often, education, or interaction with your and others' brains. Often, quality, because international standards get a great deal more attention than things thrown together on the spot.

They are often used just to make contracts shorter and easier to negotiate.

Keep the maintainers in mind

Posted Sep 17, 2021 9:01 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

I don't feel like this answers my question at all. We were talking about a precise specific case, not about standards in general.

Keep the maintainers in mind

Posted Jan 11, 2022 15:39 UTC (Tue) by rpavlik (guest, #125331) [Link]

Makes packaging for e.g. Debian much easier, and makes the maintainers feel better that all their licensing ducks are in a row. Also makes it easy to make sure incoming commits have proper copyright/license if you use something like https://reuse.software/ (which is basically "enforceable spdx headers, with tooling") because you can have a CI job checking it, etc.

Particularly useful if you e.g. publish a standard with open source parts, you can make sure even the internal repo is properly annotated and won't give you headaches at release time. (From experience here - as part of my job, I do spec editing on a Khronos standard, as well as working on open source software)

I'd also say that having a standard license tag at the top of every file, instead of just a license file for the whole repo, helps avoid "there was no license so I copied the code" thing, which is of course wrong but doesn't mean it's not done.

Also helps me re-use the little "ancilliary" files that often get ignored for copyright/license headers, like scripts, CI configs, etc...