Technical advisory board

Posted Sep 11, 2021 18:52 UTC (Sat) by corbet (editor, #1)
In reply to: SPDX Becomes Internationally Recognized Standard for Software Bill of Materials by jebba
Parent article: SPDX Becomes Internationally Recognized Standard for Software Bill of Materials

Note that, if you are unhappy with the membership of the LF Technical Advisory Board, there is an election for TAB members underway right now. This would be the time to put in your nomination, or to convince somebody you would support to put in theirs.

Technical advisory board

Posted Sep 11, 2021 19:45 UTC (Sat) by atai (subscriber, #10977) [Link]

Honestly speaking, that is not the board itself, which makes the decisions.

Technical advisory board

Posted Sep 12, 2021 9:25 UTC (Sun) by mfuzzey (subscriber, #57966) [Link] (5 responses)

I don't *think* the TAB is the issue here.

Does the TAB get involved in decisions like the one to submit SPDX to ISO (which has policies concerning the availability of their standards that are questionable at best and open source hostile at worst).

I suspect not, though I may be wrong, as it's hardly a "technical" decision (nor a CoC related thing where the TAB also seems to be involved).

Seeing as ISO apparently can set standard specific rules (someone mentionned the ISO ADA standard bring free) I think the LF should have at least made free availability a precondition for submitting SPDX.

Technical advisory board

Posted Sep 18, 2021 14:29 UTC (Sat) by jschrod (subscriber, #1646) [Link] (4 responses)

????

The SPDX standard text is freely available, just like the Ada one - what is your qualm?

The real issue with SPDX is the demand on non-corporate developers to maintain such declarations for the sake of large companies who want to exploit their work without paying for it. Publication as an ISO standard has nothing to do with it.

Technical advisory board

Posted Sep 18, 2021 22:04 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

The real issue with SPDX is the demand on non-corporate developers to maintain such declarations for the sake of large companies who want to exploit their work without paying for it.

Presumably if a large company wants to use the work of a non-corporate developer without paying and the only thing in their way is the lack of SPDX information, the least they could do is contribute a set of accurate SPDX headers to that project.

Technical advisory board

Posted Sep 18, 2021 22:59 UTC (Sat) by jschrod (subscriber, #1646) [Link] (2 responses)

Yes, but only if they are part of the developer community. Otherwise, the onus of maintaining that information remains at the project - and there the ROI is often questionable. IMHO, of course.

Technical advisory board

Posted Sep 19, 2021 13:27 UTC (Sun) by madscientist (subscriber, #16861) [Link] (1 responses)

I don't see why it should be the responsibility of the project. If something is wrong about the SPDX do users of the project see bugs? Do regression tests fail? If someone who cares about SPDX sees that something is not right, then can supply a patch to fix it. If users of the project are relying on the SPDX content without verifying it themselves and it's wrong, that's a problem for those users who need SPDX.

There is some minimal amount of effort for the project to verify the SPDX patch is correct and apply it but I don't think projects should spend any more time on it than that bare minimum, unless they WANT to do so... in which case it's by definition not a waste of time, for them.

Technical advisory board

Posted Sep 19, 2021 14:22 UTC (Sun) by pizza (subscriber, #46) [Link]

> There is some minimal amount of effort for the project to verify the SPDX patch is correct and apply it but I don't think projects should spend any more time on it than that bare minimum, unless they WANT to do so... in which case it's by definition not a waste of time, for them.

SPDX is a pretty poor example, honestly. It's nearly entirely a one-off cost, and even that's not likely to be all that large. It took under an hour for me to add SPDX headers to a modest 30KLOC (across ~30 files) project that I maintain, and that's mainly because I wrote a script to do it instead of editing each file manually. Going forward, it's zero additional effort to maintain -- Adding it to a new file is trivial when you consider that I already need to ensure the new file has a proper copyright header in it, which in turn is just cut-n-pasted from another file.

Now the other stuff that corporate types want, such as certifications, security processes, testing frameworks, CI systems, maintained "stable" branches, documentation, and unliminted hand-holding represents both upfront and ongoing effort. But SPDX isn't one of those.