There are several ‘rumors’ of MS Co-Pilot injecting itself into Open Source code as “Co-Author” of certain github commits. Does this make MS a stakeholder in (legal) ownership in commits/apps?
An example:
Here Co-Pilot is being asked to review some code, and at the same time by doing so, it qualifies itself as legal co-author. In the same commit, a certain “Kabutojira” is also co-author and it seems this is a bot/AI agent?
Just trying to get my head around this and how this (legally) works.
and asked several questions. Here is the current outcome, with an advise for the human author:
———-
Based on the current legal landscape and the recent technical updates from Microsoft and GitHub as of mid-2026, here is the English breakdown of your inquiry regarding Copilot and authorship.
1. The Automatic “Co-authored-by” Status
In recent updates to VS Code and GitHub Desktop, a feature was introduced that automatically appends metadata to git commits: Co-authored-by: GitHub Copilot <noreply@github.com>.
How it works: When the AI provides a significant code suggestion or generates a commit message that you accept, the editor inserts this “trailer” into the commit history.
Technical vs. Legal: It is crucial to understand that this is a technical attribution, not a legal one. Microsoft uses this for transparency and “provenance” (tracking where code came from), but it does not grant the AI legal standing.
Control: This is often enabled by default in recent versions, but it can be disabled in your VS Code settings under git.addAICoAuthor.
2. Can an AI be a Joint Author?
Under current law in the US, EU, and Canada (referenced in the article you linked), the answer is no.
The “Human Requirement”: Copyright law is predicated on “human authorship.” As of 2026, courts globally continue to rule that non-human entities (AI) cannot hold copyrights.
Public Domain Risk: If a piece of code is generated entirely by AI with no human modification or creative direction, it may be ineligible for copyright protection entirely, effectively placing it in the public domain.
Joint Authorship Criteria: For “Joint Authorship” to exist, there must be an intention between two legal persons to merge their contributions into a unitary whole. Since an AI is not a legal person, it cannot fulfill the intent requirement for a joint authorship agreement.
3. What this means for the code itself
Even though the AI is not a legal “owner,” the use of AI contributions impacts the status of your codebase:
Diluted Protection: The more code you commit that is purely AI-generated, the harder it becomes to sue a competitor for copying it. You can only claim ownership over the parts where you exercised “creative control” or “originality.”
The “Black Box” of Ownership: Labeling code as “Co-authored by Copilot” creates a paper trail that might be used against you in court to prove that certain parts of the code lack human originality.
Corporate Implications: Many legal departments now mandate that developers disable the automatic co-author tags. In the event of a company sale or an IP audit (due diligence), having thousands of commits attributed to an AI can complicate the valuation of the software’s intellectual property.
Summary
The automatic review leading to a “co-authored” status is a metadata convention implemented by Microsoft for transparency. It does not grant the AI copyright.
The code is not “under the authorship of an AI” in a legal sense, because AI cannot be an author. However, the code becomes “AI-assisted,” which means its copyright protection is potentially narrower than code written entirely by humans. If you want to maintain the “cleanest” possible IP record, you should disable the automatic tagging feature in your IDE.
The code remains property of the repository owner.
Even if the code is generated by an agent, the real author is the person who pushed the commit.
The developer is responsible of what the agent does.
Few days ago we added some guidelines just to better handle this scenario:
What is the policy of Nethesis on the Nethserver, Netsecurity and NS modules/apps please and when is this in effect?
I see, but the developer handbook is a dev guide and suggestion, it is not mandatory for commits and is not a legally binding agreement. See the development process where it is stated that it the ‘aim to achieve’.
Independant developers and Nethesis payed developers and everybody else can commit code to open source porjects. How to cope with wishes, independency, believes, corporate and the end user? Can commits be refused if they do not comply to the dev handbook, if so why and what reasonings are there in such a descision making process?
I personally would not like it that a company that obtains the rights to the source code in the future to contact me and demand payment for they have author rights and thus intellectual rights on the open source products I use, and they have my “phone home” history to prove it.
IIMHO a firm policy and control mechanism should be in place to safeguard the independency of Open Source code stay Open Source owned by the public. Wishfull thinking and guides will not cut it for the future. History has shown this again and again.
Sure. This is a responsibility of the reviewer.
Of course, different project can have different policies. Sometimes you need to sign and agreement before contributing.
What responsibility has a reviewer, who is the reviewer and against what policy or personal insight are descisions being made. For a handbook is not a barrier, it is a guide, not a legal standpoint.
All projects under ‘Nethserver’ are owned by the legal Italien entity Nethesis srl unipersonale. They alone call the shots on commits, not the PR’s but on the actual commits. What different policies? I can;t find any different policies in the handbook, nor on Github, nor on the Nethesis website.
‘Sometimes you need to sign’ what does that mean? What agreement, a NDA? Litterly NOBODY from the Open Source community will sign any NDA. What do you mean and what is the motivation? Digital heroes? (Whatever they may be), The seperate reseller community? or the Open Source community. It seems Nethesis is trying to deal with many different groups and get things mixed up.
So back to the main topic, how can the Open Source community count on independency? How does a PR need to look like or what can it or can not contain, to what values and standards can a PR be refused? Political, strategic, technical, ownership?
All I ask is complete transparency and healthy discussions.
What I meant is simpler: these are the rules we gave ourselves, and we apply them across all Nethesis projects, including the small amount of closed code we sometimes write for internal needs.
I was not talking about an NDA. I meant contribution agreements / CLAs / OCAs. Some open source projects do require that, even for open source code (eg. Oracle, as for MySQL ) . There are others as well, but I can’t recall them right now.
We do not use any CLA.
About PRs: in practice, a PR can be refused if it does not comply with the project rules, licensing/compliance requirements, attribution requirements, technical standards, or simply with the direction maintainers decided for the project
So, to answer your question about independence: the community can rely on transparency of the repositories, public review process, and the fact that maintainers can reject code that does not follow the project policies. That is exactly why we defined those policies.
Still, I am not a lawyer, I am a developer. My role is to help the developers I work with follow the policies. We established the guidelines together and they were validated by the company. If those policies are not followed, the code should not enter the codebase. Of course, we are human and mistakes can happen, but the goal is to make the process clearer and improve it over time.
On the legal side, I prefer to stop here, because that is outside my expertise.