Public Domain & Licensing - Open and Iterative Policy Development #317

Open
wants to merge 2 commits into
from

Projects

None yet
@haleyvandyck
Contributor

After healthy discussion with the community here on Project Open Data and through events like the Open License Data Jam, the White House is proposing edits to M-13-13 Open Data Policy to help clarify the intention of the Open License section and address concerns raised about the lack of reference to public domain.

This is the first pull request proposing changes to the policy document itself, and before merging we want to feedback on the language to ensure it sufficiently addresses the concerns mentioned. Let us know if there are ways we could further improve this language!

Thanks again to everyone who has participated in these open license discussions to date--it genuinely has helped us improve the quality of our guidance, and we appreciate your time and thoughtfulness.

haleyvandyck added some commits May 19, 2014
@haleyvandyck haleyvandyck Update policy-memo.md
Proposed policy language edits to clarify the open license requirements in the open data policy.
3d03411
@haleyvandyck haleyvandyck Update policy-memo.md
updated language
4d448b9
@haleyvandyck
Contributor

Also-- heads up, another pull request coming shortly on clarification to the other open license related files in this repo...

@waldoj
waldoj commented May 29, 2014

๐Ÿ‘

@waldoj
waldoj commented May 29, 2014

Really, this is a great modification, the result of community-raised concerns. The actual amount of text being changed is small, but the impact is potentially quite large.

@parkr
parkr commented May 29, 2014

This is great!

In some circumstances, information is acquired or accessed by an agency through an independent contractor. This requires that appropriate existing clauses [^22] be utilized to meet open data objectives, for example, by requiring the contractor to apply an open license to data created or modified under the contract, while recognizing that protection of proprietary interests in data may in certain cases be necessary to encourage qualified contractors to participate in and apply innovative concepts to government programs.

Does the public have a right to know whether "protection of proprietary interests" has been applied? Additionally, what constitutes "proprietary interests"? Is it, perhaps, code to generate the data? When, if ever, is it acceptable for a contractor to withhold data under this clause?

@feomike
Contributor
feomike commented May 29, 2014

๐Ÿ‘

@NoahKunin

๐Ÿ‘

@gbinal
Contributor
gbinal commented May 30, 2014

๐Ÿ‘

@benbalter
Contributor

The Federal government does not take copyright in works prepared by its employees as part of their official duties.

  1. "take" may not be the best word here, as one does not "take" copyright (e.g., there's no affirmative step). Copyright automatically vests in an author at the time of publication. The issue here is that a US Government Work is excluded from the definition of copywritable works under 17 USC ยง 105.
  2. Under my reading, the 17 USC ยง 105 exclusion applies solely to domestic copyright. What happens if a foreign citizen (or foreign nation) seeks to consume information published by the US Government? At least in terms of code, the general consensus seems to be an explicit CC-0 disclaimer of copyright which would remove any ambiguity about the work's public-domain status both domestically and abroad (and is a "license" geeks know and trust, further lowering the barrier to consumption).

...but IANYL, so you should check with White House counsel on both fronts.

@sbma44
sbma44 commented Jun 2, 2014

"for non-commercial or for commercial purposes" maybe just "for any purpose not otherwise prohibited by law" -- though this does make me wonder about the appropriate way to relate to things like the FEC's prohibition on use of campaign finance disclosure records for commercial solicitations. I'd hate to open the door to the larger universe of ill-advised revenue-seeking noncommercial clauses, but there are some obvious use cases that should be prohibited, and which might not explicitly prohibited by law.

@JoshData
Contributor
JoshData commented Jun 2, 2014

๐Ÿ‘Ž

I have a number of concerns which I will post later today, hopefully.

@JoshData
Contributor
JoshData commented Jun 2, 2014

On the up side:

  • Mentioning the public domain here does serve to clarify that no action need be taken by agencies for USG works in order for those works to be open (at least with respect to domestic copyright), and that it would be incorrect to apply an open license to those works, which were some of the original concerns.

But the phrasing isn't so great:

  • I agree with @benbalter's points. For clarity the term "domestic copyright" should probably be used.
  • Additionally, not all USG works are exempt from copyright by 17 USC 105. See 15 USC 290e. So the new first sentence is probably a little incorrect for being overly broad.

And additionally this pull request doesn't address many of the issues we've discussed:

  1. "Openly licensed" and "no restrictions" mean two different things, and so the paragraph remains, well, incoherent.
  2. Footnote 21 about attribution seems to indicate that attribution requirements are permitted (contra "no restrictions").
  3. "Appropriate existing clauses" in the FAR may not exist. For instance, FAR 27.404-3(a)(4) does not appear to give the government the right to re-license works produced in the performance of a contract. If appropriate clauses do exist, it would be great to point to them in use when discussing the issue instead of referring to them obliquely.
  4. Original government works and works by a contractor should be license-free. That is, copyright should be waived or, when that is not possible, an equivalent public license should be used instead. Attribution requirements are not acceptable. Civil liabilities created in exchange for access or use are not acceptable. Waiving copyright is different from the usual meaning of open licensing.
  5. On top of achieving a certain copyright status for works, it is important that the status be clear to users. It is incumbent on an agency to attempt to determine the intellectual property status of any work it publishes and to mark data (with a notice) indicating its status.
  6. The paragraph does not address the prevalence of terms of use agreements attached to government data which may undermine any openness with respect to copyright. We have also discussed quasi-legal fear-inducing language attached to data, such as "use is permitted for any lawful purpose," which should be avoided.
  7. Although 17 USC 105 exempts USG works from copyright, the statute refers to domestic copyright and not foreign copyright. To promote the greatest possible use of government data, foreign copyright should also be waived.

Many of these points are per the community best practices recommendations at http://theunitedstates.io/licensing/.

@haleyvandyck haleyvandyck added the license label Jun 2, 2014
@waldoj
waldoj commented Jun 2, 2014

I haven't dived into @JoshData's entire list, but the concerns raised by @sbma44 and @benbalter strike me as quite sensible.

@JoshData JoshData referenced this pull request in unitedstates/licensing Jun 2, 2014
Open

Language for Contracting #25

@konklone
Contributor
konklone commented Jun 2, 2014

It may be helpful to have a more visual diff in the thread for people, of what the changes are:

licensing-change

I'm with @joshdata here: all this seems to do is add a reference to the status quo of (domestic) public domain for original USG works, while tweaking the description of the exceptions that may exist.

To the extent it encourages agencies to have contractors do something (for example, by requiring the contractor to apply an open license to data created or modified under the contract), it's not referencing the public domain at all.

So for example, it doesn't meaningfully address the issues in #64 or #257, which are about recommending license-free waivers instead of "open licenses" when it comes to government works, no matter who they're originally produced by.

Perhaps it's not meant to address them! In which case, we can continue the discussion there or in a subsequent discussion. But the PR's description sort of implies that this is meant to address those concerns, and right now it's not.

@JoshData
Contributor
JoshData commented Jun 3, 2014

Wired ran an article on this pull request:
http://www.wired.com/2014/06/whitehouse_github/
(lots of factual errors and wishful thinking, unfortunately)

@tvol
tvol commented Jun 5, 2014
  1. I agree with the points made by @benbalter, @JoshData, @konklone
  2. the phrase "open licenses" does not align with/support the phrase "no restrictions"--even the most permissive licenses require attribution as a condition (read: restriction)
  3. and if we're talking about public domain in the U.S. (Section 105), it could be clearer by adopting CC0 Public Domain Dedication (https://creativecommons.org/publicdomain/zero/1.0/). This is in line with the good recommendations mentioned by @JoshData at http://theunitedstates.io/licensing/, and some Federal agencies have already started to do this, most recently https://open.fda.gov/terms/
  4. Question: what does "does not fall squarely within the public domain" mean? I think one of the main concerns raised above (and by others on some past pull requests) is 'what is the scope of content that POD is attempting to cover with its licensing guidelines?' What content are you talking about that wouldn't fall under Section 105 where a license--instead of a waiver--would be acceptable?
  5. IANAL either
@pmarreck

Looking on as a software developer (and long-time Github user) who arrived here via Wired (and a side interest in government), it is great to see that a tool built for collaborative code editing (and proposal) ends up being a fantastic use case and workflow for policy wording changes. Thanks to anyone who thought out of the box enough to make this happen, I think a lot more non-software-related projects out there could benefit from Github's (and other open source) tools, at least for the editing of official documents that depend highly on specific wording (whether for legal or other reasons)

@nsinai
Contributor
nsinai commented Jul 14, 2014

Hi! Iโ€™m Nick, and Iโ€™m U.S. Deputy CTO. Just wanted to share a quick update: We really appreciate the thoughtful feedback on this pull request and are still working through how to incorporate it on our side.

@philipashlock philipashlock changed the title from Open and Iterative Policy Development to Public Domain & Licensing - Open and Iterative Policy Development Dec 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment