Can freelancers publish code in GitHub and claim it to be theirs?

Question

I am curious to know the legal process of a collaborated effort for a code at a small startup.

Say I am the technical head of a startup, and I have about 90% of the code/commits. The other 10% is by temporary employees, interns, freelancers, etc. For the sake of this story, I will call one freelancer Alan.

For a particular project, Alan was given read access to a private repository, and write access to his branch.

What prevents Alan from copying our private code and pasting it on GitHub as his own 'published work', essentially granting him copyright over our work?

We could show git logs as proof that we had access to the code before he arrived, but git logs are easy to modify, and histories can be rewritten.

On GitHub, say Alan uses his signed keys, removes the entire git history and makes a commit with the final state of our whole codebase as his 'Initial Commit'.

What legal standing do we have (or proof) if we have not made Alan sign any documents specifically saying he is not allowed to publish our code anywhere (but we also haven't signed any document saying he IS allowed to publish our code).

Updates: There has been some discussion, so I would like to ask a more concrete question. Is it proof enough that Alan posted the code at a given time first(which was verified through something like Github's signature on the commit) that I cannot file for a copyright?(since he has published his code and gotten it verified, but we did not used 3rd party signed commits)

Answer 1

Provided you are in one of the 170+ countries signatory to the Berne Convention (the current 10 non-signatories are, exhaustively: Eritrea, Marshall Islands, Nauru, Palau, San Marino, Iran, Iraq, Ethiopia, Somalia, and South Sudan), then copyright comes into existence at the moment a work is fixed in a tangible medium, not when it is published. The initial copyright owner is the author of the work. In cases of employment, the "author" might be the natural person who authored the work, or the corporate person who employed the natural author.

To clarify your thinking about registration: copyright registration is a public record of authorship (or copyright ownership). Registration does not create a copyright, but is merely a recording of the copyright that was automatically created at the moment of original authorship.

Depending on circumstances and jurisdiction, Alan might have a legitimate claim to copyright on his own work. However, he will be quite hard-pressed to find a convincing theory of law that allows him to publish the unpublished copyrighted work of other people without their permission.

This leaves him either to admit defeat -- he cannot possibly own the copyright of his coworkers' code, so he cannot have legally reproduced it -- or else make the baldfaced lie that the code has no other authors other than Alan himself. For your company to disprove such a claim, you may employ sworn testimony of your coworkers, you may employ code analysis to show differing coding styles (suggestive of multiple authors), or you may show code backups or version control history showing the progressive authorship of the work over time by many people. (Sure, a Git history is possible to fake, but a realistic history with feature branches, "whoops, undid the typo in the last commit" messages, etc. would lend significant weight to your company being the original authors.)

Answer 2

This is a fairly complex question and it depends heavily on what jurisdictions are involved. In the US software development by regular employees will typically be classified as "work for hire" and the copyright will belong to the employer. For contractors the situation is more complex and you haven't done yourself any favors by not having written agreements with your contributors. Depending on the exact circumstances and jurisdiction, Alan may actually have a legitimate claim to the copyright of the code he wrote, though not to the code he didn't write.

To be quite literal, there is nothing that prevents Alan from taking the code, putting it on GitHub and claiming copyright. However it is only a claim. You are free to take Alan to court and assert your own ownership of the copyright. Your case is weaker because Alan is apparently a contractor rather than a regular employee and you have no written agreement. However you can still claim that Alan didn't write much of the code, and that the parts he did write were a contribution to a collective work.

It would then be up to you and Alan to bring the best evidence for both your cases before the court, and the court would decide on the preponderance of the evidence. Yes, log files can be altered, but log files in conjunction with sworn testimony from your other contributors would still cary weight.

Answer 3

The details will vary based on your locale, but I'm answering this assuming your locale is a party to the Berne Convention (since most are).

What prevents Alan from copying our private code and pasting it on GitHub as his own 'published work', essentially granting him copyright over our work?

This would not grant him copyright in any way. Publishing something does not give you any rights that you didn't have before you published.

What legal standing do we have (or proof) if we have not made Alan sign any documents specifically saying he is not allowed to publish our code anywhere (but we also haven't signed any document saying he IS allowed to publish our code).

As the author of the code, you hold the copyright and all rights to the code are yours alone. You don't technically have to get Alan to sign something saying he isn't allowed to copy the code. The default position is that the only person allowed to copy, modify, use, distribute, etc. a copyrighted work is the copyright owner. The purpose of a software license is to give someone else limited permissions to use the copyrighted code. If Alan can't produce a valid license showing that you gave him permission to do what he did, then what he did isn't legal.

Is it proof enough that Alan posted the code at a given time first(which was verified through something like Github's signature on the commit) that I cannot file for a copyright?(since he has published his code and gotten it verified, but we did not used 3rd party signed commits)

Publishing or posting something is irrelevant to copyright ownership. The author of a work automatically owns the copyright as soon as that work is "fixed" in a medium (meaning, as soon as it's printed on paper, saved to a file, recorded, etc). You don't have to publish it or register anything, it's completely automatic. If I hack Steven King's laptop, steal an unreleased manuscript, and publish it, Mr. King still owns all of the copyright. I can't take ownership of the copyright unless the copyright owner voluntarily transfers it to me.

Also, a signed Github commit verifies that the commit hasn't been tampered with and that the committer's identity hasn't been spoofed. This is useful from a software security standpoint, but is completely irrelevant as far as copyright goes. A "verified" commit doesn't indicate anything about whether the committer had the legal right to use the associated code. This is good for you, because now it's a whole lot harder for Alan to defend himself by arguing that someone else committed the code and made it look like he did it. The act of distributing the stolen material is stamped with his verified identity, which makes your lawyers' jobs easier.

I have a feeling you might be confusing copyright and patents in a lot of this. Copyrights are automatic and publication and registration are optional and irrelevant. Patents, however, must be filed and awarded, and many locales have a "first to file" rule. It is possible for someone to steal a design and patent it before the rightful owner can do so. Such a patent (if it was granted) would be completely invalid, however, and you could get it overturned in court or by an appeals process (plus sue for damages). Software generally isn't patented - and in some locales cannot be patented - so this likely won't apply to your work.

Backdating commits won't really help Alan. As you mentioned, commit logs can be forged, so they're unlikely to be given much legal weight. Github's server logs know when the repository was created and when the code was pushed to the repo, and this information would be much more trustworthy in a legal case since it comes from a disinterested third party. You also have the sworn testimony of everyone else who worked on the code base, plus indirect evidence like email threads discussing the code, reports showing screenshots of test builds, etc. that can't be faked as easy as a commit log.

Answer 4

One way to have evidence of original authorship of a work without originally disclosing the work is to first put the work in its entirety along with an authorship file into a compressed archive and securely (e.g. SHA-2 or SHA-3) hash the archive. Then, the hash must be published in several reputable sources which will serve as a timestamp reference. This will provide strong evidence that the work was originally authored by your entity. However, the claim must still hold up against the theory that your entity had copied it from someone else who failed to cryptographically prove their possession of the work from a particular time.

The concept is similar to publishing Git's internal object hashes with authorship information included in each source file. However, Git traditionally uses SHA-1 for its internal hashing which has been shown to be insecure—it is transitioning to SHA-2 but this could take years [1]. A hash algorithm is insecure if collisions may be easily found. Assuming there is some arbitrary data sections in your files, a collision attack can make your work appear to have been in your possession at the time of your arbitrary previously published hash.