In this post, I discussed why corporations are having trouble regarding the DCO as sufficient for contributions to projects using licences which require patent grants. The fear being that rogue corporations could legitimately claim that under the DCO they were authorizing their developers as agents for copyrights but not for patents. Rather than argue about the legality of this trick, I think it will be much more productive to move the environment forwards to a place where it simply won’t work. The key to doing this is to change the expectations of the corporate players which moves them to the point where they expect that a corporate signoff under the DCO gives agency for both patents and copyrights because once this happens for most of them (the good actors), the usual estoppal rules would make it apply to all.
The fact is that even though corporate lawyers fear that agency might not exist for patent grants via DCO signoffs in contributions, all legitimate corporate entities who make bona fide code contributions wish to effect this anyway; that’s why they go to the additional lengths of setting up Contributor Licence Agreements and signing them. The corollary here is that really only a bad actor in the ecosystem wishes to perpetuate the myth that patents aren’t handled by the DCO. So if all good actors want the system to work correctly anyway, how do we make it so?
The lever that will help to make this move is a simple pledge, which can be published on a corporate website, that allows corporations expecting to make legitimate contributions to patent binding licences under the DCO to do so properly without needing any additional Contributor Licence Agreements. Essentially it would be an explicit statement that when their developers submit code to a project under the DCO using a corporate signoff, they’re acting as agents for the necessary patent and copyright grants, meaning you can always trust a DCO signoff from that corporation. When enough corporations do this, it becomes standard practice and thus expectations on the DCO have moved to the point we originally assumed they were at, so here’s the proposal for what such a statement would look like.
Corporate Contribution Pledge
Preamble
It is our expectation that any DCO signoff from a corporate email address binds that corporation to grant all necessary copyright and, where required, patent rights to satisfy the terms of the licence. Accordingly, we are publishing this pledge to illustrate how, as a matter of best practice, we implement this expectation.
For the purposes of this pledge, our corporate email domain is @bigcorp.com and its subdomains.
Limitations
- This pledge only applies to projects which use an OSI accepted Open Source licence and which also use a developer certificate of origin (DCO).
- No authority is given under this pledge to sign contribution agreements on behalf of the company or otherwise bind it except by contributing code under an OSI approved licence and DCO process.
- No authority is given under this pledge if a developer, who may be our employee, posts patches under an email address which is not our corporate email domain above.
- No trademarks of this corporation may ever be bound under this pledge.
- Except as stated below, no other warranty, express or implied, is made on behalf of the contribution, including, but not limited to, fitness of the code for a specific purpose or merchantability. The entire risk of the quality and performance of this contribution rests with the recipient.
Warranties
- Our corporation trains its Open Source contributors carefully to understand when they may and may not post patches from our corporate email domain and to obtain all necessary internal clearances according to our processes before making such a posting.
- When one of our developers posts a patch to a project under an OSI approved licence with a DCO Signed-off-by: from our corporate email domain, we authorise that developer to be our agent in the minimum set of patent and copyright grants that are required to satisfy the terms of the OSI approved licence for the contribution.
All of this seems sensible, except for the requirement to post patches via a corporate email address. Corporate email addresses often prove unusable for patch submission, and even when they don’t, continuity and developer identity may make it preferable to submit patches under an individual email address. Furthermore, corporate email addresses almost universally stop working after a developer leaves.
Please do not propagate an expectation that developers at a company should use their company email address, or that any meaning whatsoever applies to the use of one email address over another.
(Irony: your comment system seems a bit broken, as I could not post a comment using a name and email address; I had to go create an account somewhere instead. Attempting to post with a name and email kept sending me to a page saying something like “please fill in the required fields”, and listing the name and email fields as missing.)
Well, legally you need some sign of authority from the company, and the email is that. I can’t quite see there’s anything to replace it with
The social media thing was an experiment since a lot of people don’t seem to have openid. I’ll remove it.
> Well, legally you need some sign of authority from the company, and the email is that. I can’t quite see there’s anything to replace it with
Today, we accept a DCO from an employee of a company, submitted using their personal address, and accept it for copyright purposes, despite the company typically owning the copyright. Why does that not suffice for patent purposes as well?
If moving to having the DCO cover patents requires some more explicit statement of employer assent, then it should suffice to have the employee explicitly state employer assent, even if using a personal address.
I’m asking that if you promote a document like the sample you suggested, that you please not encourage employers to require use of corporate email addresses, whether as a means of identification or for any other reason.
> The social media thing was an experiment since a lot of people don’t seem to have openid. I’ll remove it.
The problem occurred with the standard comment form that asked for author name and email address; I used the social media option precisely because that comment form didn’t accept a name and email, and said I needed to fill in a name and email. Unless the social media bits were what broke that?
>Today, we accept a DCO from an employee of a company, submitted using their personal address, and accept it for copyright purposes, despite the company typically owning the copyright. Why does that not suffice for patent purposes as well?
You can’t make a patch contribution to a project without granting copyright in some form. If your employer owns the copyright, you grant the copyright on their behalf whether you contribute from your personal email or from their corporate email. However, if you make an individual contribution from your personal email, and the licence seeks to bind patents reading on the contribution, how do we know whether you’re granting only the patents you individually own or those of your employer. This is the uncertainty OpenStack wants resolving for the Apache-2.0 licence.
Why not use something else than the email address for that purpose? For example, instead of “John Smith “, using “John Smith (Big Corp Inc.) “? That would decouple the legal aspect (making agency on behalf of the company explicit) from the technical issues (which address allows you to send proper patches, is more durable, etc).
> Why not use something else than the email address for that purpose?
I’m afraid its a legal reason. The DCO uses a common law technique called agency by which a person can act on behalf of an entity like a corporation:
https://en.wikipedia.org/wiki/Law_of_agency
To create agency for the DCO, there must be a “sign of authority” for it to work; just saying I’m X and I work for Y isn’t enough. However, using a corporate email as a developer is such a sign of authority. There are obviously others, but none that doesn’t require an extra step which would defeat the purpose of keeping within the current DCO process.
Damn, the comment system ate the email addresses. I meant moving from “John Smith [john.smith at bigcorp.com]” to “John Smith (Big Corp Inc.) [jsmith at otherdomain.example]” (please mentally substitute less than and greater than signs).
Pingback: Bottomley: A modest proposal on the DCO | Linux Press
One thing this document does not state is to whom the patent rights are granted (all the users of the software to which the code was contributed? all the users of the code, as long as the code is not relicensed? all the users of the code, as long as they abide by the license? all the users of the code, in any project?)
Once that is made clear, it may also make sense to add something saying that suing the company that made the contribution could result in the patent rights terminating, and the company contributing the code reserves the right to use the patents in a counter-suit.
That way companies which are reluctant to give up the defensive value of their patents can still pledge that their technology is free to use for certain people, on good behaviour, while allowing those companies to keep using their patents as a shield in case they get attacked.
Thoughts?
> One thing this document does not state is to whom the patent rights are granted (all the users of the software to which the code was contributed? all the users of the code, as long as the code is not relicensed? all the users of the code, as long as they abide by the license? all the users of the code, in any project?)
It doesn’t state this deliberately. The DCO is silent on the terms of the licence because its designed to be a contribution process, not a licence in itself. So the DCO only works in combination with an Open Source licence, and the terms of that licence govern what (if any) patent rights go with the project. The pledge is merely designed to clarify that a corporate contribution to a licence which entails patent rights can be made under the DCO.