Original URL: https://www.theregister.com/2007/10/13/sflc_primer/
Freedom loving lawyers prime primer on open source code
Penguin army forms in India
Posted in Channel, 13th October 2007 16:49 GMT
The Software Freedom Law Center will soon reveal the culmination of a year and half of steady revision and editing: a legal primer for free software projects, designed to make complex issues understandable to the layman. The primer, which will be disgorged on the Law Center’s web site on Monday, walks through issues such as the GNU public license (GPL) and how to use it correctly, copyright assignment and enforcement, and so on.
To coincide with the primer’s release, the SFLC hosted a day-long Legal Summit at Columbia Law School, consisting of panels on the key topics discussed in the primer: copyrights, reverse-engineering and clean-room development, nonprofit organizations, patents, and international law. The panels were hosted by the SFLC’s lawyers, and attracted a diverse crowd.
In attendance were representatives of companies such as Intel, Microsoft, and Hewlett Packard; lawyers (and lawyers in training); advocates from well known groups such as the Foundation for a Free Information Infrastructure (FFII), the Electronic Frontier Foundation (EFF), and the Gnome foundation; and a few lowly journalists.
Attorney Richard Fontana lectured on patents, an issue certain to raise the blood pressure of any open source programmer. Patents aren’t assets that free software projects try to acquire, Fontana explained, they’re seen as nuisances more than anything else. Patents are “a kind of monopoly, though the patent office won’t say it,” he points out, “not to practice an invention per se, but to prevent others from making, doing, or selling something.”
Mental steps
Thirty years ago, there was little argument about where software fell in the patent world. The “mental steps” doctrine stated that mere computerization of the mental process of accomplishing something wasn’t a patentable process, and mathematical algorithms fell under that doctrine. But can’t all software be reduced to mathematics? Today, the pendulum has swung the other way, with software patents being handed out perhaps too readily.
But why are open-sourcers so anti-patent?
Compliance with patents seems nearly impossible, for one thing: Software is inherently more complex than other things, and a large program potentially infringes on hundreds of patents. The cost of searching out that infringement is just too high. Plus reading and understanding patentspeak is nearly impossible; you need a lawyer just to be able to read the damn things.
Another big complaint: patents are supposed to detail how to reproduce or do something, a constraint software patents often fall short of. Should patent applications include some form of source code?
Fontana theorized that programmers feel their work is closer to research work or art, and thus believe strongly in copyrights instead. “Copyright law protects expression,” Fontanta said, “patent law protects ideas and technological principles.”
Aaron Williamson and Matt Norwood presented a thorough analysis of reverse engineering and clean-room development - a remarkably dry run through a seemingly fascinating topic. "Reverse engineering" carries a magical allure to it, a mystique that’s destroyed by a blow-by-blow breakdown of the best practices procedure behind the technique and its legal ramifications.
“When Sega’s code was reverse engineered so that someone could build game cartridges that competed with Sega’s cartridges, the courts decided that if you were reverse-engineering to get to the idea within the cartridge, than the engineering was fair use,” Williamson pointed out. The now ubiquitous end-user license agreement prevent simple reverse engineering with blanket provisions - a fact iPhone hackers would be wise to take note of.
To avoid those legal pitfalls, hackers can buy pre-activated iPhones on eBay, thus avoiding the EULA, or follow the procedure Williams outlined for proper reverse engineering: First, there are developers in the clean room, people with no prior access to the code in question and who won’t have access to the rest of the team. For them, isolation is key.
As Norwood joked, “The first rule of clean room is you do not talk about clean room. Less obvious is the second rule of clean room, which is you do not talk about clean room.”
The other two groups are the specification team, people who have access to the potentially infringing code that the project aims to replace, and the liaison, who works between the other teams and ensures their separation.
Successful reverse engineering projects are usually planned out in advance and executed according to these stringent guidelines. But often, open source developers don’t think about these issues until it’s too late.
Eben Moglen, chairman of the Software Freedom Law Center, wrapped up the evening with a passionate restatement of the Center’s goals. He’s excited about the new office that should open in New Delhi next year and support for the millions of open source coders he envisions coming out of the subcontinent in the immediate future.
Moglen sees it as his mission to defend the world’s free software programmers. As he put it, “the kid’s gotta code . . . and he can’t defend himself against the man who says, 'you’ve gotta pay me for my idea which you just had.'” ®