Employment agreements for free-software developers

At OSCON 2016 in Austin Texas, Karen Sandler of the Software Freedom Conservancy (SFC) spoke about an issue that impacts an ever-growing number of free-software developers: employment agreements. As the number of paid contributors to free-software projects grows, so do the complications: copyright assignment, licensing, patents, and many other issues may be codified in an employment agreement, and a developer who fails to consider the implications of an agreement's conditions may be in for an unpleasant surprise years down the road.

Sandler kicked off the session by acknowledging that reading through agreements and contracts is boring stuff. "It's such a drag, I know. Legal stuff is boring, and this is boring even for me. But we have to do it." You only get one chance to sign your employment agreement, she said, but even if you only plan to stay for a year, the terms and conditions included can affect you and your ability to work on free software for many years to come. That is because an employment agreement not only establishes the relationship between the employee and the employer, but it establishes how the employee will make their contributions to free-software projects. For developers who care about their contribution to the free-software community, the details of the agreement can be significant.

We live in an age where we are constantly having to agree to more and more terms-and-conditions documents, Sandler said, to the point where no one has sufficient time to read them all. Employment agreements are different, though: you are not a consumer when you sign one, you are an employee. And your agreement is unique to you; it is not a blanket set of terms-and-conditions. Even if you sign a boilerplate agreement identical to everyone else's in the company, that class of "employees" is much smaller than the class of "consumers" or "customers" addressed by a public click-through license.

You therefore have—and should use—the power to negotiate with the company for what matters to you. Immediately after signing, a power shift occurs, but at the end of the hiring and interview process, the job candidate is in the best possible position to ask for changes to the agreement. Far too many developers never ask for any changes to their agreement, Sandler said, either assuming them to be non-negotiable documents or presuming that everyone in the company has the same agreement. Neither assumption is true; companies "ask for the world" up front, because it is in their best interest, but the clauses and conditions in an employment agreement are almost always malleable and should be just as much a part of the negotiation process as compensation.

Thus, she said, you are not "being paranoid" to read through a potential agreement. The best move is to have a lawyer review the agreement, but at the very least, educating yourself about the potential issues can enable you to spot areas of concern.

The first step is to evaluate your priorities, Sandler said. For many free-software developers, those priorities may be the licensing and patenting of code developed as part of the job, but the goal is for the potential hire to determine what is crucial and what is negotiable, then to examine the agreement. It is also vital, she said, to review all documents related to the potential job, because they may interact with each other. Other documents like contributor license agreements (CLAs) or copyright assignment documents may not be part of the employment agreement itself, but can make a big impact.

Provisions

Sandler then walked the audience through a list of key provisions to look out for. First and foremost is probably the licensing of the software created on the job. The assumption for the OSCON crowd is that the employee will be working on free software and, therefore, the agreement will state that the employee's work will be released under a free-software license, but Sandler reminded the audience that this needs to be in writing to be enforceable. A "general understanding" that the job will entail working only on free software is insufficient—what happens, she asked, if a new manager comes in, the original project is canceled, or if the whole company is acquired?

Furthermore, many free-software developers hired on at companies are hired to work on existing projects (perhaps even projects that they already contribute to). So it is important to verify that the licenses described meet the project community's expectations. Companies new to free software may have a misunderstanding about what licenses are acceptable. Some agreements might be drafted by someone who does not even realize that the employee is coming on board to work on free software, and default to an "everything is proprietary" clause.

A related concern is who owns the copyright on the employee's code. In proprietary software shops, this is not an issue, but more and more free-software developers are demanding that they personally retain their copyrights, she said. Contributions to free-software projects are important to building one's reputation and to accumulating a body of work to show other employers. In an era when many people change employers several times while working on the same code base, she said, it can impede a developer's career for an employer to be the copyright holder for some (or all) of the developer's software.

The scope of employment is another major provision to look out for, Sandler said. She referred the audience to a plot line in HBO's sitcom Silicon Valley that hinged on a company's draconian employment agreements claiming the rights to everything the employees create. In many jurisdictions, such clauses are regarded as unenforceable, but free-software developers may have a harder time establishing which jurisdiction they work in. They may work remotely, or even move around regularly—in which case the local laws, in addition to the jurisdiction expressed in the agreement, can come into play.

It is also vital to many free-software developers to establish that they can contribute to outside projects in their free time. "Exclusivity" clauses are therefore problematic. Furthermore, many employees may accept a given salary with the expectation that they will be allowed to consult on the side or do other freelance work; if the agreement claims exclusivity, this could be disallowed.

Along those lines, employment agreements should also be clear on the status of pre-existing code. If an exclusivity clause makes it impossible for the employee to fix bugs on software they have already written, it could be detrimental.

Free-software developers will also want the nature of public communications to be clearly defined. Because contributions are expected to be made in the open, the agreement should clarify when developers speak or post as themselves and when their communication is deemed to speak for the company. If the employer requires that blog posts, tweets, or emails must be approved by the company in advance, Sandler said, it is a good idea to ask what that process is like.

Patents are another serious topic to consider, since so many in the free-software community have an ideological objection to software patents. Sometimes there are hard-to-miss red flags, such as a "patent wall" at the entrance to the building, but the issue can be subtler. It is vital for concerned developers to ensure that the employment agreement is clear about whether they would be required to file for patents on inventions, or if they would be encouraged to through bonuses and promotions. If the company has a patent portfolio, the employee may also want to ask about its patent-licensing policy. Participation in something like the Open Invention Network (OIN) may be a positive sign—though, she cautioned, OIN's patent pool does not cover every patent, and it does not preclude other negative outcomes like patents being sold to third parties like patent trolls.

Last on the list, Sandler advised looking out for "non-compete" clauses, particularly those that bar "conflicting employment" and could prohibit the employee from working at the job that they consider their key skill set. Employees should push back, noting that an agreement that bars them from working as a software developer later could be ruinous to their career. Here again, companies almost uniformly ask for expansive terms in the agreement, but there is almost always room for bargaining.

Asking questions

It never hurts to ask questions or to ask for changes in an employment agreement, Sandler said. Typically there is room for compromise; she told the audience that she has never worked on an employment agreement negotiation where no changes were made. An audience member asked about non-compete clauses, which are often vaguely worded and broad. Sander replied that it is worth asking "what is it that you really want to prevent?" It may be that the company is only worried about losing employees to some specific competitor, in which case it might be worth renegotiating the clause to be more specific.

Just as there is no harm in asking the company "am I understanding this clause correctly?," Sandler said, there is no harm in asking for enough time to review the agreement in detail. Even if a company asks for an answer the same day, it will likely provide a few days if the developer indicates a desire to read over the provisions in detail. After all, once a job offer is made, the company has decided that it wants to hire the candidate.

She also told the audience to be sure that they keep track of employment agreements after signing them—even after they have moved on to another job, some provisions could still come into play. There have been developers, she said, who raised questions about copyright assignment long after the work was done, and not being able to produce a copy of the employment agreement as evidence can be a serious problem.

Although it is best to renegotiate the clauses of interest (or to get "riders" attached to the employment agreement), she said, sometimes it might not be possible to have changes made, and the informal agreement between the new hire and a manager about the potential job may be all that there is. In that case, she said, if the manager in question actually has the authority to make decisions about copyright assignment, licensing, and so forth, the best thing for the employee to do is to write down the understandings agreed upon and get a confirmation, in writing or email, from the manager that the two parties are on the same page. In may not have the same weight as a formal contract, but it is better than memory alone.

Moving forward

Employment agreements are still a rarely discussed topic in the free-software world but, as Sandler pointed out, the growth of commercial investments in free-software projects is making them more and more important. She ended the session with two tidbits about where matters may head in the future.

First, SFC is working on creating a set of resources for developers and companies to use when crafting employment agreements. Though not ready for publication yet, the concept is to publish a suite of "standard" clauses covering provisions of interest to the free-software world. They would make it easier for developers to propose the changes that they want in agreements, and could even be useful for companies in the long term. If the standard clauses became popular references, a company could specify that it offers "clauses two, five, six, and nine" unambiguously (a bit like the way Creative Commons licenses have standardized certain copyright clauses).

Finally, Sandler told the attendees that "we can create a culture shift" by actively pushing for the provisions that matter in our employment agreements. If even ten percent of developers asked to retain the copyrights on the software they create, Silicon Valley will take notice, she said. Allowing developers to hold their own copyrights might not become the default position in employment agreements, but companies will recognize that it has value and will begin offering it as a benefit. Software is a competitive business, she said; free-software developers have the ability to influence it by raising the ideological issues they care about when negotiating with new employers.