Decision on proper application of CC0 artifacts

[mbland]

The CC0 FAQ recommends adding a preamble to each source file header, as well as including the full plaintext of the license as COPYING.txt. This was first raised in the context of github/choosealicense.com#243, since choosealicense.com seems to make one recommendation and CC itself makes another. I wrote info@creativecommons.org on Jan 7 and have pinged several times since, without a reply or a redirect.

This has also now coming up in 18F/test_temp_file_helper#4 and 18F/test_temp_file_helper#5. I'll remove the COPYING.txt file from that repo for consistency's sake as @adelevie recommended, but I'd like to see a consistent message from both choosealicense.com and CC.

[adelevie]

+1 to this issue, thanks for filing.

[konklone]

I'd also like to see greater consistency between choosealicense and CC. But I also think the idea of including licensing at the top of source files is a bit outdated, and that without strong justification and leadership from outside organizations we should continue with the GitHub model.

In https://github.com/github/choosealicense.com/issues/243, @benbalter said:

There's a broader discussion to be had, but adding notices to each file makes sense in formats / times where it's likely that an individual file would be separated from the project. Think a punch card or pamphlet versus a GitHub repo or a book. It wouldn't make sense to put a copyright notice on each page in a book, because the pages are bound together and a copyright notice up front is sufficient. Today with package managers, Git Repos, Gems, and the like, the chance of a single file being removed (and thus the license being forever lost and untraceable) is remote.

I think this is a real good point, and sums up 90% of the reason to put it in a single LICENSE file instead of at the top of each file.

It falls down a bit when your repo includes source files from another project. Package managers solve this problem in theory, but I've personally updated the LICENSE for a few projects recently to spell out the exceptions at the top. Licenses at the top of source files would address that and make each part of the project self-sufficient.

The counter to that is that that only helps other coders, and only those who take the time to dive in. Open source software is so massively ubiquitous and triumphant these days, and so there are plenty of non-coder (or retired coder) stakeholders who have a reason to quickly discern the license status of a project. I also think that for anyone, coder or not, learning the license status of a project by surveying its files is pretty time consuming.

I think the history of free software is pretty closely tied to *nix/BSD-based package management, something I'm not personally very familiar with -- there may well be some very good reasons to license files individually in that environment. So projects in that situation should do whatever their community says they should do. In the communities that 18F is in, the norms are getting pretty well established to use a LICENSE file, so my vote is to keep on with that.

/cc @paultag

[paultag]

I'd also like to see greater consistency between choosealicense and CC. But I also think the idea of including licensing at the top of source files is a bit outdated, and that without strong justification and leadership from outside organizations we should continue with the GitHub model.

Not quite outdated -- it just helps for files that get copied around wholesale. It's not a requirement of too many licenses, but it's handy for ensuring there's no ambiguity about the licensing of each file. It's never been a strict requirement, just a nicity.

I agree with the quote, but I disagree it's less likely to happen these days. It was more common to do code copies in the days of yore, though.

I enjoy them, but it's up to each project.

I think this is a real good point, and sums up 90% of the reason to put it in a single LICENSE file instead of at the top of each file.

Often times the LICENSE file is a requirement, and file headers are not the whole license. You'd not include the whole GPL or CC0 three-part document in a source header, just a notice to remove ambiguity.

Most of the time, the license does require the full license text to be distributed with the code (even if you have headers).

When I review software for inclusion in Debian, having each file have a copyright notice is helpful for tracking down exact terms of the work -- but it's about 50/50 anyway.

It's just style -- so long as everything still respects user freedom, it's all good!

[mbland]

FWIW, I'm indifferent to what the outcome is; I'm happy to just say go with LICENSE.md and be done with it. I'm just frustrated that CC has positioned itself as a legal authority, that the chooseyourlicense.com site has positioned itself as a one-stop shop for license advice, and the messages from both about the same license seems inconsistent. It's not that I fear running afoul of the law, but I'd like some clarity (and apparent cooperation) between stakeholders when it comes to accepted practice to avoid any potential legal hair-splitting down the line.

[konklone]

It's not that I fear running afoul of the law, but I'd like some clarity (and apparent cooperation) between stakeholders when it comes to accepted practice to avoid any potential legal hair-splitting down the line.

Totally agree. To my knowledge, there's been so little actual legal precedent for contesting open source licenses in court that I suspect having consistency between authority figures is more important than usual. Flagging @tvol if he has any thoughts.

[tvol]

I asked our web developer/sys admin at CC and he thinks you should put the license in each file as files often get copied from one project to another, and without the header you'd have no idea what the license is, and you'd have to assume it was proprietary. That being said, the recommendations listed on that CC0 FAQ page are pretty old (likely from 2011). If the community best practice has changed, CC would want to be able to reflect/recommend that too.

[afeld]

Also, the CC FAQ page is a wiki, so that recommendation wasn't necessarily written by a legal authority. My vote is to stick with a single LICENSE file, but add a header in things that are likely to be copied, like compiled JS files. Good enough for now?

[mbland]

I'm happy to follow whatever the decision is between CC and choosealicense.org, and I'd like to see that decision documented and consistent on each party's website. @tvol's comment does surprise me, though, that CC wants to reflect community practice rather than establish it. Is my understanding incorrect, that CC has lawyers on-staff to ensure that their recommended practices are legally viable? (And, as a side note, I'd like to know why I've gotten zero acknowledgement or response from info@creativecommons.org.)

Please understand, I'm not trying to be a nagging PITA. I just want to make sure the story is straight as it can be from the beginning when it comes to practices with potential legal ramifications, especially as 18F is trying to set a standard for open-source development across the US federal government.

[konklone]

My understanding is that because open source licensing is primarily normative and not hugely battle-tested in court (though there are cases), that everyone's figuring this stuff out as they go, CC included. And bear in mind, CC's primary area of expertise is on licensing non-software works. Normal CC licenses, like CC-BY, aren't appropriate for software.

And the pickup of CC0 for software is relatively recent. IIRC, choosealicense.com didn't include it on launch, rather just listing "Public domain" and "Unlicense". In fact, I was recommending Unlicense for software, until this thread on Project Open Data convinced me that CC0 was a better choice.

So I think at some level we're going to need to embrace the chaos and understand that 18F is helping lead the way on this.

[mbland]

@konklone I'm all for leading the way if no one else will. I'll go by whatever the current state of the policy is in this here repo, then. Hopefully this will prove satisfactory to CC and choosealicense.com as well.

[mattl]

@mbland FWIW, I responded to you from the info@creativecommons.org issue tracker twice, but received several more emails with "Ping" in them. Its possible you're not getting emails from CC.

[mbland]

@mattl Hmm, yeah, I definitely didn't receive any responses, and I check my spam folder on a daily basis, so I don't think it got canned. I did indeed keep sending "Ping..." messages because I didn't receive any response.

Happy to try to help track the problem down offline if you want; but would you mind posting a summary of your response here, if it's materially different from what's been discussed?

[tvol]

@mbland I don't think it's so surprising that CC would want to hear from communities like this about what the best way to mark software that is under CC0. The initial feedback from @mattl on this (that you should put the license in each file as files often get copied from one project to another) is a general solution. And it seems like the mechanism suggested by choosealicense.com is yet another way. Are you looking for a single way that this should be done that can be used in every software project? If there's a standardized or normative way to do it, then I think CC would want to document it--and if there's enough community buy-in--recommend it as a best practice. But it's rare that CC proclaims a single way to do something. The CC tools themselves have some flexibility built into them, for example there are different ways that attribution can be adequately fulfilled when using the licenses, depending on the medium and context (see https://wiki.creativecommons.org/Marking_your_work_with_a_CC_license).

[mbland]

@tvol Thanks for the feedback. I'm not looking for the One True Way so much as a clear alignment between the parties setting licensing standards. If both CC and choosealicense.com clearly document that these are all acceptable methods, that'd be ideal. I was just alarmed that choosealicense.com's advice did not appear to match up with CC's advice, which I'd presumed to be based on specific legal requirements. I'm also curious why there isn't tighter coordination between the groups to avoid potential discrepancies like this in the first place.

Again, not trying to be difficult, and I appreciate the discussion; just being paranoid about ending up on the right side of the law.

[adelevie]

which I'd presumed to be based on specific legal requirements

<NotALawyer>

tl;dr: The recommendation to include CC0 language in each file is not a legal requirement. It might be more practical for some use cases and behaviors, but not likely ours, as @konklone has pointed out.

It seems that the issue of whether to include the license in each file or not does not affect the validity of the license. e.g., there is no specific legal requirement. It's an issue of practicality: if individual files are often copied a la carte, it might be more practical to include terms in each file so as to prevent downstream ambiguity.

For what it's worth, a CC0 license is not primarily an actual license, but a declaration that rights are being waived and that something is being dedicated to the public domain. Theoretically, this need not even be made in the repo. If I tweeted that I dedicated something to the public domain in the US, my rights to sue someone for copying that thing are likely non-existent. The dedication of the thing to the public domain is not contingent on any offer, acceptance, or mutual assent from any party or parties. It's either in the public domain or it's not.

Contrast that with something like the GPL, which requires something to be done (or not done) in exchange for the rights to copy. There is a license component to CC0, which is a fallback for jurisdictions where the dedication to the public domain is insufficient to allow others to freely copy. Nevertheless, there is no requirement that a contract be included in each file for a contract to validly cover each file.

@mbland, I agree that the goal for 18F to be a good open source citizen is quite worthy. Sometimes, as is the case here, I think part of that can include straying from an errant recommendation if there is a good reason.

</NotALawyer>

[konklone]

I think we ended with basically all tolerating the status quo, so I'm going to close this.