LWN: Comments on "A SPDX case study"

A SPDX case study

dps — 2013-09-30T16:05:21+00:00

Working for a company that distributes boxes which aggregate OSS and definitely not OSS software the ability to track what licences apply to which bit of which package would be worth a lot.

Sometime we either don't have the source code or can't get it under a licence that would allow us to redistribute the source code. Some of the other code is hazardous to mental health or part of our secret sauce (and sometimes both).

A SPDX case study

HIGHGuY — 2013-09-26T18:48:57+00:00

Working for another large company that deals with OSS I recognize the problems faced.
Our company also has a large database that one uploads source code into for license review and that aids the process of verification and license obligation compliance.

For our team, using the tool at first generated a lot of work.
Currently we source 2 different Linux distributions and maintaining all of this information throughout regular package updates and other maintenance is quite a burden.
That is why we further automated the process for our team, going from 2-3 manweeks of work per release, down to 2-3 mandays of work per release. Further tuning can probably bring this down to 1-2 mandays.

For any large company dealing with OSS products, such automation is golden.

There are additional benefits to be found in maintaining such a database like providing teams with security alerts or merely forming an internal community around certain packages, promoting reuse and stimulating communication.

A SPDX case study

dvdeug — 2013-09-26T16:50:40+00:00

If your supplier sends a SPDX, and you produce a significantly different one, that's a good sign that someone needs to manually go over the package. They may find things that would elude an automatic search.