license field needs more guidance

[regongithub]

Some datasets are copyrighted -- can't address that in current field or point to specific license guidance via URL.

[gbinal]

Agreed. In particular, in the 'Further Metadata Field Guidance,' material for 'accepted values, usage notes, and example. @benbalter @waldoj - any thoughts?

[waldoj]

Huh. Funny that we hadn't considered this previously. I'm reminded of the town I lived in as a kid, a planned community near D.C. Famously, the Rouse Brothers, who planned the community, didn't include any cemeteries. It hadn't occurred to them that people would die.

Even our example for this isn't good. {"license":""} isn't an example, it's a non-example. {"license":"CC-BY-SA"} is a reasonable example. I recall discussion as to whether we wanted people to name the license here, or provide a URL linking to the license, but I can't see in the documentation what we settled on.

If this is a URL then it seems like we'd want to point to the terms of use. I mean, if the data is actually copyrighted, period, then presumably it wouldn't be on an API. There must be some terms of uses, a license under which people can use that data, even if it's not a license in the cookie-cutter sense like Apache, GPL, MIT, Creative Commons, etc. It seems to me that we wouldn't want agencies sharing copyrighted data via an API that has no license allowing it to be reused.

And if this is a text field, then I imagine we just need to agree on and document a string (e.g., copyrighted) that covers this. Of course, "copyrighted" isn't a license at all, so I'm not actually proposing using that.

[gbinal]

Taking a page from CKAN, we've actually been leaning towards text box for name of license. Given the pros and cons both ways, my suggestion is to clarify in the instructions that it's a text field where the provider can write in the license or paste a URL instead. I imagine that seems heretically open to some but any thoughts on if there's another path that is a clear consensus winner that we should adopt instead? @konklone, @JoshData - any thoughts?

[konklone]

If you really have to stick with just one field, then a URL seems like the right thing to ask for. You could also split it out into license_url, license_name, and license_text fields, where at least one of them needs to be filled out. It really just depends what balance of expressiveness versus maintenance POD wants.

[JoshData]

I think in the August meeting we said we'd provide (a link to?) some non-exhaustive list of possible values.

Since @waldoj mentioned "terms of use" generally, I had a bit of pause before replying. What if the terms are "by downloading this data you agree to quack like a duck"? If we allow arbitrary terms, we should not include an accessURL for the dataset. If an agency wants to create a click-wrap style agreement, they should be responsible for ensuring that the user actually agrees before getting the data. Because otherwise, who's really going to view the license page to see what they are agreeing to?

IANAL but this seems to differ from a copyright license agreement (or a public domain dedication). In these cases no terms apply until the user makes a copy. (Let's assume that the act of downloading doesn't constitute making a copy.) There are no terms just to download/view/analyze.

So I guess what I'm saying is, the guidance should be specific about this. You can point to a URL containing a copyright license agreement.

[haleyvandyck]

Thanks everyone for the helpful discussion. Sorry for the gap in the guidance here and the accidental "non-example." 😳 Seems that there is a relative consensus forming around the URL approach, which I would agree with. @waldoj, care to do a pass at pull request clarifying this in the further metadata field guidance? Thanks!

[waldoj]

For starters, I don't see any way around that this needs to be a URL. Licenses must be unambiguous, and anything short of an actual copy of the license (or, rather, a pointer to where it can be found) is ambiguous.

CC-BY-SA, the example that I used previously, is Exhibit A for why we need a URL—version 4.0 of the Creative Commons license came out a week or so ago. Which version is that CC-BY-SA refers to? Because they're all different.

The downside of a URL is that it makes it more difficult for machine recognition of the license that's in use. That is, "GPL" is an easily recognized string, if ambiguous. But most major licenses have canonical locations. GPL 2.0? Link to http://www.gnu.org/licenses/old-licenses/gpl-2.0.html. Apache 2.0? Link to http://www.apache.org/licenses/LICENSE-2.0.html. Etc. So I think the problem of machine-readability is well addressed by encouraging the use of canonical license URLs.

[waldoj]

If we accept that we need to use URLs, then that solves the issue raised by this ticket, because a copyrighted dataset can have a URL that points to the actual license. (Of course, this necessitates that the license be available online, but that's going to be functionally true no matter what—simply writing "copyrighted" in this field, if we didn't allow URLs, would raise many questions but answer none, making the data useless to people.) But it does raise a new problem of what's to be done with work that has no license—that is, it's in the public domain. What is the canonical URL for that? Should the field be defined but left blank (the embodiment of a non-license), or is that in practice going to be ambiguous (I think so)?

Would it be inappropriate to encourage that non-standard licenses (i.e., copyrighted datasets) be marked up with Creative Commons Rights Expression Language RDF? That would make it possible to harvest license data that would otherwise be a black box.

If anybody has any feelings about any of the points I've raised in this pair of comments, please don't be shy. Otherwise, after I let this sit for a couple of weeks, I'm inclined to start filing pull requests to act on some of these ideas, and I want to make sure that every perspective has had a fair airing first.

[raking08]

Hello I am new to this discussion as I just started supporting the CDC in this effort; however I come from a pretty deep private sector data governance / data quality background so tend to view through that lens. My comment is that a blank itself is ambiguous. a blank really means that the field has not been populated with a value. That might be because the data was evaluated and there is no license ( as in common rights) but more often will mean that the data steward did not populate that field (Didn't know, wasn't available at time, the URL moved...) As I have looked at the available data from the three main open data sites I am seeing this blank more often than not.
So I would recommend the URL be used of course, but also I think there should be commonly defined terms for the Creative rights, "not applicable", unknown... so that its clean that a blank means simply not populated. The its possible to query the metadataset for blanks and send to the data stewards for the correct population. They may still populate with unknown, but at least you can get them to own that decision. We have about 400 data stewards, so managing this set for quality on an ongoing basis, but just when initially created) is a challenge.
Thoughts?

[JoshData]

Agreed with @raking08.

CCREL is interesting but.... I think we'd need to write more guidance on how to actually do that. It's something that I think would appear on the target URL and not in the data.json file itself, so we could add that suggestion later on too without affecting the POD schema too.

Back to @waldoj's question about non-licensed federal government data. We usually talk about this data as being in the public domain, but it's only in the domestic public domain. Calling it a 17 USC § 105 exemption would be more accurate. So I think we have two options:

1. Have one special case where the value of the field is not a URL, e.g. exempt_by_17USC105
2. Make up a URL to use in this special case, e.g. tag:whitehouse.gov,2013-12-04:ostp/pod/copyright-status/exempt_by_17USC105

I'm agnostic between the choices. I have a feeling @gbinal would find the first easier to have implemented?

[konklone]

Project Open Data could also make a URL whose sole purpose is to describe the state of non-licensed federal government data -- http://project-open-data.github.io/us-data-license or something. It could just contain the text of 17 USC 105, with a human readable description accompanying it, and a more attractive/readable presentation than others I could find.

Even separately from improving the data.json schema, this would be a nice permalink for the country to have.

[JoshData]

I'd be a little hesitant to coin URLs on a github domain though.

[waldoj]

Agreed, Josh.

[konklone]

That is exactly what inspired me to file #216!