Restore licenses for dual-licensing.

[yetzt]

I request 34f9ce8 and 5443780 will be undone. I am having dual-licensed open data (odbl and cc-by) that has to be dual licensed so the data can be used as an upstream by different project with different licensing requirements. Your argument that noone will possibly ever use more than one license for the same set of data is therefore invalid.

[rufuspollock]

First thanks for flagging - its great to get this feedback. Two thoughts;

• That change probably wasn't quite right and we should think about realigning multiple values for license.
• But: irrespective of when that comes in I would suggest the solution right now is just to put one license in the metadata datapackage.json but to have a license section in your README that spells out the situation. Remember the datapackage.json is never legally binding - it is just indicative and full details are usually somewhere else. See esp http://data.okfn.org/doc/publish-faq#-strong-license-strong-

[yetzt]

i recommend you have a look at this issue from npm on a similar topic, so no mistakes shall be repeated. one point of strong metadata is automatintion. i like the idea of software to take care of things like making sure that incompatible licensed data is not mixed. having only one license in the metadata would lead to a 'false positive' incompatibility and hurt the approach of open data. my personal fix is to stick to the penultimate version of the spec.

[pwalsh]

@rgrp what do you think about reinstating this?

[roll]

also related to #146

[rufuspollock]

@pwalsh yes agreed on reinstating. Need to action this now.

[danfowler]

Can I assume that we will have both license and licenses where license can be a string or an object and licenses will be an array of such values?

@frictionlessdata/specs-working-group

[roll]

It's kinda against currently used pattern - why not license either string or array of strings/objects?

[danfowler]

@roll

license can be an object also:

"license": {
    "type": "ODC-PDDL-1.0",
    "url": "http://opendatacommons.org/licenses/pddl/"
  }

The pattern would match author (string or object) and contributors (array of author-like values)

[rufuspollock]

I'm wondering if we should adopt npm / package.json approach for multiple licenses which is:

(ODC-PDDL-1.0 OR CC-ZERO)

See https://docs.npmjs.com/files/package.json#license

[yetzt]

@rgrp the npm approach has some problems. they rely on spdx, which doesn't cover most open data licenses (only a subset of the open definition ones), and their fallback is "SEE LICENSE IN $FILENAME", which defies the purpose of machine-readability. also there's "UNLICENSE" and "UNLICENSED" which mean two diametral things. so please: don't. or: replace spdx with an open and inclusive repository of licenses. and if you want to notch up the awesome on this: also account for versions and flavours of licenses and their compatibilities. (build a basic platform, put the opendefinition licenses in and let the general public fill it)

[rufuspollock]

@yetzt good points and going to do that.

Re licenses repository see also https://github.com/okfn/licenses

[rufuspollock]

Proposal:

• license is the term (if people feel strongly on licenses please say - after all this is partly breaking change anyway!)
• Can have one or multiple values
• Simple default of a string

"license": "{ID-taken-from-open-definition-licenses-list}"

# a license with an explicit url
# NOTE: type can be "notspecified" 
# NOTE: you must have an array of objects even if only one object
"license": [{
  "type": "ID-taken-from-open-definition-licenses-list"
  "path": "http://xxx.yyy.com/LICENSE.md"
}]

Multiple licenses:

"license": [
   {
     "type": "ODC-PDDL-1.0",
    "path": "http://opendatacommons.org/licenses/pddl/"
  },
  {
    "type": "ID-taken-from-open-definition-licenses-list"
    "path": "http://xxx.yyy.com/LICENSE.md"
  }
]

Example where your own custom license locally:

"license": {
  "type": "other"
  "path": "LICENSE.md"
}

[jpmckinney]

My preference is for the simple string version to be a URL. A URL is an identifier.

The docs seem to have had id where the proposal now uses type. type would make sense if we allow values like other and notspecified, which don't identify a license, but describe its type.

That said, I personally find "licenses" like other-pd to be confusing, because they aren't licenses! I've seen data catalogs "license" their data under other-pd, but that is not a valid license!

My preference is to drop id / type and just use URLs to licenses, which are unambiguous. Either that, or remove all non-licenses from okfn/licenses to avoid the above issue.

The proposal uses both url and path. I thought we had collapsed those to a single term?

[rufuspollock]

@jpmckinney thanks for the review:

My preference is for the simple string version to be a URL. A URL is an identifier.

I hear you. However, for combination of publisher simplicity and compatibility it is unlikely for plain string to switch to being a url. The simple string value covers 80% of the use cases and save you having to find a url (which may change etc). In addition, the url option is supported in the object structure.

The docs seem to have had id where the proposal now uses type. type would make sense if we allow values like other and notspecified, which don't identify a license, but describe its type.

Current spec has type i believe not id.

That said, I personally find "licenses" like other-pd to be confusing, because they aren't licenses! I've seen data catalogs "license" their data under other-pd, but that is not a valid license!

Good question. Definitely possible to drop those "license group" rather than specific license items in licenses list. However, there are benefits in some cases. This seems a non-blocker for this change.

The proposal uses both url and path. I thought we had collapsed those to a single term?

You spotted a bug there. Does raise the question: why not just url. Only reason for path was idea of having local paths to a license file in the package. Is that useful to have?

[pwalsh]

@rufuspollock

• I prefer licenses to license (as per your request in Restore licenses for dual-licensing. #236 (comment))
• I agree with @jpmckinney on URIs for licenses, and it should be called path, being a URL or a file path.
• Tools building on the spec can use https://github.com/okfn/licenses but I don't think we should build a dependency into the specs on a single web service that OKI runs.

Still, one would like to be able to extract a name for a license, without parsing the URI (or the contents of the file found at the URI). So I do think we still need type/id as well as path. This does open things up for error though.

[rufuspollock]

@pwalsh can you clarify on point 2. IME as a user simply being able to put an id like "ODC-PDDL-1.0" is a real advantage. Looking up an authoritative URL is a PITA.

[jpmckinney]

Isn't it similar to looking up a canonical ID like "ODC-PDDL-1.0"? That ID is not obvious. Sent from mobile

…

On Dec 18, 2016, at 11:49 AM, Rufus Pollock ***@***.***> wrote: @pwalsh can you clarify on point 2. IME as a user simply being able to put an id like "ODC-PDDL-1.0" is a real advantage. Looking up an authoritative URL is a PITA. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rufuspollock]

@jpmckinney it is a good point and only people like me maybe know some of those license ids by heart 😜

@pwalsh long and short i'm coming down to view that we should have less "optionality" in the "strong" vs object stuff. Will open a general issue about this in a moment.

[rufuspollock]

AGREED:

• licenses - plural
• licenses is an array of objects
• at least one of name, path or title is present.

"licenses": [{
  # was type - optional
  "name": "identifier from our list"
  # was url
  "path": ""
  "title": "any string you want"
}]

[pwalsh]

in 2b575e6

[pwalsh]

We won't merge #337 until we can support all the changes in the core implementations we maintain. So closing this as it is implemented in #337 , as leaving it open creates confusion.