Joomla! 1.5 - 'Experience the Freedom'!. It has never been easier to create your own dynamic Web site. Manage all your content from the best CMS admin interface and in virtually any language you speak.
The Software Freedom Law Center Blog.
All blogs at the Software Freedom Law Center.

  • Twin Peaks and the GPL

    Blog post by Eben Moglen. Please email any comments on this entry to <>.

    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 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 <>.

    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 twitter accounts.

    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 Facebook, Twitter, YouTube, BlogSpot, WordPress, Google Plus, Wikipedia, 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 don't understand?

    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 rumor-mongering.

    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 busy issuing orders 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 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 <>.

    In yesterday's New York Times, Ellen Ullman criticized the SEC's suggestion that mandated software testing could prevent automated-trading catastrophes like the one that shook the market and nearly 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 ill-considered.

    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."

    Doubtless many firms believe their competitive advantage derives partly from proprietary kernel modifications or optimizations to their messaging systems. But the Knight Capital failure, the 2010 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 <>.

    At the beginning of December, we warned the Copyright Office that operating system vendors would use UEFI 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 respects:

    • 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 prosecuted for antitrust violations, it still controls around 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 Microsoft's 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 <>.

    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).