Daniel Ravicher pointed out that software freedom has passed the larval stage, and is now going from general ideals and standards to the maturity of implementation. As software freedom matures, licenses and definitions take on weight; note the Software Freedom Law Center's suit against a GPL infringer.
James Vasile talked about managing copyrights in a FL/OSS project, in a talk that overlapped with section 5 of "Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers". Like many of the lawyers, he pointed out that doing a little bit of tedious work up front could save a lot of legal and market hassles later. In the case of copyrights, setting the expectation that the project owns the copyright to all the code, and setting that expectation at the first moment that you see a community forming, prevents resistance. It also makes enforcement of the copyright much easier; if you see that some big evil company is stealing your code without redistributing its modified source, then the project can go after that company without having to check with every single contributor to the codebase that's been infringed.
One possible wrinkle for contributors who want more control: joint copyright. The contributor assigns the copyright to the project, and the project then gives a license to the contributor. The license lets the contributor do anything with the code, except exclusively assign copyright to someone else. It's a clever compromise that lowers risk for everyone.
Vasile recommends that each contributor, the first time she contributes code, documentation, or graphics, certify in some way that she owns the copyright to her work (specifically that no employer has a right to it under work-for-hire rules or the like) and that she's assigning or giving that right to the project. The gold standard would be a signed paper statement, but only a popular project with lots of momentum can afford to inconvenience its developers that much. So, instead, email, electronic signatures, or a clickthrough webpage is better than nothing; get as paper-y as you reasonably can. At any given time, you should be striving towards an auditable code repository, where you can see who has code in the codebase and whose code has been overwritten or removed.
Registering copyrights formally with the US government, Vasile said, is really only necessary if you think you'll need to enforce your copyright against someone else. If that's so, then yes, register ASAP to get the damages clock running.
My questions that I didn't get to ask included: is there anything analogous to an orphaned works problem if a FL/OSS project that owns lots of copyrights goes bankrupt? And where's the inflection point where the question of copyright assignment goes from "don't need that yet" to "we need that yesterday"?
Aaron Williamson started off telling us that he was here to persuade us to use a very inefficient method, the cleanroom process, when reverse engineering -- that is, reimplementing functionality from a proprietary project within our open source projects. I am guessing that these tips apply just as well to proprietary projects trying to duplicate competitors' features.
Clean-room process is often a curative, rather than a preventative, for concerns that a portion of code is encumbered. The rumors fly that your codebase incorporates actual stolen code, or that one of your developers once worked on the competing product. So it's time to do a cleanroom.
The three groups or people in the cleanroom are:
Of course you can do this in one physical location, with a literal cleanroom. But if the computers in use by the cleanroom team are auditable and secure, remote teams can also create and work in virtual cleanrooms, as long as they can prove after the fact that the cleanroom team didn't access dirty code. Norwood elaborated that all the cleanroom's internal communication, and all of its communication with the facilitator/liaison and with the outside world (especially any research), has to be on auditable machines. The machines and their URL histories and other logs have to be provably nontampered, but evidently this is doable.
Williamson presented details of how the courts determine whether your reverse engineering was kosher, including thoughts on the DMCA, various precedents, and the Altai Abstraction-Filtration-Comparison test. Williamson jested when he brought this last one to our attention as an excellent legal test (a three-part name with hyphens). The upshot: specification teams have to make sure they are not wholesale copying the underlying structure of the code, at least anything that's innovative or interestingly elegant.
And if you're decompiling code then that might be infringing, too. Did you know that clickwrap agreements and end user license agreements (EULAs) are generally enforceable? I'd been hoping otherwise. Where's the bargaining, the negotiation? Bleah. So it's no longer clear whether we have the right to decompile object code, and if you've agreed to a EULA you generally can't.
Matt Norwood then spoke about reverse engineering in a talk he called "When keeping IT real goes wrong." You see, in the olden days, most cleanroom projects were done carefully and strictly, both by proprietary shops and FL/OSS projects. But these days, FL/OSS projects really only make an attempt at cleanroom protocol in the case of high-risk projects, like firmware, drivers, and network interoperability.
In other cases, they get sloppy, and don't contact lawyers until AFTER the reverse engineering work. And sloppy cleanroom work in reverse engineering means that you'll come under suspicion, and that you'll need to take remedial action ranging from an audit to complete rewriting. If you wrote the code the wrong way around the first time, you have to make a tough choice: throw away a mass of code to stay clean, or cut influential developers out of the loop during the rewrite?
Suspicion arises when a similar or related project has a code leak, or is rumored to. It arises if a contributor or patch is rumored to be tainted with access to dirty code. And it can lead to legal hassles, or to customers not wanting to use your product out of legal fears. The "SCO risk" will lead to adoption pushback.
Norwood's advice on doing a code audit dovetailed with Vasile's advice on having an auditable repository. Look at the commit logs, datestamps, comments, assignments, and the records of who actually wrote the code regardless of the commit records.
On the hierarchy of risk, Norwood suggests that looking at proprietary source code is worst, decompilation is slightly less bad, intermediate copying of copyrighted works is still bad, and that testing is a mild risk. Some EULAs prohibit testing the software. But doing blackbox testing, especially over a network, to observe the behavior of the binary as it runs is a more grey area. And it's completely okay to read public documentation put out by the company or other people.
These steps protect you from copyright infringement. But don't forget that copyright is but one of the intellectual property quartet: copyright, patent, trademark, and trade secret. So if you're copying the Foo product, don't call yourself OpenFoo.
Karen Sandler had some really interesting insights into how open source projects can organize themselves legally to minimize hassle and risk.
Incorporation is the classic legal move to shield an individual from liability (copyright infringement, users whose computers blew up, you name it). If you incorporate as a nonprofit, donations are tax-deductible, and the legal entity gives you a way to feel good instead of greedy and weird about taking donations. And the entity is something that makes it easier to get insurance and indemnification for events, assign copyright to, and generally use to make contracts. The liability shield, mind, only works if you don't "pierce the veil" by mixing corporate assets with your own.
We went into tax exemptions and other nuances for 501(c)3 nonprofits and 501(c)6 trade associations. In either case, there's often a gap between common FL/OSS organization styles and the organizational structure that tax/law regulations assume you have. A board? Seven people who come to quarterly meetings to oversee things? The SFLC can help your project navigate these requirements.
And it's important to navigate them properly. Sometimes projects fall into lulls where no one does any work on them for months or years. If no one steps up to do the tax filings or other necessary paperwork, Oh Noez.
So this is where the conservancies and umbrella organizations come in. Instead of FL/OSS projects dealing with this stuff themselves, they live within the Apache incubator, Software in the Public Interest, the Software Freedom Conservancy, or the FSF -- a healthy pluralism of ideologies and organizational structures. These conservancies take care of paperwork and help nurture growing projects via mentoring and scenario planning. (And they prepare for project termination; leftover assets can get used by living projects.) Once a project gets big enough, and its deep pockets are increasing liability/risk to the other groups under the umbrella, it can graduate.
Nonprofits can use for-profit activities to make money (The Mozilla Foundation is an example). But be careful of taking in too great a proportion of "unrelated business income" (money from activities that don't relate to your mission). Advertising income is the controversial element here. And the "public support test" says that real nonprofits should have a wide donor base, rather than just being in the pocket of one rich patron.
My question: what other legal options do we have, other than incorporating or working within an umbrella conservancy?
The Register and Software Development Times pieces cover Richard Fontana's patents talk in enough detail for most readers. Some bits I found especially interesting:
Fontana explicitly said that the question of whether software is patentable seems settled to most lawyers, but is a live question to the SFLC. He also spoke hopefully of a near-term backlash against the pro-patent era. Various possibly contradictory court cases speak to this (Diamond, State Street, Gottschalk....)
Even if we allow for the legitimacy of software patents, some are more valid than others. Software developers have a broad and deep domain knowledge, so they have a head start on indignantly finding out that some old discovery's been patented. Software patent filings often fail the novelty, definiteness, enablement (the specs should allow someone skilled in the craft to replicate the claims), and obviousness tests, but instead of blaming the PTO maybe we should blame the patent attorneys drafting the things. Another problem is that the patent application does not require pseudocode or source code, and that companies patenting their methods often want to keep their source code a trade secret.
People seem to be using copyright more than patent for IP protection of their software, especially since the researchers/artists in FL/OSS find copyright a more natural fit.
It's tough for a developer to absolutely make sure that she isn't infringing someone's patent, but most of the time you don't have to worry about it. Yes, a work of software has one copyright and might infringe hundreds of patents, and the costs of searching for possible infringements is sky-high. Yes, issued software patents often seem to fail the novelty test. But probably no one's going to sue you, because they don't care or because you don't have deep pockets. The threat to your project would be a ripple effect of risk from the patentholder threatening your customer base and thus your project's ecosystem.
SFLC advises free software projects on patent issues. Fontana noted that one of their common roles is to calm down developers. For instance, there's no need to worry about broad claims in a just-filed patent application; during the examination process, those will probably get cut down. SFLC helps projects develop patent defenses, such as licensing, noninfringement defenses, invalidating the patent, agreements from IP holder that they won't sue, or even agreements with standards bodies to get cheap or free licenses.
One way the SFLC helps with noninfringement or invalidity claims is by gathering prior art. Prior art has to predate the patent filing by one year or more, and -- all gathered together, in one piece or many -- has to anticipate all the claims in the patent. (Another great thing about using source control is that is ensures prior art has a date on it!) Using this evidence, the SFLC will challenge patents via the PTO reexamination process (it's cheaper than suing) and try to get claims invalidated or at least narrowed. The risk is that, if the patent emerges from this challenge unscathed, it's now stronger! That happens about 20% of the time, Fontana said.
The SFLC also helped a lot with the drafting of version 3 of the GPL, including the patent provisions. (Eben Moglen later talked about how difficult and rewarding that process was.)
Should YOU, the open source developer, apply for a patent? Probably not. A few patents will not give you leverage against patent trolls, or companies with thousands of patents.
I didn't get to ask the question: other than help the SFLC with its invalidation (and possibly lobbying) efforts, what can we do to stem the tide of horrible patents?
Eben Moglen was absolutely, astonishingly inspiring. I wish I had a video to show you, or a full transcript. Here are videos of his other speeches so you can get a sense of his style and presence.
Moglen spoke of internationalizing the SFLC, getting beyond the inherent localism of the law to become longitudinal experts in free software. What is it to be licensed to practice law in a particular country? That meaning differs among students, licensing organizations, and the countries' governments.
The SFLC does a lot of hacker work, work Moglen thought he'd left behind -- one harrowing tale involved trying to reconstruct a destroyed Subversion repository from Crete. He often happens upon lawyers doing code reviews, and has decreed that in the future SFLC shall hire no lawyer less hackerish than one of their Daniels (I'm not sure which). Lawyers have to be bilingual in source code and the civil/criminal codes. He also expressed his amazement that he runs a law practice that has no physical law library.
How shall the SFLC go global? How and where can they make the most long-term difference? He wants to prevent future litigation and heartache by helping coders use safer processes; he pointed out that the SCO debacle was just one salvo of irresponsible fact-muddling by a dying company. Software freedom's enemies are both greed and incompetence. I thought of EMILY's List when he suggested that SFLC solving one problem every week could have a tremendous impact down the line.
But where should they be looking for the next big thing? Not in the dorm across the street, as we're used to, he cautioned -- you are probably on the wrong continent. SFLC is opening a New Delhi office next year.
Moglen believes that the SFLC needs not only to practice law but to publish it as well. He pointed to the short pieces and primer we'd received and said they weren't short enough; they needed to fit on one computer screen -- not two! -- so that busy people could read them.
What are the productive units of the 21st century? Communities. So the Software Freedom Law Center is positioning itself as part of the free software community, and finds itself acting as an ambassador to and from and within that community. And perhaps that sort of niche-specific positioning is replicable.
Returning to the bang-for-the-buck question, Moglen pointed out that the 20th century model was high-impact litigation in the public interest, and that it wouldn't work for software freedom. Instead, as a student of Richard M. Stallman, Moglen wondered: what if lawyering could be like hacking? And he believes that the SFLC will, in the next several years, develop "legal technology" worthy of being copied -- I'm assuming he means both bits of code and legal principles, documents, and models. (I wonder whether the GPL is an example of legal technology.) And a decade from now, SFLC will have cool stuff to show us, but right now "School's open."
I can't do it justice. Moglen is charismatic and a practical optimist, and I'm reassured that he's on my side in the cause of software freedom.