Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
I’m admittedly a bit late to this party despite having a few thoughts on the topic. This thread has quite a few aspects to it, starting with Jeff’s initial proposal, so I’ll try to hit all of them, even though the whole thread is not below.
First of all, I am noticing some energy around being able to add more licenses to the SPDX License List and to do so more easily. Jeff encapsulated this concept quite succinctly with the initial conclusion to his email which was:
He is not the only person to express a similar sentiment.
By way of review for those not intimately involved, the general highlights of the process to add a license include:
We aim to do releases on a quarterly basis. I’d say that after the big push to add Fedora licenses a few years back, we probably average less than 10 new licenses/exceptions per release.
We have some tooling, thanks to various GSoC projects (and Gary!) that has helped in making the process cleaner. But at the end of the day, the reality is that EVERYONE who works on this project is a volunteer and it is a very small number of people actually doing this work.
At the same time, I have noticed a trend that the people asking for more licenses, faster process, etc. are generally not engaged in the project in any significant way or helping to that end. Not to pick on Jeff in particular - but I have not seen a new license submission by anyone at Microsoft (that I know of) and I had to approve Jeff’s email to go to the legal team (not on list :). As SPDX gets used more and since we moved to using the Github repo, we also now have started seeing “drive-by” license submissions in the repo. I’m sure other open source projects experience this kind of thing, but I don’t really have experience as to how this is best dealt with: in other words, how do we get more people engaged and more hands-on-deck on a consistent basis? Because if we go back to the original question of being able to add more licenses, more quickly - we must have more resources in order to do so.
Another issue, I think Philippe touched upon related to Jeff’s proposal for a fingerprint algorithm and the challenges in matching licenses where there are small differences - this is a key part of what the SPDX legal team does in #2 above: if we have two licenses that are similar, but not exactly the same, we have a team of lawyers looking at the differences and making a determination as to whether those differences are legally substantive or not: if not, then we accommodate with matching markup (if possible); if they make a legally substantive difference, then we add as a separate license. For obvious reasons, we are very conservative in this determination. But in any case, that is not a step that is going to automat-able.
Finally - my biggest concern about some kind of registry for licenses that are not on the SPDX license list for the purpose of getting an SPDX id, is that people will just do that instead of submitting licenses to be on the SPDX License List and that trying to track this other list and pull licenses into the SPDX License List where appropriate (as per Philippe’s revised proposal) will just create more work for an already too-small and over-stretched team. In other words, it feels like not a solution, but a diversion from a bigger question (make it easier to add more licenses?) and bigger issue (need for more resources).
I hope to discuss the bigger question on the upcoming legal call.