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

Adventures with Proprietary Software in Disneyland

by Karen Sandler on December 2, 2019

I'm not a big fan of Disney - I don't like the impact the company has had on copyright or the social messages that they have insinuated over the years. But I have little kids and when I was in the Los Angeles area I knew I had to take them to Disneyland. I have happy childhood memories myself of a visit there. Like my mother did when I was young, I researched everything I could about how to make the trip the most enjoyable for my kids. I planned out a route to get to the rides, what we would likely eat, even what my kids would wear. I noticed that the tickets that I got came with the ability to skip some of the lines. In order to use that part of the tickets, you had to download the Disneyland app.

If you're reading this, you probably know that I avoid as much proprietary software as I can. I have a heart condition and a technical background, so that when doctors prescribed a pacemaker/defibrillator, I was appalled not to have any ability to look at the software that was to be sewn into my body and attached to my heart. I didn't have much choice but to get the device but I have been passionate ever since about making sure our software is safe and ethical. At first I was concerned with the transparency of the software and making sure it could be reviewed. Then as I lived with my device I encountered times where I realized that my device wasn't designed exactly for me. Through no ill will of my device manufacturer, I was getting unnecessary and unwanted treatment, and the only way to deal with it was to take drugs to slow my heart rate down. I realized that this was a spot-on just a really good example of how well-intentioned manufacturers could simply not anticipate all of the use cases for their product. These experiences have made me passionate about software freedom and our ability of us -- as the public technology users and consumers -- to have fundamental control of our technology in a practical and meaningful way.

Now because of all of this, I'm all about using only free and open source software whenever I can. I'm as "pure" as one can be about avoiding proprietary software while still getting things done for myself in the world - I have to use proprietary java script when to book a flight or interface with my bank, for example but otherwise I simply avoid it. So when I was getting ready for Disneyland, I was disappointed to see the app referenced but I figured I'd just complain at the park but have my husband use his phone to down load the app so that I'd make the point but also make an exception for this special occasion and one-time use (I believe getting someone else to use proprietary software or do anything else you'd morally avoid specifically for your benefit is basically the same as using it yourself.

Arriving at the park was so magical for my kids. We got there right when the park opened and the line was minimal to get in. There were many Disney characters for them to take pictures with. And then, when we started to embark on our planned out day of rides and adventures, we realized: my husband's phone was too old to download the app. The lines on some of the rides were already starting to form and it began to set in that even though we theoretically had the ability to skip some of those lines, we were going to be unable to do it. I cannot describe to you the sinking feeling I had when I realized that I had spent a ton of money to make my little kids stand in long lines doing nothing for a large part of what was supposed to be such a special day, all because of my desire to avoid proprietary software. I had let them down. After spending so much time making sure I was prepared to maximize the day, I was so embarrassed and upset. My face literally went red.

Now, I'm a lawyer and a software freedom advocate. I'm an Executive Director! I pulled myself together and marched over to the customer service people. If you watch the Good Place, these women looked and acted an awful lot like Janet. I explained to them what had happened - that we'd purchased the tickets that we learned had line skipping ability, that I don't use proprietary software and my husband's phone was too old for the app. We had no way to access this feature. The Janets were nice but puzzled. They had not had anyone complain about this before and had never considered that this could happen. But ultimately they understood my problem.

Disneyland is a huge expense. It's a lot of money to get in, and there are tons of additional things you can buy presenting themselves attractively to your children at all corners. While the staff is really nice about not upselling you, it's hard not to feel very self conscious about money while you are there. The less money you have the more dear it is to you to make the most of this special splurge. And it's embarrassing to admit that your phone is so old that you can't even download a "free" app.

The Janets were lovely and were able to attach a few special passes on our tickets that allowed us to skip certain lines in a different way and then gave us advice on where we should use them to best maximize our time in the park, so my story had a happily ever after that day. But the implications of that experience were haunting.

While surely Disney wants visitors to Disneyland to spend as much money as possible, it was clear to me they'd taken care to make sure that there were ways for people on a budget to have a good experience - you can plan to bring your own food into the park, if you try to buy something without specifying you want a larger size or special version they assume you want the basic option without asking, and the workers will take pictures of you with your own phone so that you don't have to purchase their professional photos. But the technology wasn't designed with that care. Poor people with old phones would have to walk up to customer service and confess in front of their children and anyone else around that they couldn't afford a more modern phone to find out whether or not there was another option to skip the lines. I don't think most people would do that. They would just spend a large part of the day waiting miserably in lines that more well off people would easily skip.

While there's hopefully nothing life or death about going to Disneyland, it was a profound example about how our technology is being created with inequity baked into its very design. I wanted my children to have a good time that day so badly, and I had spent so much money to even get there, that it was an emotional experience even for a skeptic like me to feel like the experience we had looked forward to was being yanked away. When companies incorporate proprietary software into their basic products, services and experiences it becomes much more likely that this will be the effect. Richer people using new proprietary software never even realize this as they used technology they considered available to all.

We must be more thoughtful and resist incorporating technology carelessly into more and more aspect of our lives. We must embrace the fact that the creators of any technology cannot anticipate every possible customer or use. We must insist that when we do require the use of software that we provide fundamental control for it to be changed by those users who haven't been anticipated (or by someone working to help those users down the road). The only way to be sure that there is no ultimate inequity is by making sure there are easy "analog" alternatives to technological solutions for every day activities, and to make sure that software is free software as often as possible so that software can be adjusted when people need it to be, especially those who are most vulnerable.

[permalink]

Tags: software freedom for everyone

Microsoft & exFAT: One Step on a Long Journey

by Karen Sandler on August 30, 2019

In 2013, Conservancy helped resolve a GPL violation by Samsung which arose primarily due to complications around Microsoft's patent holdings related to the exFAT filesystem. At the time, Microsoft was known for demanding patent fees from Linux users and redistributors.

Late last year, Microsoft joined Open Invention Network. As we wrote at the time, this action had limited impact, as key patents like exFAT were not implemented in any packages that were part of OIN's “Linux System Definition”. We asked Microsoft at the time to upstream the exFAT code under GPLv2-or-later to confirm its intention to end patent aggression.

This week, in response to recent follow-up requests from upstream Linux developers, Microsoft announced that they would sign off on inclusion of exFAT in upstream Linux. This is the first step toward real patent peace related to exFAT.

This process for exFAT will only complete once all of the following happen: the exFAT patch appears in an official Linux release, that official Linux release becomes part of OIN's Linux System Definition (this generally happens automatically, as future versions of Linux are included by default), and Microsoft distributes a copy of Linux themselves that contains this technology. This last step is critical, as the OIN patent license is not as comprehensive as a full patent license from Microsoft. Any participating company can withdraw at any time from OIN¹ (and there have been several withdrawals in the past, including Oracle, Facebook, HP and Symantec). After a transition period, the safety of OIN's non-aggression pact weakens. In contrast, when a company distributes software under the GPL, there is an irrevocable implicit patent license with the distribution, and GPLv2§7 further assures patent licensing safety.

Eventually, Microsoft will likely distribute a version of Linux containing exFAT to its Azure users and in its Windows Subsystem for Linux. However, until that occurs, the issue is not really resolved. An expedient solution is as we previously requested: that Microsoft bring definitive patent safety to free and open source software by publicly granting a permanent patent license for all patents Microsoft holds that read on Linux. Additionally, we invite Microsoft to keep pace with its peers such as Google and Red Hat, who years ago made very public patent promises to FOSS users. While the actions taken thus far are intermediary steps, I applaud Microsoft's journey from being a company that long attacked FOSS to becoming a contributor.

¹ The legal mechanism for withdrawal is exercise of a “Limitation Election” in the OIN patent license agreement.

[permalink]

Tags: conservancy, patent, law

Thoughts on IBM’s acquisition of Red Hat

by Karen Sandler on October 31, 2018

There’s been quite a stir in our communities following the announcement that IBM is acquiring Red Hat. As I considered the announcement, one part of the email to employees by Jim Whitehurst posted on the Red Hat blog really struck me:

I appreciate that everyone will experience a range of emotions as a result of this news. Excited, anxious, surprised, fear of the unknown, including new challenges and working relationships - these are all ways I would describe my emotions. What I know is that we will continue to focus on growing our culture as part of a new organization. We will continue to focus on the success of our customers. We will continue to nurture our relationships with partners. Collaboration, transparency, participation, and meritocracy - these values make us Red Hat and they are not changing. In fact, I hope we will help bring this culture across all of IBM.

In addition to the normal anxiety, surprise and fear experienced by employees of companies in the wake of an announcement of a merger, takeover or ordinary reorganization, this transaction will also reverberate through the community outside of the company. Free software contributors across many communities and industries are feeling some of the same apprehension and unease that ordinarily would be reserved for employees.

I wish IBM and Red Hat luck, and I’m optimistic that the partnership will yield good things for both companies and their employees. I hope that following the acquisition, Red Hat is able to maintain its special relationship to the free and open source communities it shepherds, and that its employees continue to feel empowered to support critical free software solutions in a community-focused way. I also hope that in its announcement to keep Red Hat its own unit within IBM is an indication of IBM’s support of Red Hat’s unique business and that the deal does wind up bringing that culture to more of IBM. While some folks at IBM are important contributors to free software, IBM’s is primarily a culture of proprietary software and Red Hat’s is one of open source, so in my view this solution is likely to yield the most success anyway.

I’ve heard people imagining the best from this deal, and also people imagining the worst. The one thing everyone can agree on is that there’s a lot of uncertainty, despite whatever reassurances are contained in corporate messaging. Because of this, I think it’s a good time to remind everyone of the ways we can protect ourselves now and in the future from these kinds of uncertainties related to changes in ownership, structure or motivations of corporate players in free and open source software:

• Use copyleft. Quite a lot of the software projects that Red Hat plays a critical role in are licensed under a version of the GPL. When we use strong copyleft we set the ground rules for corporate actors to participate with each other and with the public. We get a level playing field and assurance that companies will be less incentivized to go their own way. (We also get other good benefits like the right to the source code, allowing us to be in control of the technology we rely on.)

• Support strong charities. Nonprofits, and in particular charitable nonprofits, keep the community’s interests at the forefront. They can serve as copyright aggregators in a more trusted way, facilitate cooperation of different stakeholders and function in a variety of ways to forward the long term interest of software freedom. The more we invest in our critical foundations, the less vulnerable we are to changes in corporate actors. The stronger foundations like GNOME, Conservancy and the FSF are, the easier it is for communities to weather a new direction from a prominent company.

• Encourage diversely held interests. Making sure that interests are not aggregated in single for-profit actors insulates communities against a change in ownership of a company. For effective success in using copyleft, copyrights must not only be with for-profit companies but have substantial copyright holding from charities and individuals. Also, technical leadership should include actors from different types of entities. When copyrights are held by many actors in the field (or by charitable nonprofits), it’s much harder to relicense projects as proprietary or on otherwise less ideal terms, and copyleft enforcement is a community-driven rather than for-profit activity. When care of the technical direction of a project isn’t significantly concentrated in one company, free software projects are more robust. Development may be slower with community-led contribution, but we can have greater confidence about the stability of the project and the community.

The interests of companies are not always aligned with the free software community or the public. Companies that seem to be in one stable condition today may change dramatically tomorrow. While I expect Red Hat to flourish under IBM ownership, the acquisition is a good example of the kinds of changes we must be prepared for down the road, whether it be with Red Hat or any of the other companies on which we’ve come to rely.

[permalink]

Tags: conservancy, GPL