How Should I Get Permission to Use Contributions?

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:

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:

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

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.

$ git clone https://github.com/octocat/git-consortium.git
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^
0001-Create-foo.txt.patch
$ cat 0001-Create-foo.txt.patch
From bbfbbc128d3dce29699b0e56821f1bd9bb01d01c Mon Sep 17 00:00:00 2001
From: Jason Yundt <jason@jasonyundt.email>
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.
--
2.36.0

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 git@vger.kernel.org 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:

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.

Others

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).