Conservancy Blog

Displaying posts tagged conservancy

Why You Should Speak At & Attend LinuxConf Australia

by Bradley M. Kuhn on August 4, 2016

Monday 1 February 2016 was the longest day of my life, but I don't mean that in the canonical, figurative, and usually negative sense of that phrase. I mean it literally and in a positive way. I woke up that morning Amsterdam in the Netherlands — having the previous night taken a evening train from Brussels, Belgium with my friend and colleague Tom Marble. Tom and I had just spent the weekend at FOSDEM 2016, where he and I co-organize the Legal and Policy Issues DevRoom (with our mutual friends and colleagues, Richard Fontana and Karen M. Sandler).

Tom and I headed over to AMS airport around 07:00 local time, found some breakfast and boarded our flights. Tom was homeward bound, but I was about to do the crazy thing that he'd done in the reverse a few years before: I was speaking at FOSDEM and LinuxConf Australia, back-to-back. In fact, because the airline fares were substantially cheaper this way, I didn't book a “round the world” flight, but instead two back-to-back round-trip tickets. I boarded the plane at AMS at 09:30 that morning (local time), and landed in my (new-ish) hometown of Portland, OR as afternoon there began. I went home, spent the afternoon with my wife, sister-in-law, and dogs, washed my laundry, and repacked my bag. My flight to LAX departed at 19:36 local time, a little after US/Pacific sunset.

I crossed the Pacific ocean, the international dateline, left a day on deposit to pickup on the way back, and after 24 hours of almost literally chasing the sun, I arrived in Melbourne on the morning of Wednesday 3 February, road a shuttle bus, dumped my bags at my room, and arrived just in time for the Wednesday afternoon tea break at LinuxConf Australia 2016 in Geelong.

Nearly everyone who heard this story — or saw me while it was happening — asked me the same question: Why are you doing this?. The five to six people packed in with me in my coach section on the LAX→SYD leg are probably still asking this, because I had an allergic attack of some sort most of the flight and couldn't stop coughing, even with two full bags of Fisherman's Friends over those 15 hours.

But, nevertheless, I gave a simple answer to everyone who questioned my crazy BRU→AMS→PDX→LAX→SYD→MEL itinerary: FOSDEM and LinuxConf AU are two of the most important events on the Free Software annual calendar. There's just no question. I'll write more about FOSDEM sometime soon, but the rest of this post, I'll dedicate to LinuxConf Australia (LCA).

One of my biggest regrets in Free Software is that I was once — and you'll be surprised by this given my story above — a bit squeamish about the nearly 15 hour flight to get from the USA to Australia, and therefore I didn't attend LCA until 2015. LCA began way back in 1999. Keep in mind that, other than FOSDEM, no major, community-organized events have survived from that time. But LCA has the culture and mindset of the kinds of conferences that our community made in 1999.

LCA is community organized and operated. Groups of volunteers each year plan the event. In the tradition of science fiction conventions and other hobbyist activities, groups bid for the conference and offer their time and effort to make the conference a success. They have an annual hand-off meeting to be sure the organization lessons are passed from one committee to the next, and some volunteers even repeat their involvement year after year. For organizational structure, they rely on a non-profit organization, Linux Australia, to assist with handling the funds and providing infrastructure (just like Conservancy does for our member projects and their conferences!).

I believe fully that the success of software freedom and GNU/Linux in particular has not primarily come from companies that allow developers to spend some of their time coding on upstream. Sure, many Free Software projects couldn't survive without that component, but what really makes GNU/Linux, or any Free Software project, truly special is that there's a community of users and developers who use, improve, and learn about the software because it excites and interests them. LCA is one of the few events specifically designed to invite that sort of person to attend, and it has for almost an entire generation stood in stark contrast the highly corporate, for-profit/trade-assocation events that slowly took over our community in the years that followed LCA's founding. (Remember all those years of LinuxWorld Expo? I wasn't even sad when IDG stopped running it!)

Speaking particularly of earlier this year, LCA 2016 in Geelong, Australia was a particular profound event for me. LCA is one of the few events that accepts my rather political talks about what's happening in Open Source and Free Software, so I gave a talk on Friday 5 February 2016 entitled Copyleft For the Next Decade: A Comprehensive Plan, which was recorded, so you can watch it, or read the LWN article about it. I do warn everyone that the jokes did not go over well (mine never do), so after I finished, I was feeling a bit down that I hadn't made the talk entertaining enough. But then, something amazing happened: people started walking up to me and telling me how important my message was. One individual even came up and told me that he was excited enough that he'd like to match any donation that Software Freedom Conservancy received during LCA 2016. Since it was the last day of the event, I quickly went to one of the organizers, Kathy Reid, and asked if they would announce this match during the closing ceremonies; she agreed. In a matter of just an hour or two, I'd gone from believing my talk had fallen flat to realizing that — regardless of whether I'd presented well — the concepts I discussed had connected with people.

Then, I sat down in the closing session. I started to tear up slightly when the organizers announced the donation match. Within 90 seconds, though, that turned to full tears of joy when the incoming President of Linux Australia, Hugh Blemings, came on stage and said:

[I'll start with] a Software Freedom Conservancy thing, as it turns out. … I can tell that most of you weren't at Bradley's talk earlier on today, but if there is one talk I'd encourage you to watch on the playback later it would be that one. There's a very very important message in there and something to take away for all of us. On behalf of the Council I'd like to announce … that we're actually in the process of making a significant donation from Linux Australia to Software Freedom Conservancy as well. I urge all of you to consider contributing individual as well, and there is much left for us to be done as a community on that front.

I hope that this post helps organizers of events like LCA fully understand how much something like this means to us who run a small charities — and not just with regard to the financial contributions. Knowing that the organizers of community events feel so strongly positive about our work really keeps us going. We work hard and spend much time at Conservancy to serve the Open Source and Free Software community, and knowing the work is appreciated inspires us to keep working. Furthermore, we know that without these events, it's much tougher for us to reach others with our message of software freedom. So, for us, the feeling is mutual: I'm delighted that the Linux Australia and LCA folks feel so positively about Conservancy, and I now look forward to another 15 hour flight for the next LCA.

And, on that note, I chose a strategic time to post this story. On Friday 5 August 2016, the CFP for LCA 2017 closes. So, now is the time for all of you to submit a talk. If you regularly speak at Open Source and Free Software events, or have been considering it, this event really needs to be on your calendar. I look forward to seeing all of you Hobart this January.

[permalink]

Tags: conservancy, GPL, supporter, conferences

ContractPatch, step 1: Everything Is Negotiable.

by Fred Jennings on August 4, 2016

About a year ago, I got talking with some friends in the tech industry about contracts. And it began to sound like something was very, very wrong.

Working informally through personal networks of engineers, project managers, freelance designers, and many more, I ended up with a small horde of employment contracts, offer letters, work agreements, and all manner of other documents that fall under that umbrella term, “contracts.”

And almost all of the contracts were bad.

Not badly written, though some were. Not legally unenforceable, though some were.

They were bad for the people who signed them.

They waived important legal rights, gave the employer ownership of ideas and projects it had no reason to take, or imposed serious limits on future work.

And people often didn’t realize how bad these were, the risks they’d agreed to, or what rights they’d given up.

Among the few who did, most didn’t realize they could negotiate these terms. Others did, but weren’t sure how to start. Several assumed their employer wouldn’t enforce the more onerous terms.

Nobody should bet their future on that assumption. Doing so is to build one’s career on a house of cards.

But that won’t change until enough people speak up and push back, and have the tools to do so.

That’s where this project began for me.

About a month ago, I sat down over lunch with friends from Software Freedom Conservancy, and learned they’d embarked on a similar project at around the same time. In fact, Karen Sandler recently spoke on the subject as OSCON 2016.

We’re calling it ContractPatch. The idea is to provide strategy and legal knowledge to workers, along with some sample language for better contract terms.

But let’s start with the first step:

Everything is negotiable. Keep repeating that until it sticks.

Merely knowing that is an edge. Companies know it, but often don’t want their employees or potential hires to realize it. Some employers even structure their hiring, renewal, and termination processes to discourage negotiation. This can halt inexperienced negotiators, especially those from historically underrepresented groups who face widespread employer prejudice that can undermine their perceived ability to negotiate. Everyone will enter a negotiation with different leverage, different goals, and unique needs and strengths.

There are no magic words, but anyone can learn the techniques and strategies to approach contract negotiations. Like any other skill, it may not be easy at first. Also like any other skill, it can be broken down into steps, practiced, and will become easier over time.

And we’re here to teach.

In the coming months, we’ll write about legal and strategic points in contract negotiation strategies, pre-negotiation prep and practice, methods for negotiating, and we’ll provide information on your legal rights around contracts.

Down the road, we’ll look at specific contract provisions — especially those that impact tech workers the most, such as non-compete agreements and intellectual property assignment clauses. This will go hand-in-hand with a Github repository with forkable sample language for key contract provisions, such as payment terms, benefits, non-competition and non-solicitation agreements, and intellectual property assignment clauses.

But let’s walk before we run. The first step is knowing you can negotiate. Next, we’ll discuss the balance of power in hiring agreement negotiations, and how to self-evaluate your position before a negotiation begins. After that, we’ll cover timing and strategies around contract renewals, raises, and other opportune moments to renegotiate.

Whether it’s an employment offer, a mid-project contract renewal, or a termination agreement, its terms can be pushed on. Often, they can be changed. And getting there gracefully is an art, more dance than declaration.

And we want you to know as much as you can before your next dance starts.

[permalink]

Tags: conservancy, ContractPatch

The Importance of Following Community-Oriented Principles in GPL Enforcement Work

by Bradley M. Kuhn and Karen M. Sandler on July 19, 2016

UPDATE:2022-01-24: the Netfilter Core Team, one of the first groups to endorse our Principles of Community-Oriented GPL Enforcement have worked since that time to address concerns about McHardy's behavior discussed below. The Netfilter Core Team has now announced a settlement with Patrick McHardy (which follows a lawsuit they filed against McHardy in 2020 — that lawsuit was confidential until the settlement was announced (a practice that is common in Germany). The settlement requires all enforcement to be done in concert with a majority vote of the active Netfilter Core Team members, and also covers the exercise of contractual penalty provisions in contracts from past enforcement matters. The team also reiterated their continued endorsement of our Principles of Community-Oriented GPL Enforcement.

When we wrote the blog post below, we were the first organization to publicly criticize McHardy's use of enforcement in this manner, and we know many find this post when searching for information about McHardy's enforcement. We've left the remainder of the post as it original stood at its first posting for posterity. We now congratulate the Netfilter Team on standing by the Principles and effectuating legal mechanisms to ensure that they are followed for the benefit of software freedom. We look forward to coordinating with the Netfilter team in future enforcement that focuses on the right to software repair.

Our original post, as written on 2016-07-19, follows:

The GNU General Public License (GPL) was designed to grant clear permissions for sharing software and to defend that freedom for users. GPL'd code now appears in so many devices that it is fundamental to modern technology. While we believe that following the GPL's requirements is neither burdensome nor unreasonable, many fail to do so. GPL enforcement — the process to encourage those who fail to correct problems and join our open software development community — is difficult diplomacy.

Our community learned together over the last 20 years how to do this work well. Last year, Conservancy and the FSF published the concise but comprehensive Principles of Communited-Oriented GPL Enforcement. The Principles are endorsed by Conservancy, FSF and gpl-violations.org — the three historic community-oriented GPL enforcement organizations, as well as other non-enforcing organizations such as OSI. Recently, these principles were also endorsed by the Netfilter team, a core and essential group of Linux developers. However, despite our best efforts, we have been unable to convince all enforcers to endorse these Principles. Here, we express our concern and desire to ameliorate that situation as best we can. Furthermore, we also bring some transparency and context where enforcers seem unlikely to ever endorse the Principles.

One impetus in drafting the Principles was our discovery of ongoing enforcement efforts that did not fit with the GPL enforcement community traditions and norms established for the last two decades. Publishing the previously unwritten guidelines has quickly separated the wheat from the chaff. Specifically, we remain aware of multiple non-community-oriented GPL enforcement efforts, where none of those engaged in these efforts have endorsed our principles nor pledged to abide by them. These “GPL monetizers”, who trace their roots to nefarious business models that seek to catch users in minor violations in order to sell an alternative proprietary license, stand in stark contrast to the work that Conservancy, FSF and gpl-violations.org have done for years.

Most notably, a Linux developer named Patrick McHardy continues ongoing GPL enforcement actions but has not endorsed the community Principles. When Patrick began his efforts, Conservancy immediately reached out to him. After a promising initial discussion (even contemplating partnership and Patrick joining our coalition) in mid-2014, Patrick ceased answering our emails and text messages, and never cooperated with us. Conservancy has had no contact with Patrick nor his attorney since, other than a somewhat cryptic and off-topic response we received over a year ago. In the last two years, we've heard repeated rumors about Patrick's enforcement activity, as well as some reliable claims by GPL violators that Patrick failed to follow the Principles.

In one of the many attempts we made to contact Patrick, we urged him to join us in co-drafting the Principles, and then invited him to endorse them after their publication. Neither communication received a response. We informed him that we felt the need to make this public statement, and gave him almost three months to respond. He still has not responded.

Patrick's enforcement occurs primarily in Germany. We know well the difficulties of working transparently in that particular legal system, but both gpl-violations.org and Conservancy have done transparent enforcement in that jurisdiction and others. Yet, Patrick's actions are not transparent.

In private and semi-private communications, many have criticized Patrick for his enforcement actions. Patrick McHardy has also been suspended from work on the Netfilter core team. While the Netfilter team itself publicly endorsed these Principles of enforcement, Patrick has not. Conservancy agrees that Patrick's apparent refusal to endorse the Principles leaves suspicion and concern, since the Principles have been endorsed by so many other Linux copyright holders, including Conservancy.

Conservancy built a coalition of many copyright holders for Linux enforcement so that we as copyright holders in Linux could share with each other our analysis, strategy, plans and diplomacy. Much like Linux development itself, enforcement functions best when copyright holders collaborate as equals to achieve the desired result. In coding, Linux copyright holders seek to create together the best operating system kernel in history, and in an enforcement coalition like ours, we seek to achieve proper compliance in the best possible way for the community. (More collaboration is always better for various reasons, and we always urge copyright holders in Linux, Debian, Samba, and BusyBox to join our coalitions.)

Nevertheless, Conservancy does not object to individual copyright holders who wish to enforce alone; this is their legal prerogative, and with such limited resources for (and political opposition against) GPL enforcement on Linux, everyone who wants to help is welcome. However, Conservancy must denounce anyone who refuses to either endorse the Principles, or (at least) publicly explain why the Principles are not consistent with their efforts to advance software freedom.

There are few public facts on Patrick's enforcement actions, though there are many rumors. That his enforcement work exists is indisputable, but its true nature, intent, and practice remains somewhat veiled. The most common criticism that we hear from those who have been approached by Patrick is an accusation that he violates one specific Principle: prioritizing financial gain over compliance. Meanwhile, some who criticize Conservancy's enforcement efforts ironically believe we are “too nice” — because we don't seek to maximize financial gain, and therefore we ultimately fund some license compliance work with donations from the general public. Despite that criticism, and the simple fact that Conservancy's settlement funds from GPL enforcement usually fail to cover even the staffing costs associated with our enforcement efforts, we continue to abide by the Principle that compliance is paramount over monetary damages. While we sympathize with those who wish GPL enforcement would fund itself, we also see clear problems if an enforcer prioritizes financial gain over compliance — even if the overarching goal is more comprehensive enforcement in other areas.

Conservancy does all our enforcement specifically through a USA 501(c)(3) charity, precisely because that makes us transparently financially accountable. The IRS requires that our work benefit the general public and never bestow private inurement to anyone. Success in enforcement should never personally benefit one individual financially, and a charity structure for GPL enforcement ensures that never happens. Furthermore, the annual Form 990 filings of charities allows for public scrutiny of both enforcement revenue and expenditure¹.

Conservancy, as a charity in the center of GPL enforcement, seeks to make enforcement transparent. We devised the Principles in part to clarify long-standing, community-accepted enforcement procedures in a formalized way, so that violators and GPL-compliant adopters alike can discern whether enforcement behavior is acceptable under community norms. We welcome public debate about any enforcement action's compliance with the Principles (i.e., its meta-compliance with the Principles). We encourage all those who enforce GPL to come forward to either endorse the Principles, or publicly propose updates or modifications to the Principles. (We've created the mailing list, principles-discuss, as a public place for that discussion.) We urge developers to state that they support enforcement undertaken in a principled manner, including litigating only as a necessary last resort and to never prioritize financial gain.

We chose the phrase “meta-compliance with the Principles” carefully. Applying the Principles themselves to compliance with those Principles seems apt to us. For example, we publicized the concerns about Patrick's enforcement only after two years of good-faith attempts to discuss the problems with him, and we waited for more than a year before publicizing the problem, and only after both ample warning to Patrick, and discussion and coordination with the Netfilter team. Just as we would with a GPL violator, we exhausted every path we could find before making this statement publicly.

Thus, we now call on Patrick to endorse the Principles or publicly engage in good faith with the community to discuss proper methods of enforcement. We further welcome anyone who does not currently abide by these Principles to join us anew in our coordinated community-oriented GPL enforcement work.

In conclusion, to contrast GPL enforcement with the much more common proprietary software litigation, violators should always have a simple and solid method to quickly resolve the rare legal action around the GPL: compliance. GPL enforcers should always seek compliance as the primary and paramount resolution to any enforcement matter. In this manner, where community-oriented enforcement exists and thrives, the risk for danger from lawsuits diminishes. Today's violators can then become tomorrow's contributors.

Finally, if you are in a situation where you are unsure what your obligations are under GPL, we urge you to read and study the Copyleft Guide to learn more about how to properly comply with GPL and other copyleft licenses.

¹ Looking at Conservancy's Form 990s, you can see by examining Page 2 (Part III) (in FY 2011, see Page 25, Schedule O, for continuation) each year how much revenue Conservancy received from enforcement settlements, and how much Conservancy spends on license compliance activity. Most notably, Conservancy has not received a single dollar in GPL enforcement revenue since FY 2012.

[permalink]

Tags: conservancy, Filings, GPL

Comments on OpenChain Specification

by Karen Sandler on 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 Compliant is 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 Conforming or OpenChain Accordant would work, for example.
G4.1 should refer to complete and corresponding source code instead of just source code.
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.