Displaying posts by Karen Sandler
ICYMI: “Companies, Free Software, and You”
byon December 8, 2016
At this year’s LibrePlanet, I presented “Companies, Free Software, and You” as a keynote presentation. In the talk, I take a hard look at companies’ engagement in the free software community, dissecting which contributions are productive and weighing them against instances where their interests might diverge from the rest of the community’s.
When that happens, Conservancy is a strong independent voice fighting for the community’s interests, in project leadership, employment agreements, license compliance, and more. Please support Conservancy today to keep the conversation balanced!
Thanks to the Free Software Foundation for running another great conference and preparing this video! Both the talk and the recording are released under CC BY-SA 4.0.
See you at OSCON EU!
byon October 14, 2016
My bag is almost ready to go - I'm heading to London for OSCON EU. The conference days are going to be packed.
On Monday I'm giving a talk about enforcement worldwide at 1:35 in the Buckingham Room. I'll be giving attendees an inside look into what legal actions are happening where, how they impact compliance and what the impact of this may be for free software down the road.
I'm especially excited to deliver a keynote on Tuesday morning, where I'll explore software freedom ideology, and whether it makes sense to think of free and open source software as a social justice issue. There are obviously so many critical issues like hunger and human trafficking that software freedom cannot equal in importance. After struggling for a long time to reconcile ideological rhetoric with this reality, I've concluded that software freedom is a threshold issue. If we hope to solve our biggest social problems, we'll need software and if that software is not free and open, it is much less likely to be effective in the long term. It's become apparent to me that software freedom underlies our ability to effectively solve any social problem.
Throughout the conference, Conservancy will also have a booth in the expo pavillion. We'll have Conservancy stickers, Outreachy flyers and enthusiastic encouragement for you to become a Supporter if you can. Please stop by and say hi!
ContractPatch, Step 2: Understanding the power balance
byon September 26, 2016
Employment agreements are one of the things that I'm asked the most regularly about in the free and open source software world, almost rivaling questions about licenses. My responses have always been the usual lawyerly responses of This Is Not Legal Advice and while I Am A Lawyer, I Am Not Your Lawyer (I'm generally not acting as a lawyer on behalf of Conservancy as its Executive Director either). But even from my early days of being involved with free software, I have seen that there's a lack of understanding about employment agreements and the ability of employees to get their agreements modified. Last month, Fred announced a new initiative that we are working on together, called ContractPatch. With ContractPatch, our goal is to help provide knowledge to employees, along with sample language for better contract terms. The first step in this process is understanding the dynamics at work in employment arrangements. Step 1 is knowing that everything is negotiable and step 2 is knowing where you stand in the negotiation. Quite simply, you likely will never have as much power as you do the moment just before you sign your employment agreement.
At the point you are presented with a job offer, your prospective employer really wants to hire you. Chances are, they've screened and interviewed a number of candidates and put a lot of work into the process. Your manager has thought deeply about who they want in the position and has probably imagined how it will all work out with you in the role. Both you and the hiring decision-maker(s) are probably very optimistic about what you'll accomplish in the role and how well you'll get along working together. At this point, no one wants to go back to the drawing board and start the process over again. You will be excited to start the new job but it's worth taking a step back to appreciate the unusual position you are in with your new employer.
As part of the hiring process, you'll be expected to negotiate your salary (this can be complicated) and finalize all of the terms of your employment. Terms of employment can also be looked at through the lens of compensation, and asking for more favorable terms in your employment contract can be another kind of perk an employer can give you if they have a tight budget. A classic contract negotiation tactic (I even learned this in law school) is to make an agreement stronger in the first draft than you really need it to be, just so that you can give something away when pushed. This is certainly true of many company's standard agreement templates. The only way to find out is to ask.
Once you take the job, it's harder to change your terms of employment (though it's possible, as we'll cover later). Think hard about the long term impact of signing the agreement and whether things could happen down the road that would make you feel less comfortable with working under those terms. We'll be giving you some examples of situations you want to be prepared for when we talk about specific contract provisions.
Asking for more favorable terms doesn't have to be an adversarial process. You can ask for an agreement to be amended in a friendly way. Employers often respect workers more when they advocate for themselves.
So, we'll help you think about how to engage with your employer while anticipating things that could go wrong down the road and how to ask for more favorable terms. You can sign up for our mailing list to be part of the conversation. While it may be easier to avoid negotiating your agreement, don't trade short term comfort for your long term benefit.
Comments on OpenChain Specification
byon June 6, 2016
Today I submitted comments to the OpenChain specification. OpenChain is a working group formed under the Linux Foundation by companies to collaboratively come up with standards and shared materials around compliance. As community-oriented GPL enforcers, we applaud efforts to improve compliance and have been following the effort with interest to the extent we can with our limited resources. The working group recently put out a public call for comment on the OpenChain specification, which is open until June 17. We encourage people to take a look, perhaps echo our comments if they agree, and even join the calls if they are interested (there's a call today).
Here are the comments I submitted:
- I think text should be added in the introductory section about the value of compliance, generally. Perhaps something like:
Complying with the terms of the free and open source licenses used in industry is not only important for minimizing risk to individual companies, but is also a necessary step towards the preservation, collaboration and improvement of the software infrastructure we all rely on.
- Text should also be added to clarify that completely following the spec does not guarantee full compliance and that the (obvious) intention is that companies need to tailor the guidelines to their own procedures. I think this would fit well in the second to last paragraph on page 3 and perhaps should also be added to G6.1.
- In the definitions, I think the term
OpenChain Compliantis confusing, and can be fixed by using a term other than
compliant. We don't want people to think that following these recommendations is any attestation as to actual compliance (though of course I agree that they will help if followed fully). Calling it
OpenChain Accordantwould work, for example.
- G4.1 should refer to
complete and corresponding source codeinstead of just
- Also in G4.1, a bullet point should be added saying
scripts used to control compilation and installation, as per GPLv2 Section 3 and GPLv3 Section 1 (we may also want to include some reference to this in G3.2, along with a reference to complete and corresponding source code as well). Even though scripts are included in CCS under GPL I think it makes sense to give this its own bullet point to highlight the requirement which is sometimes overlooked. GPLv2 and GPLv3 ensure not only that users receive software freedom in the abstract, but have the technically necessary information to make practical use of those freedoms. Ability to rebuild the binaries from source code, and knowing that everything necessary to produce the binary are present is what matters most in copyleft compliance (this is why, for example, copyleft and security go hand in hand).
- In G5.2, it may be appropriate to recommend considering a Code of Conduct for a company's participation in any community (right now the language is weak anyway and says
might include). This is becoming increasingly common in companies, as I understand it, as a way to limit liability for inappropriate communications by employees in the public and is something they should actively consider.
These comments, like all contributions to OpenChain, are under Creative Commons CC0 1.0 Universal license.