Leading items

Cory Doctorow on the game plan to crush DRM

Author and Electronic Frontier Foundation (EFF) activist Cory Doctorow presented the opening keynote at SCALE 14x in Pasadena on January 22, using the opportunity to highlight the project that brought him back to the EFF after a decade. That project is Apollo 1201, an effort to challenge the ever-expanding problem of "digital rights management" (DRM)—now built into all manner of mass-produced products, not just entertainment media—that threatens the rights of individuals. The dangers of DRM are even greater than those posed by traditional proprietary software, Doctorow said, precisely because the rise of "smart" devices is putting DRM-locked software everywhere around us.

Doctorow told the audience that the fight against proprietary software has taken place on four fronts, which correspond to the factors Lawrence Lessig says regulate behavior: "code," "markets," "norms," and "laws." The "code" front is seen, simply enough, in Apache unseating IIS because Apache was a better web server. The "market" front is where open source creates new business opportunities that would not exist otherwise and the popularity of the new market overwhelms the proprietary software. Samba is an example, he said: it made SMB shares more useful and spawned new products; the popularity of those products took Microsoft out of the driver's seat. The "norm" front is ethical and moral debates, where advocacy changes the minds of the public. And the "laws" front involves all of the instances where city, regional, or national governments have passed laws mandating open-source software, open data, and the like.

Those four fronts describe the competition between "open" and "closed" technology in recent years, Doctorow said, but there is "a more profound kind of 'proprietary' on the horizon" now—one that goes beyond whether or not a product is "open" or "free." The new form of proprietary is code that includes DRM, which is much harder to fight against.

"You all know the DMCA [Digital Millenium Copyright Act]," he said. "It's the author of all your favorite YouTube videos." The problematic part of the DMCA is Section 1201, he reminded the crowd, "which makes it a crime to give people tools that they could use to bypass DRM." But that law was just the beginning: the US Trade Representative has been "patient zero," spreading the problem around the world by persuading other countries to enact their own equivalent laws. The worst example was the New Zealand law's Section 92A, which sparked protests in the streets. The backlash initially derailed the bill, he said, but entertainment industry lobbyists forced it through by reintroducing it as a rider on the disaster-relief bill passed after the 2011 Christchurch earthquake.

While such laws spread around the globe, DRM was also making its way into more and more devices. The Lexmark printer-cartridge case is a well-known example, as was the case of Skylink garage-door openers. In both cases, a company used poor, easily broken encryption software to attempt to block interoperability with third-party products, then sued rival companies who broke the encryption. In both instances, the courts sided with the defendants, noting that the DMCA only protects copyrighted works (rather than, say, trade secrets), which meant that the only DMCA-protected work in the Lexmark printer cartridge or Skylink garage-door opener was the DRM software itself.

But those cases were years ago, Doctorow noted; today, more and more devices do include significant amounts of software inside, from WiFi light bulbs to smart appliances, even to smartphone-enabled rectal thermometers—"yes, they now want to put DRM up our asses," he told the crowd to a peal of laughter. The sole reason the makers of these products are employing DRM is to stifle competition, he said; it has nothing to do with "piracy" and never has. Furthermore, DRM has never been a selling point; "if there were two Netflixes for the same price," he said, "and the only difference was that one had a 'save' button, no one would ever sign up for the other one."

Follow the money

The clear conclusion is that people are either oblivious to the DRM around them or they just do not care. Yes, he conceded, there will always be "a few supernerds" with the skills to bypass DRM themselves, but without real reform, DRM will continue to prop up anti-competitive behavior in the global economy.

Companies make money with anti-competition in three ways, he said. First, they double-dip on sales, as when they require people who have bought DVDs legally to pay again to put the same video on their phone. Second, they control parts and repairs. There are cheap diagnostic scanners that can read car "check engine" codes, but only for individuals; mechanics "operating a business with an address you can sue them at" have to buy expensive scan tools from carmakers, who require them to also sign contracts to purchase all replacement parts directly from the company. Finally, they make money by making promises to other businesses. For instance, cell carriers give away iPhones to customers, but only because Apple has promised to prevent those customers from ever installing a tethering app—by locking down the OS with DRM.

So, every day, "DRM costs you and me and everybody we love money," Doctorow said, "but that's not why I worry and that's not why I've returned to the EFF," Doctorow said. What worries him is how DRM prevents the patching of security vulnerabilities. When we can't examine our devices, we are stuck with ancient software filled with unfixable bugs.

He shared several "horror stories" about DRM. The Jeep remote exploit Charlie Miller and Chris Valasek published in 2015 was demonstrated on that car because that model's software did not employ DRM and the authors could thus avoid a felony prosecution. Subsequently, other automotive-security researchers have said similar flaws affect most other cars, but their lawyers have advised them not to disclose the vulnerabilities.

Jay Radcliffe (who is diabetic), refuses to use an insulin pump "thus taking years off his life" because of the security vulnerabilities he has seen in the devices' software, but which he cannot disclose because they are "protected" by DRM. In Ukraine, people who took their mobile phones near the site of anti-government protests later received text messages saying that they had been recorded as participating in an illegal action and warning them against doing so again. The unique identifiers baked into each phone are protected by DRM.

There were plenty of other examples, from John Deere tractors to voting machines to criminals capturing wireless webcam video and blackmailing the owners by threatening to publish the camera footage online. DRM makes it illegal to disclose security vulnerabilities in devices, and the Internet of Things makes that problem ubiquitous. That, Doctorow said, is why he decided to return to the EFF to work on the Apollo 1201 project.

Apollo

The goal of Apollo 1201 is to eradicate DRM in ten years' time by rewriting the laws. If you work on any sort of anti-circumvention project, Doctorow said, the EFF wants to talk with you. The point of the conversation is two-fold. First, the EFF can provide advice on how to structure one's project and how to discuss it publicly (although he made a point to say this was not of the formal "legal advice" variety). Second, the EFF wants to be prepared for when such projects inevitably result in lawsuits; it plans to fight a number of such cases and to take the fight all the way to the Supreme Court.

Since code is ultimately a form of First-Amendment–protected speech, the EFF is confident it can eventually defeat Section 1201 on Constitutional grounds. That process will likely take close to a decade. Fortunately, "this is a target-rich environment," he said, so the EFF believes it will have no trouble finding solid test cases and well-prepared defendants to work with.

In the meantime, though, a lot can change on the ground. As soon as the DRM threat for a particular product class begins to look uncertain, he said, companies will begin to attack the profit margins of the DRM purveyor. That will bring the fight to a second front (markets). And the courts, he said, deeply want the law to be relevant: if it is obvious that successful businesses and millions of people regard DRM as an obsolescence, they will rule against DRM. That principle was a large part of why the court upheld home recording in the 1984 Betamax case: millions of households already used VCRs to tape television.

He also challenged the audience to take the fight to the "norms" front, to talk about DRM wherever they can. "We're at peak indifference now. Every week, something bad [like the horror stories he related] will happen. When the people you know ask you how this happened, tell them." Finally, he asked the audience to do what they can to support the work of fighting DRM. "You probably give money to one of these companies every month," he said. "I just ask you to tie it, to match what you give these companies with something you give to organizations fighting for your freedom."

After the keynote, Doctorow stayed to discuss the project further and to answer questions. Among other matters, he said that the EFF may have already identified what project will be its first Apollo 1201 test case, and that the defendant in that case has been braced for such a fight for many years—even before the EFF announced the project.

He also noted that there was a chance that a case the EFF takes might result in only a narrow ruling, rather than cutting out the heart of Section 1201. But that is still a victory, he said, and narrow rulings can still shift the economic factors in a major way. As in the "dancing baby" case, where the court ruled that copyright holders must consider fair use before issuing any DMCA takedown notices, or else be held responsible for damages. The ruling turns the mass issuance of takedown notices into a financially risky proposition for entertainment publishers, a fact that defense attorneys are beginning to notice. He also encouraged open-source developers to join the fray and help disrupt the DRM-protected businesses. "We want people to see that there's money in them there circumvention devices."

Comments (7 posted)

Trademarks for open-source projects

SCALE 14x featured a dedicated legal track requiring separate registration. While much of the content was aimed at lawyers working in open-source software or at companies investigating the legal aspects of open-source software for the first time, there were also sessions of interest to software developers. One such session was Pamela Chestek's Trademarks and FOSS: Entirely the Same and Entirely Different, which looked at how trademarks impact developers within an open-source project as well as those who are downstream users of the code.

Many in the community recognize Chestek either from her years at Red Hat or, more recently, for acting on behalf of the GNOME Foundation when it faced a trademark battle with the web service Groupon. While trademark law is well understood by many in the legal profession, she said, open-source projects have tended to ignore it—at least in comparison to their understanding of copyright and patent law.

Chestek opened up the session with a brief look at how trademark law functions. By definition, a trademark is a "symbolic representation of the sum of information about a product or service"—or what marketing calls "the brand." A key concept is that trademark traditionally points to a "unique single source" for a brand, but any particular usage of a trademark can signal a variety of different relationships.

For instance, the Apple logo on a MacBook designates Apple as the party that the laptop "comes from," even though multiple subcontractors actually built it. A software vendor that offers certification may allow independent contractors to advertise with its certification's trademarks, even though they are not employees. That usage designates more a "seal of approval" for the contractors. Trademarks can also be used in advertising relationships, such as "Volvo Fashion Week." That usage makes it clear that Volvo is sponsoring the event, Chestek said, and no one is likely to misunderstand and think that the carmaker is also producing clothing. The absence of misunderstanding is critical, she said: the only thing that the law prohibits is the usage of someone else's trademark in a way that causes confusion about the relationship being signaled.

Trademarks from a project's perspective

For open-source software, though, these principles create considerable tension. First, trademarks are often lumped together with copyrights and patents in the broad "intellectual property" pool, which is generally mistrusted by open-source projects. Second, trademark law's "unique single source" concept does not map well to open-source projects' distributed, ad-hoc membership and open participation model. Finally, trademark law in most jurisdictions comes from the manufacturing era of a century ago, and does not mesh easily with how open-source software is produced.

On the intellectual-property front, Chestek argued that, while almost all open-source developers find software patents "all bad" and copyrights to be a mixed bag (after all, copyright is what allows open-source licenses to function), trademarks should be seen as the "all good" piece of the puzzle. That is because most projects' primary or only trademark is the project name, and looking after the name is how the project protects its reputation.

Trademarks fit well with the "fandom" that many projects rely on to build a community and to turn users into contributors. They also enable projects to offer assurances that users know what they are getting from the software. A bad actor could insert malware into open-source code that it redistributes; while copyright would offer no recourse (as long as the license requirements are met), trademark law would let the project step in and shut down the malware redistributor. Mozilla has had to take such steps more than once in the past.

Regarding the "unique single source" doctrine of trademark law, some lawyers think that open-source development's "anyone can submit a patch" nature undermines trademarks, but Chestek disagrees. Yes, anyone can modify and redistribute code, she said, but it is not "the Wild, Wild West." In reality, projects operate in a systematic fashion. There is a canonical source for releases and there is an organizational structure. Furthermore, she said, many of the same issues (such as who in the organization determines what is allowable trademark usage) already arise in other endeavors—particularly not-for-profit ones. From volunteer work to church raffles to bands that split up and disagree about which member gets to use the old band name, the same issues that open-source projects encounter are regularly seen elsewhere.

Current trademark law in the US was rewritten in 1946, and the previous update was in 1908. In both eras, Chestek said, the assumption was that a product was a physical, manufactured good. But open-source software is built and distributed differently, which can be problematic. For instance, she noted that it is common practice for one project to intentionally choose a name that is similar to another project's, such as NHibernate, which is a .NET port of the Java-based Hibernate framework. That name communicates to the user about compatibility. Although common practice, she said, it is a strategy that projects will likely have to abandon if they grow—much as the Jenkins project had to change its name when it forked from Hudson. The main Hudson developers started the fork, but were told by Oracle that they could not use "Hudson" for its name.

Above all else, Chestek urged projects to register their trademarks—at the very least, in a major jurisdiction like the US or the EU, but wherever possible. There are two benefits. First, the registration forces project members to take a serious look at their structure and have the conversation about who owns what; that conversation can be more valuable than the legal filing it eventually produces. Second, registering a trademark is the key way to get the mark on the radar of anyone doing a trademark-clearance search. Most companies do want to create their own brand and identity in good faith, she said, but they generally do not know where to look for open-source software project names. If the names are registered as trademarks, however, they can be found.

Trademarks from a downstream perspective

Chestek then addressed several frequently asked questions about trademarks that arise for the users of open-source software, including downstream projects. The first question was whether there really is a "duty to enforce" a trademark. Such a duty is often claimed, she said: many cease-and-desist letters assert that the trademark holder has to enforce a trademark or lose it. But "there is actually no such thing," she said, "those words do not appear in the Trademark Act."

Rather, she explained, there is a continuum of trademark usage that could be seen as confusing, and a trademark holder has the right to enforce their trademark on a confusing usage. But only the bottom end of that continuum involves anything like "losing" a trademark, and that situation is when a court decides that a trademark has become so widely used that it has turned into a generic term for a product category. It is a rare occurrence, but not impossible: Chestek speculated that the "Linux" trademark runs the risk of becoming a generic term for a category of software. She wondered how many projects actually bother to apply for authorization from the Linux Mark Institute.

The second question was whether a trademark covers exact copies distributed downstream (that is, whether or not the trademark would have an infringement case if the downstream product used the trademark in, say, advertising). Unfortunately, the answer seems to vary depending on the jurisdiction (in the US, the trademark is likely extended to the copy, but it is likely not in the EU).

Whether a project's trademarks extend to downstream forks is a more interesting question. Chestek believes that the upstream trademark is not transferred to forks, so forks need to remove any usage of the mark. But even that has limits; in particular, she believes a project cannot demand that downstream forks remove its trademarks if doing so would functionally alter the program. The example she gave was a project using its name in function names, class names, and commands. If the command-line tools are FooBuild or FooRun, requiring users to change the names would impede script compatibility, and impair usage.

Nevertheless, she cautioned that there is no US case law on this topic, and others may disagree. For projects concerned about that uncertainty, she said they could always write their own trademark guidelines and offer to grant trademark licenses to downstream users; that would clarify the matter for users.

Chestek closed by recommending that projects explore writing a trademark policy, looking to the Model Trademark Guidelines and FOSSmarks sites for help. Trademarks are underrated and underfunded in open-source software, she said, but an open-source project's name is often its heart and soul, so it needs protection.

Comments (5 posted)

The Linux Foundation changes its bylaws

The Linux Foundation's board of directors is not usually a hotbed of controversy; for the most part it does its work in the background, quietly going about the business of directing the non-profit organization. In mid-January that all changed. The bylaws that governed how some at-large board seats were allocated were changed, which caused quite an uproar within the Linux world. While there is speculation about the motive for the change—as well as an official statement of sorts—it certainly seems like the whole thing could have been handled a lot better.

Until the change, which was made on January 14, two of the Linux Foundation (LF) board's "at-large" directors were elected by the individual (as opposed to corporate) members of the LF. Those seats were filled by Bdale Garbee and Larry Augustin (and still are, the board re-appointed them to the seats after the bylaw change). A third community representative comes from the Technical Advisory Board (TAB), which is comprised of kernel developers who are elected at the annual Kernel Summit. The TAB chair has traditionally been added to the LF board and that is the case now, with Grant Likely serving as the TAB representative to the board.

Out of sixteen members, the LF board has three that are meant to represent the community, while the rest are made up of representatives of the companies that have joined the foundation. As pointed out by Matthew Garrett, the LF board changed its bylaws, quietly, to remove the possibility of directly electing the two at-large seats. In addition, the $99/year "individual member" option was quietly switched to an "individual supporter"—with all mention of running for and electing seats on the board removed.

Garrett's speculation was that the move was precipitated by Karen Sandler's candidacy for the LF board. Sandler, who is the executive director of the Software Freedom Conservancy (SFC) actually announced that she was running back in September. The changes to the LF individual member/supporter program and to the bylaws all took place in that time frame, which Garrett said "may be coincidental", but it didn't really look that way to him. To his eye, it seemed that the GPL-enforcement suit that SFC is funding against LF-member VMware made the LF "willing to throw out any semblance of community representation just to ensure that there was no risk of someone in favour of GPL enforcement ending up on their board".

That posting set off quite a firestorm on Garrett's blog, here at LWN, and elsewhere. As with many controversies in our community, the comments ranged from sober analysis to intemperate rants to outright trolling. On reddit, Greg Kroah-Hartman (who works for the Linux Foundation, but was not commenting on its behalf) replied to the uproar at some length. He noted that electing board seats from the general membership is not common for non-profits. Furthermore:

The speculation about two HP board seats may be part of the equation, but the fact that the board re-appointed Garbee is then a bit puzzling. Garbee is far more than just his HP affiliation, however, having been a part of the Debian project for many years (including as Debian project leader and chair of its technical committee along the way). But there is also the question of how these actions could be taken without any notice to the community, before or after the changes were made. In the reddit comment exchange with Garrett, Kroah-Hartman said that is simply the way boards normally operate:

But Garrett disagreed:

LF executive director (and board member) Jim Zemlin weighed in with a blog post that echoed some of what Kroah-Hartman said:

Zemlin also decried some of the comments about Sandler that were cropping up in various online forums. While many of those comments are certainly deplorable (as well as inaccurate and irrelevant), Zemlin focused mainly on that and did not directly address much of what Garrett (and others) have alleged.

Further inquiries about the vote and the reasons behind it have largely been met with silence. When asked in email, Likely deferred any questions (including how he voted) to Zemlin, who has not responded to an email inquiry. Also in email, Garbee said that he voted against the proposal to eliminate the elections; so far, Augustin has not responded.

The LF is a non-profit, but not a charity. It is, instead, a US 501(c)(6) corporation that is organized as a consortium for the benefit of its members. For the most part, those are Linux-oriented companies. The bylaws state: "The purposes of this corporation include promoting, protecting, and standardizing Linux and open source software." Those are all laudable goals, of course, but Linux is far larger than simply the companies that have chosen to join the LF.

One could imagine that the board members (and the companies they represent) were a little nervous about some kind of activist (whether it be Sandler or someone else) getting elected to the board. GPL-enforcement activism may well be part of that concern, but there could be other factors at play here too.

There seems to be something of a veil of secrecy around the board's activities; there appear to be no published minutes from the meetings, for example. That secrecy might not be honored by some potential board members (though Sandler would not seem likely to be one of those). It is not clear, exactly, what the board might be doing that requires such secrecy (especially with regard to open source), but that is traditionally how boards operate. Being able to ensure that it can do its work quietly in the background may be one of the prime motivations for this change.

Given the level of secrecy, the community representation does not really amount to all that much in some ways. One hopes and believes that those representatives are voting and contributing for the benefit of the community, but we don't have any direct way of knowing that. We do know that the LF has done lots of good things for Linux from funding developers and their travel to the Core Infrastructure Initiative and running kernel.org—and plenty more. The board has undoubtedly had a good deal of influence on that. One can quibble with some of its decisions, projects, and programs, but the LF has also been a strong, capable advocate for the advancement of Linux over the years.

It should also be noted that $99 per vote to elect the at-large board members is hardly the right mechanism to get community members onto the board. That kind of system can be too easily gamed, for one thing. But it did at least give the appearance of a way for those outside of the member companies to influence the direction of the LF. On the other hand, having the board self-select those community representatives, as it appears it will be now, is not a particularly good option either.

In the end, though, the LF is set up by and for its members and they can certainly do whatever they want in terms of seats on the board. In some sense, it was the illusion that the seats could be elected "by the community" that was lost, thus the outcry. In the end, at-large seats were always subject to the rest of the board's approval, but removing a duly elected board seat would have been even more unpopular than this move has been.

Thinking that these changes would be able to "fly under the radar", however, seems like a serious miscalculation. Many readers may not have been LF members, thus were not truly affected by the change, but still felt disenfranchised by it. The appearance that the board is "circling the wagons" against community participation is probably not accurate, exactly, but is still strongly felt in many quarters.

One cannot go long at an LF event without hearing the word "collaborate"; this would have seemed like an opportunity to do just that. Perhaps this proposal came out of the blue and was quickly approved, but that does not seem all that likely. Before making these kinds of changes, explaining the problem and looking for solutions with the community would seem a more sensible approach. The logistics would be tricky, perhaps, and there might still be some loud voices expressing displeasure, but collaboration is not necessarily easy. Perhaps the board will look at better ways of somehow enfranchising "the community" to represent its interests within the LF down the road.

Comments (33 posted)