How Should I Get Permission to Use Contributions?

(learn about this date format)

In a previous post, I decided that I would accept patches using a public-inbox. One advantage of public-inboxes is that anyone can mirror them. There’s a few legal issues associated with accepting patches via public-inboxes and allowing people to mirror public-inboxes:

  1. By default, emails are copyrighted. In other words, I’ll need permission to redistribute any emails that get sent to my public-inbox.
  2. Even if I had permission to redistribute the emails, others wouldn’t necessarily have permission to redistribute them further.
  3. Even if I had permission to do 1 and 2, I still wouldn’t necessarily have permission to incorporate emails that contain patches into upstream projects.

How others have solved similar issues

I’m certainly not the first person to run into these sorts of challenges. Let’s take a look at how others have solved similar issues:

Stack Overflow

Stack Overflow isn’t meant to be mirrored or contain patches per se, but readers are often encouraged to copy from posters’ answers. To make sure that readers have legal permission to copy from answers, Stack Overflow first makes sure that posters agree to its Terms of Service. Stack Overflow does this using three different mechanisms. The first is by linking to the Terms at the bottom of every page. If you click on that link, you’ll see that the first sentence is By using our products, you agree to our Terms of Service. The Terms go on to say:

By accessing or using the Services or the public Network in any manner, including without limitation by visiting or browsing the public Network or registering for an account on the Network, you affirm that you have read, understand, and agree to be bound by these Public Network Terms, as well as the Acceptable Use Policy and Privacy Policy.

Stack Overflow’s Public Network Terms of Service / 1. Public Network Terms ( revision)

This first mechanism is something that I would like to avoid. How could anyone expect someone to truly (not just legally) agree to those terms before they use Stack Overflow? Even if the first time you visited Stack Overflow was by going directly to the Terms of Service page, you still would still be using the site before you had fully read those terms. Sending an HTTP request for the Terms and interpreting the response counts as using the site (that might not be legally true, but it’s definitely literally true). In other words, you have to use the site to figure out what legal terms you’ve agreed to by using the site. It’s a trap!

The second mechanism for ensuring agreement to the Terms is gating off certain functionality. While you can use Stack Overflow without an account, you need an account to do certain things. The registration page says By clicking ‘Sign up’, you agree to our terms of service, privacy policy and cookie policy. This mechanism is something that I’m much more OK with. This mechanism tells users exactly what they’re agreeing to before they have an opportunity to agree to it.

The final mechanism for ensuring agreement is the simplest. To the right of every “Post Your Answer” button is the text By clicking ‘Post Your Answer’, you agree to our terms of service, privacy policy and cookie policy.

The second thing that Stack Overflow does (to make sure readers have permission to copy from answers) is to include a license agreement in its Terms of Service:

You agree that any and all content, including without limitation any and all text, graphics, logos, tools, photographs, images, illustrations, software or source code, audio and video, animations, and product feedback (collectively, ‘Content’) that you provide to the public Network (collectively, ‘Subscriber Content’), is perpetually and irrevocably licensed to Stack Overflow on a worldwide, royalty-free, non-exclusive basis pursuant to Creative Commons licensing terms (CC BY-SA 4.0), and[…]

Stack Overflow’s Public Network Terms of Service / 6. Content Permissions, Restrictions, and Creative Commons Licensing / Subscriber Content ( revision)

I only have two complaints with this license agreement:

  1. It’s buried in a much longer Terms of service. The likelihood that anyone would actually read it is very low.
  2. It’s all crammed in to a single sentence. I cut the quote off, but the full sentence is about the length of a paragraph, if you don’t include the bulleted list at the end of it.


GitHub is a little bit closer to my use case than Stack Overflow. Stack Overflow only accepts comments that might contain snippets of code. GitHub accepts both comments and pull requests.

Like Stack Overflow, GitHub starts by making sure that everyone agrees to its Terms of Service. Unlike Stack Overflow, GitHub doesn’t try to make its Terms automatically apply to everyone who visits the site. Instead, there’s some text at the bottom of the sign-up page that says By creating an account, you agree to the Terms of Service.


GitHub’s handling of comments is a little bit tricky. GitHub appears to be leveraging copyright law for vendor lock-in:

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).

GitHub Terms of Service / D.5. License Grant to Other Users ( revision)

(“Your Content” is defined to include comments. See A.4.)

This means that GitHub comments aren’t necessarily reproducible outside of GitHub. In practice though, I doubt that prevision has made anyone think twice about moving away from GitHub.

Pull requests

Pull requests (both regular ones and GitHub ones) have an advantage over patches: to make a pull request, you have to push an entire commit. Consider the following situation:

$ git clone
Cloning into 'git-consortium'...
remote: Enumerating objects: 19, done.
remote: Total 19 (delta 0), reused 0 (delta 0), pack-reused 19
Receiving objects: 100% (19/19), 7.13 KiB | 7.13 MiB/s, done.
Resolving deltas: 100% (7/7), done.
$ cd git-consortium/
$ git checkout -b example
Switched to a new branch 'example'
$ echo -e '\nBTW, this license doesn’t apply to foo.txt.' >> LICENSE
$ git add LICENSE
$ git commit -m 'Preemptively relicense foo'
[example 57804db] Preemptively relicense foo
 1 file changed, 2 insertions(+), 1 deletion(-)
$ echo 'Pretend that there’s something copyrightable here.' > foo.txt
$ git add foo.txt
$ git commit -m 'Create foo.txt'
[example bbfbbc1] Create foo.txt
 1 file changed, 1 insertion(+)
 create mode 100644 foo.txt
$ git format-patch HEAD^
$ cat 0001-Create-foo.txt.patch
From bbfbbc128d3dce29699b0e56821f1bd9bb01d01c Mon Sep 17 00:00:00 2001
From: Jason Yundt <>
Date: Mon, 20 Jun 2022 15:34:39 -0400
Subject: [PATCH] Create foo.txt

 foo.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 foo.txt

diff --git a/foo.txt b/foo.txt
new file mode 100644
index 0000000..18b454a
--- /dev/null
+++ b/foo.txt
@@ -0,0 +1 @@
+Pretend that there’s something copyrightable here.

If that patch was sent to me, I would assume that foo.txt was available under the same license as the rest of the repo. In reality, most patches don’t contain enough information for us to determine what legal terms apply to them. Now, let’s imagine that this change was submitted as a pull request rather than a patch. Before you can submit a pull request, you have to push all of the pull request’s commits to a remote. Commits are snapshots which means that every commit contains (a reference to) every file that was being tracked at the time. In other words, before you make a pull request, you have to give the recipient a complete copy of your version of the project. That complete copy would (probably) contain a license for the changes.

Even if the license file wasn’t modified, it still isn’t clear to me what the patch’s license would be. When I receive a copyright license, I expect there to be a statement telling me what the license is. As it turns out, that isn’t always the case. I recently found out that there’s something known as an implied license. In other words, when someone sends me a patch, it’s possible that I’ll get a license for that patch even if the email doesn’t mention licensing or permissions at all. The question is: what license would I get in this situation? I would want it to be the same as what the upstream project is using, but I don’t know how likely that would be.

All in all, pull requests tend to be licensed correctly, even in the absence extra legal agreements. The keyword here is tend. There are a few scenarios where pull requests get a little bit of help from the GitHub Terms of Service. The first is when a repo has no license. As I mentioned before, you must push commits to a remote in order to make a pull request. In other words, you have to distribute copies of the upstream project in order to make a pull request. If you don’t have a license, then you can’t distribute copies. Here’s GitHub’s solution to that problem:

By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license.

GitHub Terms of Service / D.5. License Grant to Other Users ( revision)

The second scenario where pull requests get help from the GitHub ToS is for projects with CLAs. Some (perhaps all) CLAs give more permission to project owners than project licenses give to others. The ToS specifically has a prevision for CLAs:

Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede.

GitHub Terms of Service / 6. Contributions Under Repository License ( revision)

The Git project itself

Git is developed on a mailing list. That mailing list is available as a public-inbox where people contribute to Git by submitting patches. This means that the Git project does something very similar to what I want to do.

From what I can tell, the Git project doesn’t explicitly get permission to distribute most mailing list posts. It’s possible that sending an email to gives the Git project an implied copyright license to distribute that email. That license probably wouldn’t give others permission to mirror the project’s public-inbox. Additionally, the earliest email that I found in the archive is from 2005, long before the public-inbox project was started. While it’s possible that in 2005, posting to the Git mailing list gave the project an implied license to distribute the messages in an archive, I doubt that that license would give others permission to redistribute Git’s public-inbox.

Patches, on the other hand, are different. The Git project very explicitly gets permission to incorporate patches:

To improve tracking of who did what, we ask you to certify that you wrote the patch or have the right to pass it on under the same license as ours, by "signing off" your patch. Without sign-off, we cannot accept your patches.

SubmittingPatches (from Git v2.36.1)

SubmittingPatches goes on to explain that signing off on a commit indicates that the author of the commit agrees to the Developer Certificate of Origin. The DCO makes contributors certify that are legally able to offer an appropriate license for their contributions.

Initially, I thought about using the DCO for my projects. It wouldn’t be a complete solution, but it would offer some legal clarity for patches. Plus, it’s relatively well known among FOSS contributors. Unfortunately, the DCO doesn’t really work the way I want it to:

  • The DCO has contributors certify that they have the right to submit their contribution under an appropriate license. It doesn’t make them certify that their contribution is actually under an appropriate license.
  • The DCO only works for open-source licenses. Many of the files in my projects are dedicated to the public domain under 🅭🄍. 🅭🄍 is a public domain dedication, not a license. If 🅭🄍 was a license, then it probably wouldn’t be an open-source one.
  • The DCO only works for […]the open source license indicated in the file. I try to make many of the files in my projects indicate their license or public domain dedication, but there are some files where that simply isn’t the best option. I’m sure that it’s possible to embed licensing metadata in an image file, but I doubt that many people would know how to access that metadata. Plus, there’s definitely some file formats where you couldn’t add licensing metadata in a reasonable way.


While every project and service is different, my research indicates that most projects fall into one or more of these categories:

  • projects that rely on implied licenses,
  • projects that let their centralized hosting platform handle it (by requiring pull requests or agreement to a ToS) or
  • projects that have some sort of CLA (like the DCO).

How I’m solving these legal issues

It would be nice if there was a CLA that

I couldn’t find one, so I decided to make my own. (If you know of another one, then please email me). You can find it here.

In my next post, I’m going to break down the agreement that I created, and explain why I wrote it the way I did. After that, I’m going to:

  1. write instructions for how to submit patches to my public-inbox,
  2. test that patch submission process with a regular inbox,
  3. switch my Web server to NixOS and then
  4. create a public-inbox for accepting patches.

It’ll be a while before I get back to working on Jason’s Ring-Con Project. Once more of that project is complete, it will hopefully become more clear why I’m spending so much time on this process.