It Matters Who Owns Your Copylefted Copyrights

by Bradley M. Kuhn on June 30, 2021

Throughout the history of Free and Open Source software (FOSS), copyright assignment has simultaneously been controversial and accepted as the norm in our FOSS communities. This paradox, I believe, stems entirely from some key misunderstandings that perpetuate. This issue requires urgent discussion, as two of the most important FOSS projects in history (GCC and glibc) are right now considering substantial and swift changes to long-standing copyright policies that date back to the 1980s. This event, and other recent events over the last few years in the area of GPL compliance and corporate FOSS adoption, point to long-term problems for projects. This essay works through these nuances, and will hopefully assist FOSS contributors as they make difficult decisions about copyright ownership for their projects. At the end, I provide a summary list of issues to consider when creating copyright ownership policies for FOSS.

The Default Is: You Give It Away To Your Boss

I was at one time bemused, but now am mostly aghast, at the true paradox of common wisdom about copyright assignment for FOSS projects. I don't believe anyone has done a statistically valid study, but anecdotally it's rare to find a FOSS contributor who enjoys assigning copyright to another entity. FOSS contributors who do assign copyright to a non-profit charity that collects copyrights (such as the FSF or Conservancy) often complain about the complexity and annoyance of the paperwork to get started as a contributor. Even more commonly, contributors express disgust or annoyance at the pressure from the project to give away something that should be rightfully theirs.

I am sympathetic on both points, and have worked over my career to design, implement, and improve copyright assignment processes for projects — in hopes to address that first complaint. However, the second concern — the preference of FOSS contributors to keep their own copyrights, is an ironic complaint. Here's why:

Almost no contributors to larger FOSS projects hold their own copyrights. If they have not gone through a process to assign them to a charity, the most likely scenario is that their employers own those copyrights. My colleagues at Conservancy have been working on the Contract Patch project — which seeks to educate FOSS contributors about their inherent right to employment agreement negotiation, and seek more favorable terms in those employment contracts. However, over the years of our Contract Patch work, we still find that only dozens (among the thousands of FOSS contributors) have insisted that their company allow them to keep their own copyrights. If you work for a company, check your employment agreement. I'll bet that your employer owns your copyrights for everything you do at work — including your contributions to FOSS — unless there's a separate agreement that gives those copyrights to a charity like Conservancy or FSF.

As a result, in debates about copyright ownership, discussions of what policy contributors want regarding the fruits of their labor is sadly moot. Without a clear, organized mitigation strategy to assure that FOSS contributors keep their own copyrights, a project (such as GCC or glibc) that switches from a standing “(nearly) all copyrights assigned to a charity” model to a plain Developer Certificate of Origin (DCO) or naked inbound=outbound contributor arrangement will, after a period of years, mostly likely have copyrights that are primarily held by the employers of the most prolific contributors, rather than by the contributors themselves.

The Faustian bargain that causes this default is the “work-for-hire” doctrine in the USA (and similar arrangements that exist around the world). When you take a job, in most places in the world, by default, your employer owns and/or effectively controls all your copyrights. They argue that they're paying you handsomely for this and as such they have every right to own it all. Perhaps that argument has merit with regard to software that will ultimately be proprietarized, but for copylefted software, the value proposition is different and history shows that the arrangement leads to surprising results.

Copyleft Is Weakened When Most Copyright Holders Oppose Enforcement

Copyleft licenses are not magic pixie dust. Copyleft is not a legislatively-mandated regulation (e.g., pollution regulations) — which are enforced by government staff. Ultimately, an entity — most commonly the copyright holders themselves — must proactively enforce GPL. This entity can be an organization, an individual, a group of individuals, a group of organizations, or a mix of all of those. Someone must enforce the rules; so-called “spontaneous compliance” is a myth promulgated by those who oppose copyleft.

Yet that myth's apparent unexamined truthiness has taken hold; many FOSS contributors reasonably think that it does not matter who owns the copyright of their copylefted works. If it's GPL'd, they surmise, surely someone out there will enforce the GPL when it's violated. Or, perhaps the contributors think that GPL violations on their particular codebase are rare. Either way, most contributors avoid the effort required to figure out who owns their copyrights and ponder whether that entity will uphold copyleft in a reasonable way. Nevertheless, I really urge FOSS contributors to think through this issue with care and healthy skepticism, as they may be surprised at the outcome. What lurks in the backchannels may well surprise you:

Once upon a time, copyleft enforcement was not considered controversial by many otherwise-pro-FOSS companies. In recent years, companies that prefer non-copylefted FOSS have succeeded in making even the most mundane GPL enforcement appear as controversial and industry-destabilizing. Many developers who contribute to GCC and glibc — even ones that work for historically FOSS-friendly companies — will be surprised to learn that their employers (or at least their legal departments) are opposed to any GPL enforcement. Conservancy, as the main organization actively doing GPL enforcement, hears this kind of pressure regularly. Our colleagues at FSF historically told us that they hear the same. It's rarely done publicly — but, when public, criticisms are delivered by proxies in a subtle, “you don't really need copyleft to be enforced anyway, do you?” manner. The public arguments are usually couched in a careful “dog whistle” style. While the message comes through loud and clear to executives, lawyers, companies and their trade associations, it's easily missed by contributors — who understandably have a much more important task to do: writing great FOSS code!

We expect that you may be surprised by this, but we can tell you that: in private, companies that contribute to key copylefted projects are not so subtle. They have communicated to those of us in the GPL enforcement community on several occasions — a message delivered by many executives over a period of many years — that they would prefer both Conservancy and FSF to curtail, or outright end, GPL enforcement. Their view, as communicated to us, is that GPL enforcement causes customers to think copyleft is problematic. As one executive once said to me: “We consider it a failure if any customer ever even asks us if they have to worry about GPL compliance”. These companies usually say: “well, we will always comply with the license, but we'd prefer if anyone who is our customer (or potential customer) simply is just left alone if they violate”. Once, an executive actually claimed to me that his company, a huge multinational software company, would: “cease to build any products on Linux and other GPL'd software at all if Conservancy and FSF don't cease their enforcement”. That statement was fortunately bluster and bluff; the company in question is still heavily invested in copylefted software, including Linux, GCC, and glibc, but the sentiment is a common one that we hear privately often. And, that company has since funded work to discredit GPL enforcement. Conservancy faces constant pressure and threats regarding its GPL enforcement efforts, and we're aware that FSF has faced to similar pressure.

In parallel, these companies have also steadily worked to hold more of the copyrights in key copylefted works — primarily by hiring the key developers that contribute to key copylefted projects. While I oppose this outcome, it's undeniably a rational approach: if companies hold the copyrights, they can decide when, how, where and most important if copyleft licenses are ever enforced. This process is well underway for copylefted works that don't have any policies about copyright ownership. For example, the “Who Contributes to Linux?” reports by LWN show starkly over recent years: fewer contributions coming copyrighted by individuals, and more contributions copyrighted by companies. While corporate involvement is always welcome in FOSS projects, we (as a FOSS community) have not responded with the necessary care to question why the companies, rather than the individual contributors, should own our FOSS. Only very few developers have even questioned this issue; we thank them for their efforts, but such questions are simply not raised enough.

As such, the most important consideration in ending copyright assignment to a charity is to consider what the employers of most of the developers will do with those copyrights, and whether they will enforce the copyleft in the best interest of the community. Even worse, might they eventually sell those copyrights to someone who will use enforcement in a manner that a charity never would — for their own avarice rather than the good of the community?

While the remainder of this essay addresses at length other secondary considerations and nuances regarding copyright ownership in copyleft projects, this point is the absolutely most important one:

Most for-profit copyright holders prefer copyleft to function much like non-copylefted FOSS. Namely, “it's certainly nice when folks voluntarily release their changes, improvements and ‘scripts used to control compilation and installation’, but if they don't, their failure to do so should be begrudgingly tolerated, and compliance should never be compelled for those who refuse”.

Violations Are More Common Than You Think

During this recent upheaval in the GCC community, I spoke at length with a GCC developer who has contributed to the codebase regularly for decades. After I'd explained some of issues above, the developer stated: “Well, is any of this really an issue for GCC? When was the last time there was a GPL violation on GCC?”. I glibly answered: “Well, I haven't heard about one for about a week, but I'll surely hear about another one soon.” The developer was flummoxed to learn that part-and-parcel to nearly every embedded Linux GPL violation (which have been, for years, innumerable) is a companion violation on GCC. Specifically, most system-on-chip (SoC) vendors not only have a stock Linux build given to the OEMs, but also include a toolchain. More often than not, a GPL violator who has what we call an “incomplete Complete, Corresponding Source (CCS)” violation on Linux will also have a “no-source-or-offer” or “incomplete CCS” violation on GCC. The usual reason is that part of the SDK given to OEMs must include an appropriate binary toolchain (sometimes with vendor-specific patches, and almost always with a complex configuration that's difficult to reverse engineer) so that the SoC integrators can compile other software for the system. This scenario is so common that we in the GPL enforcement community coined the shorthand term “toolchain violation” to refer to the scenario where the GCC violation “tags along” with a Linux violation. While glibc violations of this nature are admittedly less common than GCC, glibc violations do occur relatively often in the same manner.

Upstream developers are mostly unaware of how bad the compliance problem is regarding their code for one simple reason: the folks impacted most by GPL violations are downstream users, not upstream developers. Furthermore, correction of compliance problems usually produces code releases that “work” for the given device on which the original violation occurred, but rarely is that CCS released resulting from a GPL enforcement action trivially upstreamable. After all, this is code written, modified, and/or integrated by developers whose plan was to “get away” with a GPL violation, so why would they have invested the time to provide the improvements in a manner that it was immediately digestible for upstream? My view is that users matter, and FOSS contributors should care about their experience with the downstream consequences of their code. I urge FOSS contributors to implement copyright ownership schemes that have the most likely chance of enabling enforcement actions principled parties.

The Power of Collective Action

Regarding my views on FOSS copyright assignment, I often quote the famous gaffe of (former USA presidential candidate and senator) John Kerry, “I voted for it before I was against it” when I'm talking about copyright assignment. But I don't quote it purely for self-deprecation; I never felt the press was all that fair to Kerry, because I think policy makers should be willing to change their positions over time as new information comes to light, or when policies that we thought were beneficial in theory prove problematic in practice. I once thought universal copyright assignment for a copylefted work to a single charity was an absolutely necessity. Then, Conservancy's successful and continuing work with various BusyBox copyright holders, and our collaboration with Christoph Hellwig, showed me that there was huge value in individuals having copyrights and making their own choices about enforcing copyleft. Still later, I realized that individuals like Erik Andresen and Christoph Hellwig are quite rare, as most FOSS contributors — even if they've kept their own copyrights — ultimately have to take on such political and career risk to enforce copyleft that they must often chose not to because they could easily get blacklisted from major employers for doing so.

The central thread here is collective action by principled people who will use copyleft primarily as a tool for rights of users and for the improvement of copylefted projects. Ultimately, copyleft functions best when leaders of a project have the agency, wherewithal, commitment, and collective consensus to either ensure copyleft functions to protect their users' rights, or enable another entity to do that job for them in a principled way that serves the public good (usually in contrast to the interests of for-profit industry). (Note that even if that interest is “vendor-neutral”, as that means the interests served are the common business interests of the vendors, but not their customers.)

These issues are complex. Every policy change, or lack of policy change, will have many unintended consequences. An apparent “simple move” away from mandated assignment to a centralized organization could well be a decision to ultimately move copyright holding to for-profit corporations and their trade associations — all of whom are unlikely to stand up for the GPL and user rights. Beyond all else, I urge caution and slow deliberation before any policy changes about copyright control. I ask FOSS contributors to do the substantial and necessary homework of not only reading and considering the points of this essay, but those points raised by all parties. As you do, keep in mind that every party, including me, has a policy goal in mind for copyleft. I and Conservancy are very transparent that our policy goal is to see copyleft licenses enforced regularly on behalf of end users who buy products on the open market that contain copylefted code. We believe, as a policy matter, that copylefted copyrights are best held by entities that have a bona-fide track record of serving the public good, act in a principled and ethical manner in doing so — the most important principles being to never prioritize financial gain over users' rights — and who won't back down and give up when faced with the inevitable anti-copyleft backlash. Others, probably including your employer and the trade associations to which they pay membership dues, probably disagree with this position, but you should ask questions and listen carefully to see if you're getting a straight answer. After you've heard everyone's position, decide for yourself who deserves to have your copyrights: your employer, a charity, or yourself. Once you've decided, you'll have hard work ahead to change the default (which will likely be your employer once projects drop their copyright assignment mandate).

A Word on FSF's GPL Enforcement

The elephant in the room that I've not yet mentioned is the current status of the FSF as an organization. There is no question, given the recent mass resignation of their management, and other rapid leadership change surprises, that the FSF faces serious challenges in the next few years. I personally was previously affiliated with the FSF. That affiliation ended in 2019, so I have no real information about the internal status of the FSF since then. What I do know is that FSF currently lacks sufficient capacity to follow up on any GPL violations on GCC and glibc that we've reported for years. That said, if I have to chose between the strict dichotomy of: (a) copyrights held by the FSF (which has the possibility of recovery in the future and restoration to an organization that actively enforces the GPL) vs. (b) copyrights held by companies — many of whom are known to oppose enforcement of the GPL, I would still pick the FSF. Remember that copyright does not expire for a very, very long time. GCC and glibc are both codebases that prove the half-life of well-written software is very long, and that software stays relevant and useful for much longer than any of us usually admit. We have to think long term about the copyright ownership of copylefted works. While there are serious short-term and medium-term problems at the FSF, we have to consider carefully who is the best long-term steward of copyrights: companies or charities. Most importantly, changing 30 years of careful planning about the copyright inventory of important codebases is certainly not a decision to be finalized in a matter of just a few weeks or even months. Thus, most of all, I ask FOSS contributors to take care and ample time in their deliberations on such matters.

A Summary of Recommendations and Considerations

As promised at the start of this essay, here is a laundry list of recommendations and considerations that any copylefted project should consider regarding how to structure its copyright ownership rules. This list is provided as a quick reference only, and readers should keep in mind the complexity of the topic before jumping to a conclusion about the right policies. Not every issue below was addressed in detail in the essay above, but if there is interest from the community, I will publish further essays on other topics.

• Without your active work to avoid it (such as by modifying your contract or demanding assignment to another entity), for-profit employers will control your copyrights. You typically have no say into how or whether the license of your project is enforced if your employer holds your copyrights.
• Modern copyright assignments to charities such as the FSF or Conservancy usually take two forms: either your employer has a blanket copyright assignment, or you must individually assign copyright. In the latter case, there are typically two components: a disclaimer from copyright from your employer, and an assignment from you. In either case, you should speak at length with your employer's legal department to figure out what form, if any, is in place, and what will happen to those systems if your project changes its copyright aggregation policies.
• FOSS contributors have safety in numbers. A strong consensus that your project wants to see copyleft enforced for your users can create leverage that mitigates risk of “blacklisting” of those who chose to enforce copyleft licenses. When policies like copyright assignment to a charity or copyright ownership only by individuals are set project-wide, companies historically have simply accepted it. (The Samba project is an excellent example of a project where the developers have control.) By contrast, each contributor faces a steep climb in negotiating their ownership of the copyrights in the absence of such policies.
• While assignment to a charity can be annoying and feel problematic, this is often the most expedient way to assure that the copyleft license of your project is upheld. Conservancy, for example, will accept one-off assignment from FOSS contributors to strategically important FOSS projects. Even if you (collectively) chose to not mandate assignment for your project, it's valuable to assist and encourage your contributors to either develop together a collective individual copyright ownership plan, or assign to different charities, or recommend a mixture of the two.
• As an upstream developer, you're likely going to be unaware of most copyleft violations on your code. If possible, work with an entity that has the time and resources to investigate violations for you, and empower that entity to act on your behalf if possible.
• Pay attention to the details of Contributor Licensing Agreements (CLAs). Often, these require that you give up almost as many rights as a copyright assignment would require you to give up anyway. Avoid asking your contributors to agree to a CLA.
• Developer Certificate of Origins (DCOs) and other inbound=outbound contribution regimes are very good, useful and recommended. However ultimately such systems are entirely orthogonal to who holds the copyright. DCOs and contribution terms are general statements that attest to your right and permission to make contributions under the project's license, but are, by design, silent on the details. A DCO is absolutely compatible with a project that separately requires copyright assignment, or with a project that has other recommendations about how developers should handle copyright ownership.
• Seek and consider advice from all sources. Everyone with an opinion on these topics has a policy agenda. Ask what their policy agenda is when they advise you. Ask them their view on copyleft enforcement. Ask them if they've ever investigated copyleft violations on your software, and if so what they found and what their opinion is. If you're considering assigning your copyrights to someone, most notably your employer (who, again, is likely to by default receive your copyrights) be sure you've fully understood their policy and views on these matters. Insist that they put their policy and views in writing for you for future reference. Ask for strong commitments, and be skeptical if you cannot receive them.

[permalink]

Tags: conservancy, GPL, ContractPatch, law, licensing, resources

Ethical Employment Contracts Instead of Ethical Licenses?

by Karen Sandler on December 17, 2020

Earlier in the year at Copyleft Conf, we had a few sessions dedicated to the Ethical License movement. During the conference, Coraline Ada Ehmke gave a moving talk outlining why technologists and software freedom activists in particular must act against atrocities, especially those committed using FOSS. I have long argued that technologists (and especially software freedom activists) should dedicate more care and resources to the ethical use of technology and eliminating discrimination and oppression that technology often enables. While I don't believe software licenses are the best way to accomplish this task, I've wondered since the conference what FOSS contributors can do to protect human rights.

The proposed licenses have been essential to starting these discussions, but the license changes themselves seem unlikely to work: they'd introduce nonfree provisions, introduce license uncertainty and on top of that, we know that companies that would commit atrocities will ignore licenses and act from judgement-proof jurisdictions. So the question is how best to influence the behavior of companies who can improve their human rights record and how to insulate employees who want to take action to assure that their companies do the right thing.

Through our ContractPatch[1] initiative, Conservancy has been working to educate developers about employment contracts. We plan to eventually draft suggested contract language to help developers negotiate their employment contracts. While ContractPatch has moved slower than I would have liked (due to our prioritization of other urgent work), the initiative has shared good information, primarily via our talks and blogposts. I've been gratified to hear from folks that they've actually been able to negotiate better terms into their employment agreements as a result! Some have told us that they've succeeded in retaining their FOSS copyrights. Others have simply negotiated a better salary, as ContractPatch information improved their negotiation skills generally.

In the context of human rights, where FOSS licenses are unlikely to achieve the desired result, perhaps contractual demands by developers can succeed. I propose here a simple “contract patch” that can more successfully leverage developers' power in the market to prevent human rights abuses due to software.

Employees of all sorts face a difficult dilemma upon discovering unethical practices at their company. If the activity is already in advanced stages and/or the profit amounts generated from the practice are high, the employee's predicament becomes even more precarious. Should they report it to their manager or their manager's manager? If those managers all know about the activity already, will a complaint even be taken seriously? Often, the employee will have signed documents upon employment committing them to confidentiality, so the employee has little choice except to decide whether to quit or not but otherwise remain silent. For matters that concern the safety and well being of human beings, the stakes are much higher. Yet, employees have even fewer choices to ameliorate the situation. While most companies have whistle blower policies, the fallout of corporate politics can leave employees powerless.

What if those employees knew exactly how to handle the situation? What if the steps to escalate this situation were spelled out in advance? What if the employee were truly assured non-retaliation for reporting the situation? What if the employee were guaranteed a soft landing if they felt they needed to quit their job when the company took no action? In other words, what if these details appeared in their employment agreement and the employee knew they could rely on it from day one of their employment?

Amending Employment Contracts

With this in mind, we can draft a clause for employment contracts. Should an employee come to know that the company is committing violations of human rights, their employment agreement can specify the ways they can raise attention to this matter. Perhaps they first report the violation to their manager. If there is no satisfactory response or repair of the situation within a certain period of time, then the employee is to report the violation their manager's manager. If again there is no satisfactory response or action, the employee is to report the violation to the head of the department. If in that instance there is again no satisfactory response or action, the employee may post the violation on an internal mailing list or posting board. If again no action is taken, the employee may choose to terminate their employment and receive a pre-agreed severance amount — similar to the “golden parachute” provisions that executives have in their contracts. The company would also promise no retaliation against the employee for reporting the violation, including a non-disparagement provision that prevents the company from speaking negatively about an employee who opts for the severance. Each company could tailor the reporting chain to match what would make the most sense with their corporate structure. Nothing in the provision would undermine the company's confidentiality provisions with the employee, but the employee would have confidence in raising an alarm and also be able to quit while having a cushion to be able to look for another job.

Like most ContractPatch proposals, these approaches works best when the clause becomes standard. Companies are more likely to agree to these terms if many developers who interview ask for it.

This is a relatively simple solution — a good set of ContractPatch terms and a collective bargaining demand around it — is an outcome that companies can actually accept when the terms are reasonable. It protects the company's confidentiality and incentivizes employees to bring to management's attention problematic practices that the companies should have an interest in knowing about. Additionally, while the company and employee may disagree about the human rights implications of a problematic behavior, the ultimate negative result of the provision's operations is that the employee leaves the company, with a small, pre-agreed and easily budgeted financial settlement. In the case the employee is simply wrong about the alleged human rights violation, a voluntary exit is an obvious benefit to both parties. However, if multiple employees exercise this contract clause, the company then has a strong incentive to cease the violations, both financially and operationally. Alone one employee may not effectuate change, but standing together employees can have a powerful voice. Adding contract provisions like this one work within the existing corporate structure but amplify the impact that employees can have.

While I've focused my example on human rights violations, the provision could also cover endangering public health and safety or substantially violating the law.

The ContractPatch

Employment contracts often have provisions where the employee represents that they will obey laws and act ethically in the position. Here's an example of this kind of language I've seen in a contract:

Employee will act in an honest and ethical manner in compliance with all applicable laws … and comply with the policies, procedures, requirements, rules, and regulations promulgated at any time and as amended or supplemented from time to time by Employer … including Employer’s policies on sexual harassment …

Employment agreements are already the correct venue for these expectations. We can build on provisions like this to introduce the one I'm proposing here. The language itself could look like this:

“Human Rights Laws”) is defined as the United Nations Universal Declaration of Human Rights and any other applicable laws protecting the rights inherent to all human beings, regardless of race, sex, nationality, ethnicity, language, religion, or any other status.

An “Unethical Action” is defined as an action by Company that violates Human Rights Laws, excluding actions Company has taken against the Employee individually.

An “Adequate Response” is defined as a written response that (a) explains why there has been no Unethical Action, or (b) provides notice that the Unethical Action has ceased.

A “Planning Response” is defined as a written response that sets forth a plan to cease the Unethical Action.

Company shall act in an honest and ethical manner in compliance with all Human Rights Laws.

In the case that Employee becomes aware of any Unethical Action, Employee will report such action to their manager in writing as soon as is reasonably practicable. If Employee's manager does not provide an Adequate Response or a Planning Response within two weeks, Employee will send the report to their [FIXME - manager's manager/department head]. If [FIXME-title] does not provide an Adequate Response or a Planning Response within two weeks, Employee may report the Unethical Action via [FIXME - whatever relevant internal company-wide dissemination makes sense, whether it be an email list, posting board] (“Company Notice&Rdquo;). Employee may also provide a Company Notice in the case that the Employee has received a Planning Response but no Adequate Response is received within the period set forth for repair in the Planning Response. If the Employee receives no Adequate Response or Planning Response to a Company Notice within two weeks, Employee may terminate their employment and receive an amount equal to the greater of (i) twelve (12) weeks severance pay or (ii) twice the amount required by any relevant applicable law or statute. Company will not retaliate, intimidate or harass any Employee who reports an Unethical Action. If Employee's employment is terminated for any reason after Employee first reported the Unethical Action, Employee shall receive an amount equal to twelve (12) weeks severance pay. Nothing in this provision contradicts, supersedes or diminishes Section [FIXME-CONFIDENTIALITY] of this agreement. However, if Employee terminates their employment pursuant to this provision, Company will not engage in any disparagement of the professional or personal life of the Employee.

This text is a first draft and edits and suggestions are welcome on the Contract Patch mailing list .

No software developer expects to encounter human rights violations or unlawful activity using software when they take a new job. But history shows that it will and does happen; Coraline's talk is an excellent list of known examples. Introducing new clauses into employment contracts is a practical way to align the interest of all parties, while providing simple mechanisms to raise attention to and end problematic behavior. Developers usually have more bargaining power than most workers. Let's use that to make sure we compel our employers to behave ethically and provide us the safety to stop providing them with our services if they don't!

[1] While I'm a lawyer and many of the people who have worked on ContractPatch are lawyers, Conservancy doesn't provide legal advice and so ContractPatch isn't meant as legal advice. Please use the language as a starting point or as an example for you to work on with your own lawyer to figure out what works for your situation.

Software Freedom Conservancy is in the middle of its annual fundraiser. Please help us continue our work by becoming a Supporter. Donate now and have your donation matched by a group of generous individuals who care deeply about software freedom.

[permalink]

Tags: ContractPatch

ContractPatch: Supporting Maintainers in Employment Agreements

by Karen Sandler on December 19, 2019

Since we've launched ContractPatch, I've heard a lot of feedback from free software contributors about the successes they've had in negotiating their employment agreements. While not everyone has achieved full modification to the agreement, so far everyone who's reported back had a positive experience negotiating and many have been able to introduce improvements into their contracts. As we've mentioned before, generally employers won't give you something unless you ask for it and generally agreements are negotiable. As a developer or other contributor, you often know what your FOSS project needs better than your employer does even though they may depend on that project.

Recently, I was discussing this with a CEO of a company that (like many) depend on free and open source software for their business to succeed and he was kind enough to send me an example of one of the free software specific provisions that they included in their contract with an employee. The employee is a developer who maintains an important project, and was its maintainer even before the company's founding. This provision gave the employee confidence that they could continue their work for the project. Furthermore, this provision clearly demonstrates the company's commitment to support the project.

This part of the contract says:

For 10 hours each week, you will be free to continue your work as the [PROJECT] maintainer. The tasks you work on will be at your discretion, and you will hold the copyright to that work, so long as it is released under [COPYLEFT LICENSE]. For the remaining 30 hours per week, you will work at the direction of [COMPANY].

While the provision could certainly go farther in favor of the employee¹, this provision clearly declares the intention of the company with respect to the employment relationship. The employee gets to choose how best to maintain and improve the free software project unfettered by the needs of their employer and also knows how much time is reasonable for them to use during work hours. Additionally, the provision allows the employee to keep their copyrights, which given the copyleft license, empowers the employee going forward and underscores the company's intention to stay in compliance with its license obligations. This provision is strong, but the contract could also address a procedure or process for how to handle a situation where the interests of the company and the interests of the project conflict. For example,they could also include a term that indicates the employee should mark the contributions during those 10 hours in some way, such as by using a personal address in all those Git commits. There are a range of provisions that employees already have in their contracts to help their free software work, this is just one example of a provision that is in effect for an employee right now.

Many free software contributors take jobs with the unwritten understanding that they will be able to continue working on their long-time free software projects. As Bradley quoted from the old telephone commercials on our FaiF episode that announced ContractPatch: “put it in writing!”. Without having that written agreement with their employers, employees find later that expectations can change. Managers change; companies get acquired; and, sometimes, what's promised on the interview just never turns out as expected! Often higher level management understands the importance of having an employee working on the free software projects that the company needs, but shifts in middle management can easily break that focus. Employees then may not feel comfortable escalating the problem. Ultimately, that results in decreased employee satisfaction and allows short-term quarterly goals of the company to take precedence over the free software projects that the company needs for long-term profitability. Explicitly giving the “freedom to FOSS” in employment contracts both provides long term benefits to all parties and brings sustainability to FOSS.

¹ For example, the employee in question sometimes spends more than 10 hours on behalf of the project and has considerable leeway to exercise their judgement for the process in the course of their employment

[permalink]

Tags: ContractPatch