Twin Peaks and the GPL
Blog post by Eben Moglen. Please email any comments on this entry to <email@example.com>.
Twin Peaks Software, Inc., which makes proprietary data replication and cloud storage software, sued Red Hat and its subsidiary Gluster for patent infringement back in February. Last week, Red Hat filed a counterclaim in that litigation, alleging copyright infringement by Twin Peaks in misappropriating GPL'd software.
Red Hat's counterclaim asserts that Twin Peaks has copied GPL'd code, from mount, into their proprietary mount.mfs utility, which is distributed to licensees of their data replication products. Red Hat holds copyright on most of the code in the relevant version of mount, which is part of the util-linux package.
The facts supporting Red Hat's counterclaim have not yet been proven; they are merely allegations. The legal form in which Red Hat has made its counterclaim is the standard one pioneered by the clients I have worked with over the years. Red Hat points out that their code in mount is only licensed under GPLv2, and can only be redistributed, in modified or unmodified form, by Twin Peaks or anyone else, under the terms of GPLv2. If distributed inside a proprietary program, the code is plainly not being used according to the terms of GPLv2. So if Red Hat is correct that Twin Peaks has put code from mount inside mount.mfs, it has no license for that use of the code, and is infringing Red Hat copyright. Indeed, if the allegation is correct, Twin Peaks has lost any rights to distribute mount in any form under the automatic termination provision of GPLv2.
Red Hat's counterclaim should survive a motion to dismiss in the trial court, because it states a claim on which, if the facts are true, Red Hat is entitled to relief. We shall see in due course whether Red Hat can prove the facts it has alleged.
In the meantime, the allegations raised by Red Hat are very grave. Not only has Twin Peaks initiated patent aggression against members of the FOSS community, it is apparently making use in its business of the very FOSS produced by the community member it is suing. And not only is it making use of that FOSS, it is allegedly doing so in gross disrespect of the rights of the parties who have made the valuable software they are using. First, if Red Hat is correct, they take our software without playing by our rules, and then they attack the community using their doubtful patent.
Such betrayal of the community while making use of its software is a particularly severe offense. If Twin Peaks is in fact ripping off the community while also suing one of our leading commercial redistributors, serious consequences should follow.
Red Hat has been a significant supporter of SFLC since I founded it. But in this as in all similar situations, SFLC's primary concern is protection of the rights and interests of our clients, non-profit makers and distributors of FOSS. SFLC will now begin an investigation of Twin Peaks' products, to ascertain whether any of our clients' rights are being infringed through the violation of FOSS licenses. We hope that other organizations around the world, including GPL-violations.org and the Software Freedom Conservancy will do likewise. Community defense is the crucial guarantor of a level playing field for businesses, as it is the heart of protecting freedom for developers. We need to know the truth about Twin Peaks' practices, and we must take whatever steps are appropriate when the truth is known.
Government of India: Quiet all the way!
Blog post by Mishi Choudhary. Please email any comments on this entry to <Mishi@softwarefreedom.org>.
The recent curbs on social networking websites in India demonstrate the
unpredictability of the legal environment, both for businesses and the
citizens. Whether its the Government of India's (GoI) insistence on
getting access to corporate emails and text messages sent via BlackBerry
devices, or changing stances on "pre-screening" user generated content,
the authorities seem to be doing a tap dance around legal issues. The
implementation of rules seems surreptitious as they are bent
conveniently in the name of "security".
The North-east exodus related disturbances presented a public
disorder situation which had a new characteristic.
This time around, the platforms of communications and reporting had
changed. The social networking websites provided voice to anyone and
everyone who had an internet connection, thereby the chatter of the
street transposed online and could be read widely. The communal hatred
of the society started reflecting in people's online communication as
well. The GoI, crippled by its inexperience of social media and plagued
by the nervousness of the situation, offered a knee jerk response, that
of issuing a blanket ban of at least 300 websites and various
Well you wonder---shouldn't GoI be dealing with this episode by using
the power of the Net to support and protect its citizens by combating
rumor with truth, told reliably by a govt people can trust? Instead, in
order to disguise its inefficiency, it is not only resorting to
censorship, which won't work, it is trying to force people to keep the
censorship secret, which is corrosive of the very idea of democracy.
An analysis of the orders issued by the Ministry of Communication & IT
makes it difficult to discern the intentions of the authorities. The
specific URLs sought to be blocked included the domains of
Times of India,
Al Jazeera, FirstPost and other websites.
Section 69A of the Information Technology Act, 2000 provides the Central
Government, the power to block access by the public of any information,
to maintain public order or for preventing incitement to the commission
of any cognizable offense amongst other things.
The governing rules which lay out the procedure to carry out such
blocking, provide that, any such direction for blocking can only be
given by the Secretary, Department of Information Technology, on a
recommendation made by a Designated officer in an emergent situation.
This interim direction is then supposed to be reviewed by a committee
consisting of Joint Secretaries from the Ministry of Law and Justice,
Home Affairs, Information and Broadcasting and the Indian Computer
Emergency Response Team, to analyze if the response was appropriate
considering the seriousness of the situation. A final order can only be
issued by the Secretary, Department of Information Technology after
receiving a report from this committee.
Such elaborate rules requiring the involvement of officials at such high
levels, from various departments of the Government were formulated, to
prevent misuse of the power to block access. However, all these
communications were signed by a Director (DS-II)of the Department of
Telecommunications and not a Joint Secretary. While the letter instructs
Licensees to block specific URLs, it also requests them to refrain from
mentioning these URLs in their compliance letters. Implying that the
censorship should be kept secret.
A Director level officer issues a non-reasoned order, instructs the
licensees to omit the details from an official compliance report, the
process rests in a black hole and we shut down half the internet?
Are the authorities abandoning the Rule of law, the very principle of
democratic government? or these tedious rules are to stay on the books
when results can be achieved "merely by asking", as the over-zealous
ISPs seem to comply? or rules are being followed in some covert way, we
The communications used to block access not only fail to show legal
authority for these orders, but they also try to subvert the
requirements of law. Blocking actions must be documented by those who
perform them. Time and again we have seen the desire of the authorities
to cover such attempts. If that's the kind of 'emergency' to which they
are referring, then we have a bigger problem than some malevolent
The problem of combating rumor is a classic problem, for which more
speech is a time tested and appropriate approach. GoI, instead of
fulfilling its duty of supplying accurate, useful information by
channels that every Indian citizen can benefit from, in the interest of
public safety and social order, is telling people to send fewer SMSs.
Instead of deploying an efficient public communication strategy, it is
to censor the world wide web.
The current methods will gain some co-operation from multi-national
social networking businesses, who are eager to demonstrate that they are
good community participants. They will behave responsibly regardless of
whether the government policy is well judged and they will follow the
law. But in the long run, it is impossible to ask them, given the
volume of communication in the global internet, to substitute silence
for the government's responsibility to inform its citizens.
In the 21st century, you cannot censor your way to public tranquility.
Various Civil Society organizations including Sflc.in have been trying
to help GoI, DIT in particular, in making responsible policies with
respect to Intermediary Liability Rules. But how do we work with a
government to make appropriate rules when they show they won't follow
them? Is the Government being ill-served by its advisers, who are
leading it into a position in which they cannot expect people of good
will, who have believed in the Government's seriousness to take
seriously anything it says or does?
When economists talks about regulatory overbearance and warn about a
regulation a day keeping the business away, there are lessons to be
learned for all sectors. This micro management of the public discourse
through businesses will only push India out of the global discussion and
not lead to any kind of public tranquility. The cataclysmic cost to the
economy, to the free speech ideas, and a tarnished international image
of the largest democracy will be hard to ignore. This will only turn us
into a society incapable of achieving anything, economic prosperity,
liberty or security.
An open infrastructure could curb high-frequency trading disasters
Blog post by Aaron Williamson. Please email any comments on this entry to <firstname.lastname@example.org>.
In yesterday's New York
the SEC's suggestion that mandated software testing could prevent
automated-trading catastrophes like the one
bankrupted Knight Capital at the beginning of this month. More
testing won't work, according to Ullman, for a few reasons. First,
computer systems are too complex to ever "fully test," because they
comprise multiple software and hardware subsystems, some proprietary,
others (like routers) containing "inaccessible" embedded code. Second,
all code contains bugs, and because bugs can be caused by interactions between modules and even by attempts to fix other bugs, no
code will ever be completely bug-free. And finally, it is too
difficult to delineate insignificant changes to the software from
those that really require testing.
Ullman's critique of a testing-centric solution has some
merit, although few professional developers test individual "coding changes" (they really do test entire systems anytime changes are introduced). But her proposed alternative is heavyweight and
difficult to square with the needs of the industry. She proposes making
brokers liable for losses caused by trading errors in order to induce
them to write "artificial intelligence programs that recognize unusual
patterns" and shut down runaway trading algorithms. Her model is the regulation of
credit card companies: since they're liable for most fraudulent
charges, they've created software to track purchases and put holds on
accounts showing suspicious activity. In Ullman's scheme, the SEC
would also create its own electronic sentries as a backstop.
I doubt Ullman's assumption that the rogue trading program problem can be fought with A.I. as successfully as credit card fraud. The speed of automatic trading—the systems can evaluate and
execute thousands of trades per second—makes automated trouble-shooting much trickier. Even very fast A.I. would likely take more than a few seconds to spot bad behavior reliably. This is time enough for several thousand erroneous trades to be made. And false positives would be far more expensive, since for every second
the program was down, thousands of legitimate trades would not be
made. In the credit card context, where fraud happens at human speed,
it makes sense to have humans double-check the computer's
determinations, but Ullman's suggestion that the same human-backup
process would port easily to the algorithmic trading context is
Algorithmic traders could reduce their error rate much less
expensively (and more realistically) by collaborating on a common
infrastructure for executing trades, using free and open source
software everyone could review, test and improve. Trading firms are understandably tight-lipped about the
algorithms that actually choose which trades to make; these are the
source of their competitive advantage over other
firms. But most of the pieces of everyone's high-frequency trading systems are
not so secret, including the real-time operating system, high-volume message
queuing, and software actually executing the selected
trades. By opening, standardizing, and collaborating on these
ancillary but complex components, trading firms could reduce errors
and improve reliability, all without exposing their trading
strategies. A common infrastructure used and collaboratively produced
by several firms would be better-tested than the balkanized systems in
use now, and less prone to the interaction effects that Ullman finds prevalent in complex systems. Open code would also enable the SEC
to audit the system directly, without the complexity and expense of AI "watchers."
many firms believe their competitive advantage derives partly from proprietary
kernel modifications or optimizations to their messaging systems. But the Knight Capital failure,
Flash Crash, and similar episodes have made it clear that trading
firms—as well as their investors and the market as a whole—pay a heavy
price for their secrecy. That
price will only increase if the SEC passes expensive regulations to
deter future failures. If the firms can work together now, they may
find that, by turning their infrastructure into shared, standard
components, they can not only keep the regulators at bay, but also free their own
resources to concentrate on the trading algorithms that are the true value add to their business.
Microsoft confirms UEFI fears, locks down ARM devices
Blog post by Aaron Williamson. Please email any comments on this entry to <email@example.com>.
At the beginning of
warned the Copyright Office that operating system vendors would
secure boot anticompetitively, by colluding with hardware partners to
exclude alternative operating systems. As Glyn Moody points out, Microsoft has wasted no time in revising its Windows
Hardware Certification Requirements to effectively ban most alternative operating systems on ARM-based devices that ship with Windows 8.
The Certification Requirements define (on page 116) a "custom"
secure boot mode, in which a physically present user can add
signatures for alternative operating systems to the system's signature
database, allowing the system to boot those operating systems. But for
ARM devices, Custom Mode is prohibited: "On an ARM system, it is
forbidden to enable Custom Mode. Only Standard Mode may be enable."
[sic] Nor will users have the choice to simply disable secure boot, as they will on non-ARM systems: "Disabling Secure [Boot] MUST NOT be possible on ARM systems." [sic] Between these two requirements, any
ARM device that ships with Windows 8 will never run another operating system, unless it is signed with a preloaded key or a security exploit is found that enables users to
circumvent secure boot.
While UEFI secure boot is ostensibly about protecting user security, these non-standard restrictions have nothing to do with security. For non-ARM systems, Microsoft requires that Custom Mode be
enabled—a perverse demand if Custom Mode is a security
threat. But the ARM market is different for Microsoft in three important
- Microsoft's hardware partners are different for ARM. ARM
is of interest to Microsoft primarily for one reason: all of the handsets
running the Windows Phone operating system are ARM-based. By contrast,
Intel rules the PC world. There, Microsoft's
secure boot requirements—which allow users
to add signatures in Custom Mode or disable secure boot
entirely—track very closely to the recommendations of the UEFI
Forum, of which Intel is a founding member.
- Microsoft doesn't need to support legacy Windows versions
on ARM. If Microsoft locked unsigned operating systems out of
new PCs, it would risk angering its own customers who prefer Windows
XP or Windows 7 (or, hypothetically, Vista). With no legacy versions to
support on ARM, Microsoft is eager to lock users out.
- Microsoft doesn't control sufficient market share on mobile
devices to raise antitrust concerns. While Microsoft doesn't
command quite the monopoly on PCs that it did in 1998, when it was
for antitrust violations, it still
90% of the PC operating system market—enough to be concerned
that banning non-Windows operating systems from Windows 8 PCs will
bring regulators knocking. Its tiny stake in the mobile market may
not be a business strategy, but for now it may provide a buffer for
its anticompetitive behavior there. (However, as ARM-based "ultrabooks" gain market share, this may change.)
The new policy betrays the cynicism of
initial response to concerns over Windows 8's secure boot requirement. When kernel hacker Matthew Garrett expressed his concern that PCs shipped with Windows 8 might prevent the installation of GNU/Linux and other free operating systems, Microsoft's Tony Mangefeste replied, "Microsoft’s philosophy is to provide customers with the best experience first, and allow them to make decisions themselves." It is clear now that opportunism, not philosophy, is guiding Microsoft's secure boot policy.
Before this week, this policy might have concerned only Windows Phone customers. But just yesterday, Qualcomm announced plans to produce Windows 8 tablets and ultrabook-style laptops built around its ARM-based Snapdragon processors. Unless Microsoft changes its policy, these may be the first PCs ever produced that can never run anything but Windows, no matter how Qualcomm feels about limiting its customers' choices. SFLC predicted in our comments to the Copyright Office that misuse of UEFI secure boot would bring such restrictions, already common on smartphones, to PCs. Between Microsoft's new ARM secure boot policy and Qualcomm's announcement, this worst-case scenario is beginning to look inevitable.
Cory Doctorow at 28c3: The Coming War on General Purpose Computation
Blog post by Aaron Williamson. Please email any comments on this entry to <firstname.lastname@example.org>.
In his keynote from the 28th Chaos Communication Congress last week, Cory Doctorow outlines the primary threat to software freedom in the 21st century: that as our lives become more dependent upon general-purpose computers, the attempts of industry and government to control computing will fundamentally endanger our personal liberty. Using the now-familiar history of digital rights management—its rise, its failure, and legislative efforts to enforce it—Cory illustrates how those threatened by technology will inevitably seek to cripple it. But the so-called copyright wars waged by content owners, he says, were only "a skirmish":
The problem is twofold: first, there is no known general-purpose computer that can execute all the programs we can think of except the naughty ones; second, general-purpose computers have replaced every other device in our world. There are no airplanes, only computers that fly. There are no cars, only computers we sit in. There are no hearing aids, only computers we put in our ears. There are no 3D printers, only computers that drive peripherals. There are no radios, only computers with fast ADCs and DACs and phased-array antennas. Consequently anything you do to "secure" anything with a computer in it ends up undermining the capabilities and security of every other corner of modern human society.
This problem has been at the center of SFLC's recent work. It's the reason we've fought for disclosure of the software running implantable medical devices and are asking the Copyright Office to limit the DMCA's anti-circumvention provisions to ensure that people can install whatever software they choose on their personal computing devices.Thanks to Cory for his clear and accessible explanation of the threat to free computing and for his call (at 36:00) to support SFLC's efforts to fight restrictive implementations of UEFI.
You can download a high-resolution copy of the entire speech here or watch it on YouTube (Flash required).