Context on Conservancy's Filing for Summary Judgment with the TTAB

by Bradley M. Kuhn on December 11, 2017

As Conservancy's entire staff wrote in our earlier statement: while we think SFLC's trademark action is a waste of resources for both organizations, we also are dedicated to transparency. Accordingly, we'll keep the software freedom community updated about the action as long as it proceeds. We publicly called on SFLC to withdraw this legal action, but they have not. Therefore we've proceeded today with the most expedient defense available to us: a summary judgment motion which can be read on the USPTO's website. As a non-lawyer, I explain in this blog post some details of that motion and its supporting documents in more mundane, non-legal terms. If you are curious about the details of today's motion filing, do read this blog post and the full filing, but I actually encourage you to skip to the last paragraph of the blog post. (In other words, I made this post solely for transparency, not because I believe following every move in this action is worth your valuable time.)

Today, Conservancy filed for summary judgment in SFLC's trademark cancellation action. As I understand from our lawyers, summary judgment is a mechanism to ask a Court to expediently handle a matter where the facts are straightforward and, as a matter of law, there is no plausible way that the party filing for summary judgment won't prevail. Everyone at Conservancy strongly believe that fits this situation, and the motion asks the Trademark Trial and Appeal Board (TTAB) to agree with us.

In making our defense, I needed to now publicly state facts that I had hitherto avoided saying publicly. Frankly, I previously saw no reason to publicly discuss SFLC's strange accusations over the years. But, I now must do so, because these points are essential to Conservancy's legal defenses. Specifically, SFLC's contact with us since we filed our trademark in 2011 raised other issues but never in those interactions did SFLC raise any concerns about the name, trademark, or branding of our organization. In other words, people from Conservancy, including me, communicated with SFLC often, listened to their complaints, and none of them were about the issues that SFLC raised in the trademark cancellation action.

If you read Conservancy's filings today, you'll see various examples of this. Simply put: while SFLC has a history of complaining to us, complaints about the organization's name were not among them until their cancellation petition. Each time, we took those complaints seriously, and each time, we discovered that they were spurious threats. I'll explain more about two examples from our filings. In February 2013, at an in-person meeting, Moglen told me that Conservancy was in danger of losing our 501(c)(3) status because we relied heavily on a few large grants back then. (This was before our Supporter program). I was pretty sure Moglen was wrong, but after he told me that, I nevertheless spent months researching, re-reviewing our 990s, and otherwise trying to figure out what he meant and why he thought we were in such danger. In the end, I confirmed with the aid of legal counsel that our public support test was fine and strong, and we had nothing to worry about. Additionally, from fall 2014 through May 2016, SFLC repeatedly made accusations that some material on Conservancy and FSF's joint copyleft.org/guide site had “plagiarized” SFLC's publications. We researched that question too, and Karen and I even recorded an audcast back in December 2014 that explains how plagiarism claims are nonsensical regarding compliantly published CC-By-SA-licensed works. We also confirmed that compliance by asking CC licensing experts to review copyleft.org. Once they confirmed our compliance, we repeatedly told SFLC their claim was inaccurate — even while SFLC continued to make threats about that same topic and demand meetings about it.

Again, I have hesitated for years to talk publicly about these facts; I historically concluded that unilaterally exposing privately-made specious claims interferes with the essential job of promoting and defending software freedom. Despite our differences, SFLC is a fellow charity, and I have no wish for them to cease to exist, only that they stop attacking us. While both Conservancy as an organization, and I personally, have publicly disagreed with some of SFLC's policy positions and actions, I have striven for years to keep our public dialogue focused on software freedom policy — rather than about the petty issues that SFLC raised in private. I don't think it serves the software freedom community to conflate public policy disagreements with personal attack. But, SFLC has recently extended those personal gripes into the public space, not only via this trademark cancellation action, but also in their public statements about Conservancy's other work. For example, a year ago, Moglen publicly described certain GPL enforcement work, to which I have contributed since the 1990s, as “a jihad”. I was offended because I have dedicated my life to non-violent, Principled activism for social justice causes. Even so, I did not likewise assail in response; I sought to keep the discussion about policy, not hyperbolic rhetoric.

Sadly, less than a year later, SFLC escalated even further with this surprising (and inherently public) filing against us with the TTAB. Since SFLC refused our public requests to withdraw the cancellation action, we must defend ourselves with our best legal defense. To do that, we needed to make public, through our declarations, that SFLC's own email clearly show that, for years, SFLC made strange complaints (which we researched and responded to), but SFLC did not complain about the name, trademark, nor branding of Software Freedom Conservancy until the cancellation action.

Finally, on a meta-issue, I've seen a lot of stories, blog posts, and comments on LWN and other venues in the last few weeks about this matter. It seems to have burned more electricity and time than it warrants. I do appreciate the statements of support that so many of you have made, but I have a request. While I understand that this kind of situation generates an intriguing distraction and seemingly endless discussion, I encourage those of you who are otherwise software freedom contributors to temper your time investment. Faced with a petition to cancel our trademark, Conservancy must defend ourselves before the TTAB. But, I loathe the idea that the time-waste damage of SFLC's action might extend to other software freedom contributors and activists. In particular, I ask that those of you who are Conservancy project volunteers avoid distraction by this. The work of Conservancy's member projects is the work that SFLC's action seeks to impede, so please don't allow them to break your focus and succeed in that — even if just a little bit.

[permalink]

Tags: conservancy

Join me at Free Society Conference and Nordic Summit!

by Bradley M. Kuhn on November 2, 2017

I'm delighted to be en route to Oslo, Norway as I write this post. I'll be speaking this weekend at FSCONS, the Free Society Conference and Nordic Summit. FSCONS is admittedly a small event, but has a theme that is absolutely intriguing and incredibly important to the future of software freedom. As can be read on the FSCONS website, the conference looks at the intersection of society, culture and technology. They invite speakers from throughout the Open Source and Free Software world as well as Free Culture and privacy and other technology activists.

I'll be giving a talk entitled The Crumbling Intellectual Infrastructure of Free Software & Free Culture Licensing. My talk will explore the history of Free Software and Free Culture licensing, how it relates to rise of for-profit popularity of Open Source, and the larger political and societal implications of where we are now. Admittedly the title sounds bleak, and I'm certainly known for my pessimistic talks about the future of software freedom, but I'll also include suggestions and ideas for activists to work to solve the problems our community now faces.

I want to thank in advance the great work of the organizers of FSCONS. Not only are they funding travel for speakers, but they've sent numerous clear and understandable emails about the weekend's events. It's made my planning smooth and easy.

I really encourage you to join us in Oslo this weekend; tickets are still available, and I did a quick check and round-trip flights from major cities in Europe this weekend to Oslo are around €200. I think it's well worth the trip! See you there!

[permalink]

Tags: conservancy, conferences

How Additional Permissions (aka Exceptions) Impact a Project's License

by Bradley M. Kuhn on October 20, 2017

When first learning about FLOSS (Free, Libre and Open Source) licenses, most of us learned them by their specific names, and generally when someone asks: What license is your project under?, the answer is a short moniker like GPLv2-only or GPLv3-or-later. However, since the earliest advent of FLOSS licenses, the concept of “additional permissions ” — or, the older term for it: “exceptions” — have been an essential part of the licensing infrastructure of our community.

The first additional permission for a copyleft license dates back to the Bison license. Since the 1980s, the GNU project gave an exception to the GPL for Bison to assure that typical uses of Bison — which copy some of Bison's own source code into the program's output — did not cause the GPL to apply to that output. This exception was simple, straightforward, and necessary. Users of parser generators would be surprised to learn that using Bison to generate their parser would cause their work to be governed by copyleft. Additional permissions are a scalpel-like tool for authors of copylefted software that carefully craft project policy to best fit their community. Indeed, these exceptions became such an important component of GPLv2 licensing that GPLv3 formalized the concept in the actual license text, defining the term “additional permission ” in GPLv3 itself.

This name better described the purpose of these clauses. Historically, the FSF called them “exceptions”. Throughout the 1990s and early 2000s, software authors deployed these solutions in creative ways, and it became clear that the phrase “license exception” was a poor descriptor (particularly given that “taking exception” is often considered a bad thing)! Slowly, the term “additional permission” became preferred.

Additional permissions are now quite prevalent. Some pursue esoteric policy goals, but most are simply stated and achieve a narrow goal. While additional permissions often make it impossible to name a project's license as simply “GPLv2-only”, the intended policy is usually clear by quickly reading the additional permission(s).

By way of example, despite our common shorthand of saying that Linux's license is GPLv2-only, the details are more complicated. Linux's license has a long-standing additional permission regarding syscalls. Specifically, this additional permission states that the copyleft terms do not cover user programs that use kernel services by normal system calls. This means that even though GPLv2 is a strong copyleft and seeks to apply to any derivative and/or combined work with Linux under copyright, downstream may license parts of combined works that use kernel services by normal system calls under terms other than GPLv2. While some contributors' code in Linux is licenses without this additional permission (such as plain GPLv2-only), most Linux contributors license their copyrights under “GPLv2 with the syscall exception”.

This week, the Linux community began a process to add another additional permission to Linux's license. As with the syscall exception (and any other additional permission), copyright holders must opt-in to grant this additional permission (and a long list of copyright holders have already done so for the new Statement). Conservancy has lauded this effort, since this additional permission allows violators (in some cases) to officially receive permission from those copyright holders to operate under the GPLv3 termination provisions. Copyright holders who participate in Conservancy's GPL Compliance Project for Linux Developers have long followed this, anyway (first informally, and then more formally in adherence to our Principles of Community-Oriented GPL Enforcement). The Linux Kernel Enforcement Statement formalizes this practice as an opt-in additional permission for Linux's license.

Fortunately, copyleft-based additional permissions (aka license exceptions) aggregate reasonably well. Specifically, additional permissions are fully compatible with the main copyleft license. At their option, downstream can usually remove the additional permission and distribute under the main license. Sometimes, licensing experts will talk about the effective license of a work. In practice this means: given a codebase that combines copyrighted material under many different licenses, and possibly many different additional permissions and exceptions, what's the lowest common denominator licensing requirement that, if met, will satisfy all the licensing requirements of all of the relevant licenses? With most copylefted works, this often does simplify to those easier monikers!

This begs the question: what's the effective license of Linux? Well, more than likely, it's simply GPLv2-only. The reason is this: all the copyrighted code that comprises Linux is (at least) licensed under GPLv2-only. A overwhelming majority is under “GPLv2 with the syscall exception”, and (with this week's announcement) an ever-growing swath will be licensed under “GPLv2 with the syscall exception and with the Linux Kernel Statement additional permission”. Not every copyright holder whose code is in Linux will grant either exception. Thus, the abbreviation to GPLv2-only, as a moniker for Linux's effective license, remains accurate.

Additional permissions are handy tools when building a community around a codebase, particularly when some community members have reservations about some aspect of the standard copyleft license. Copyright holders can grant an additional permission — even one that isn't strictly necessary — to quell concerns and clarify the licensing infrastructure.

Finally, all this begs one more question: Why aren't additional permissions to copyleft licensing (particularly after they were formalized in detail as part of GPLv3 itself) more widely utilized? My anecdotal theory is that licensing remains a difficult area of comprehension for FLOSS contributors and adopters. Like everyone whose primary expertise lies elsewhere, licensing novices prefer simple buckets that are easily understood; difficult concepts often dive deeper than necessary for typical daily work. While licensing geeks like me enjoy pondering and exploring the flexibility provided by additional permissions, many developers prefer a simple moniker to describe a project's license. As such, you'll even hear licensing experts oversimplify to describe a project's license. As one of my undergraduate Computer Science professors said to me, all your professors will oversimplify until you're graduate students, because we've yet to figure out the topological sort necessary to tell you the whole story in proper order such that we avoid these oversimplications that make experts cringe.

[permalink]

Tags: conservancy, GPL

Goodbye To Bob Chassell

by Bradley M. Kuhn on July 3, 2017

It's fortunately more common now in Free Software communities today to properly value contributions from non-developers. Historically, though, contributions from developers were often overvalued and contributions from others grossly undervalued. One person trailblazed as (likely) the earliest non-developer contributor to software freedom. His name was Robert J. Chassell — called Bob by his friends and colleagues. Over the weekend, our community lost Bob after a long battle with a degenerative illness.

I am one of the few of my generation in the Free Software community who had the opportunity to know Bob. He was already semi-retired in the late 1990s when I first became involved with Free Software, but he enjoyed giving talks about Free Software and occasionally worked the FSF booths at events where I had begun to volunteer in 1997. He was the first person to offer mentorship to me as I began the long road of becoming a professional software freedom activist.

I regularly credit Bob as the first Executive Director of the FSF. While he technically never held that title, he served as Treasurer for many years and was the de-facto non-technical manager at the FSF for its first decade of existence. One need only read the earliest issues of the GNU's Bulletin to see just a sampling of the plethora of contributions that Bob made to the FSF and Free Software generally.

Bob's primary forte was as a writer and he came to Free Software as a technical writer. Having focused his career on documenting software and how it worked to help users make the most of it, software freedom — the right to improve and modify not only the software, but its documentation as well — was a moral belief that he held strongly. Bob was an early member of the privileged group that now encompasses most people in industrialized society: a non-developer who sees the value in computing and the improvement it can bring to life. However, Bob's realization that users like him (and not just developers) faced detrimental impact from proprietary software remains somewhat rare, even today. Thus, Bob died in a world where he was still unique among non-developers: fighting for software freedom as an essential right for all who use computers.

Bob coined a phrase that I still love to this day. He said once that the job that we must do as activists was “preserve, protect and promote software freedom”. Only a skilled writer such as he could come up with such a perfectly concise alliteration that nevertheless rolls off the tongue without stuttering. Today, I pulled up an email I sent to Bob in November 2006 to tell him that (when Novell made their bizarre software-freedom-unfriendly patent deal with Microsoft) Novell had coopted his language in their FAQ on the matter. Bob wrote back: I am not surprised. You can bet everything [we've ever come up with] will be used against us. Bob's decade-old words are prolific when I look at the cooption we now face daily in Free Software. I acutely feel the loss of his insight and thoughtfulness.

One of the saddest facts about Bob's illness, Progressive Supranuclear Palsy, is that his voice was quite literally lost many years before we lost him entirely. His illness made it nearly impossible for him to speak. In the late 1990s, I had the pleasure of regularly hearing Bob's voice, when I accompanied Bob to talks and speeches at various conferences. That included the wonderful highlight of his acceptance speech of GNU's 2001 achievement award from the USENIX Association. (I lament that no recordings of any of these talks seem to be available anywhere.) Throughout the early 2000s, I would speak to Bob on the telephone at least once a month; he would offer his sage advice and mentorship in those early years of my professional software freedom career. Losing his voice in our community has been a slow-moving tragedy as his illness has progressed. This weekend, that unique voice was lost to us forever.

Bob, who was born in Bennington, VT on 22 August 1946, died in Great Barrington, MA on 30 June 2017. He is survived by his sister, Karen Ringwald, and several nieces and nephews and their families. A memorial service for Bob will take place at 11 am, July 26, 2017, at The First Congregational Church in Stockbridge, MA.

In the meantime, the best I can suggest is that anyone who would like to posthumously get to know Bob please read (what I believe was) the favorite book that he wrote, An Introduction to Programming in Emacs Lisp. Bob was a huge advocate of non-developers learning “a little bit” of programming — just enough to make their lives easier when they used computers. He used GNU Emacs from its earliest versions and I recall he was absolutely giddy to discover new features, help document them, and teach them to new users. I hope those of you that both already love and use Emacs and those who don't will take a moment to read what Bob had to teach us about his favorite program.

[permalink]

Tags: GPL