Keep the maintainers in mind [LWN.net]

Keep the maintainers in mind

Posted Sep 16, 2021 7:53 UTC (Thu) by ncm (guest, #165)
In reply to: Keep the maintainers in mind by NYKevin
Parent article: SPDX Becomes Internationally Recognized Standard for Software Bill of Materials

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.

to post comments

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