[od-discuss] SPDX license taxonomy

Wed Jun 18 20:20:56 UTC 2014

On 06/18/2014 02:17 AM, Andrew Katz wrote:
> Mike
> 
> <snip>
>>
>> AFAIK their 2.0 won't change how they see licenses at all; the finer grained
>> thing is how they model licensed material, at least that's what I gather from a
>> recent slide deck
>> https://lists.spdx.org/pipermail/spdx/attachments/20140402/0e357fce/attachm
>> ent-0001.pdf
> 
> Yes, that's what I understood from talking to Jilayne Lovejoy.
> 
>> In any case we're initially only interested in their repository of license texts. If
>> some additional collaboration with them on license metadata (beyond naming
>> implied by file names in their repo) turns out to be useful, that'd be fine too.
> 
> Agreed. I was more concerned that we kept our taxonomies of licences compatible, so that if we came across a new licence, we could agree between us what code name to give it. What I don't yet know is how techniques for recording modular licence options might develop - at the moment, for example, the CC list of licences is given different names depending on the options selected, but I can see at some point that the options might themselves be standardised. This would enable the additional permissions under of GPL3 to recognised, for example.
> 
> This is not something to worry about now, but is something I'd like to keep an eye on. I'm interested in how SPDX might develop anyway, so I may have a chat with Jilayne, and report back if I find out anything interesting.
> 
> 
>> Let me know if I'm missing something.
> 
> Not at all 

I did miss (by glossing over "taxonomy") that you were concerned about
naming. I'm completely for using their naming, and naming they'd
probably come up with for licenses not in their list, previously:
<https://lists.okfn.org/pipermail/od-discuss/2013-June/000504.html>.
Treating them as an upstream for license texts just makes doing so more
compelling.

Also I like their fine grained naming (eg of GPL with or without later
versions or widely used exceptions). I don't know that there's a need
for that with any licenses this group is likely to engage with, but
there could be. I suppose a historical (somewhat wishful thinking :))
example would be FDL, for which they don't separately identify
with/without non-open options, but maybe ought to.

Mike