Safe-harbor compliance for FOSS projects
Blog post by Aaron Williamson. Please email any comments on this entry to <email@example.com>.
"DMCA" is a four-letter word among free and open source software developers, and for good reason: the 1998 act criminalized an entire category of programs and has been grossly misused in numerous cases. It's in the news yet again this week, as activists are fighting to make it legal to carrier-unlock cellphones despite the Librarian of Congress's decision not to exempt unlocking from the DMCA's anti-circumvention rules.
But the anti-circumvention rules are only one part of the DMCA—it also put in place the safe harbors that protect online services from liability for their users' activity. These too have been the subject of some controversy, as large content owners have routinely abused the notice-and-takedown process to censor materials protected by fair use. But they've also done a lot of good. Before, it was difficult for service providers dealing with user-uploaded content to predict their potential liability for the infringing activity of their users. The safe harbors provide clear rules for avoiding secondary liability related to user content.
Why free and open source software projects should care about safe-harbor compliance
Popular content hosting sites like YouTube are the most common targets for infringement claims related to user content, but they're not the only ones who can benefit from the safe harbor. Any online service that allows users to post content—whether multimedia, software, or text—can be used for infringement and exposed to liability.
Free and open source social networking and content-hosting services are obvious candidates for the safe harbor, but even projects whose software isn't hosted should take a look at their online presence. Does the project host a source code or add-on repository? Forums, project management software, or other collaboration tools? Any online tool that allows users to post content potentially risks secondary liability.
Obviously, the risk depends upon the service: a source code repository accessible to a few trusted developers may be relatively safe, while a photo-sharing site with open registration is more likely to run into trouble. Whether a DMCA policy makes sense for your project depends on your particular situation, but its a question worth considering carefully: a compliant policy gives you a solid defense to claims related to user activity and without one, dealing with even a bogus claim could cost significant time, effort, and even legal expense.
How to qualify for the safe harbor
Qualifying for the safe harbor involves some one-time eligibility requirements and well as some continuing obligations. The up-front requirements are pretty simple:
- Designate someone to receive notices from copyright holders about infringing content. You have to provide the person's name, address, phone number, and email address to the Copyright Office (by mailing in a form) and post the same information publicly on your website.
- Adopt a policy for terminating the accounts of users who repeatedly infringe copyrights. The law doesn't say what the acceptable bounds of such a policy are except that it must be "reasonably implemented," leaving projects some room to determine what an appropriate policy looks like for their users.
Ongoing compliance: notice & takedown
Once you've met the initial qualifications for the safe harbor, you have to observe a few rules to remain in compliance. The most important are the rules about responding to infringement notifications:
- When you receive a valid infringement notification, you must "respond expeditiously" to remove the allegedly infringing content or disable access to it. The law doesn't define "expeditiously,", but a good rule of thumb is to act within a week. To be valid, a notice must meet the seven notice requirements in the law, e.g. it must be signed by an agent of the copyright holder, must adequately identify the allegedly infringing content, etc.—you are not required to judge for yourself whether the material is actually infringing. You are also not required to act upon a notice that "substantially fails to comply" with the notice requirements. But you should be careful about ignoring any notice, because...
- If you become aware of infringement you must remove or disable access to the infringing content regardless of whether you receive a valid notice. An invalid notice may be sufficient to make you legally "aware" if it contains contact information for the sender and properly identifies both the infringing content and the copyrighted work infringed. However, mere suspicion is not enough—before you have an obligation to remove content, the fact that it's infringing must be "apparent."
- When you remove content, you have to notify the user who posted it. If the user sends you a valid counter-notification claiming a good-faith belief that the material was removed because of a mistake or misidentification, you must:
- notify the sender of the original notification that you will put the content back up in 10 business days; and then...
- put the content back up after 10 business days. (You cannot put the content back up before 10 business days have passed, nor can you wait longer than 14 business days to put it back up.) But, if you receive notice from the copyright holder that he or she has "filed an action seeking a court order" to prevent the user's alleged infringement, you are not required to put the content back up.
In addition to these important rules, you may not "interfere with standard technical measures" used to identify or protect copyrighted works. While this may sound like a requirement to enforce DRM, it's quite limited. It requires no affirmative accommodation of DRM, just non-interference. And it essentially only applies to widely adopted standards. In short, if you're not actively stripping DRM or copy-control information off of uploaded files, it's probably not something you need to pay much attention to.
Writing a copyright policy
While the only information you're required to post on your site is the contact information of your DMCA agent, most services include a bit more information about how they deal with DMCA claims. This can be a good way to discourage illegitimate infringement notifications and also to tell users how to submit a counter-notification if their content falls victim to an overzealous copyright holder. The Electronic Frontier Foundation's copyright policy includes a good example of a DMCA policy with an advocacy component.
You should put the DMCA agent's information (and anything else you choose to include) somewhere readily accessible. If you have terms of service or a similar site-wide usage policy, you can put your DMCA policy there. Alternatively, you can create a stand-alone DMCA/copyright policy and put a link in your site's footer or another easily accessible location.
There's unquestionably some irritating bureaucracy involved, but qualifying for the safe harbor isn't difficult, and can save projects a lot of time and trouble. Not every site or service is at risk of infringement claims for user content, but if your site or service allows users—particularly anonymous or otherwise untrusted users—to post content, you should consider putting a safe harbor policy in place.
Red Hat and Rackspace check troll's math in motion to dismiss
Blog post by Aaron Williamson. Please email any comments on this entry to <firstname.lastname@example.org>.
Several times in recent years, opponents of software patents have looked hopefully to Congress and the Supreme Court for a solution to the expensive problem of software patents, and several times we've been disappointed. The narrow Bilski v. Kappos ruling invalidated one business method patent but left the question of software patents to one side, and even arguably weakened a rule—the "machine-or-transformation" test—intended to limit the scope of patentability. The reforms of the America Invents Act were half-hearted; they provided additional opportunities to challenge patents at the USPTO, but did not fundamentally affect the rules for patenting software.
Despite these missed opportunities, there are signs of slower but consistent reform in the courts, and yesterday's ruling in the Eastern District of Texas in Uniloc v. Rackspace is one of them. The Uniloc ruling is about as good as it gets for a defendant in a software patent case: the judge dismissed the case at an early stage on the grounds that the claim at issue described an unpatentable mathematical formula.
Uniloc is a self-described "independent laboratory" with a small software business and a thriving patent-licensing division. Its website ominously assures readers that "[t]he cost of licensing is quite modest when compared to other alternatives." It sued Rackspace (which was defended by Red Hat under its Open Source Assurance program) over a basic technique for computing floating point numbers, which it claimed Rackspace infringed by virtue of its use of Linux:
Claim 1. A method for processing floating-point numbers, each floating-point number having at least a sign portion, an exponent portion and a mantissa portion, comprising the steps of:  converting a floating-point number memory register representation to a floating-point
register representation;  rounding the converted floating-point number;  performing an arithmetic computation upon said rounded number resulting in a new floating-point value;  converting the resulting new floating-point register value to a floating-point memory
You can tell this is a software patent of the old school (it was filed in 1995), because the claim doesn't reference a machine, even one so abstract as a general purpose computer. This essentially required the court to find that the patent failed the "machine-or-transformation" test, which (as modified by the Supreme Court) says that a "useful clue" to a process's patentability is whether it "(1) is tied to a particular machine or apparatus, or (2) it transforms a particular article into a different state or thing." (The patent failed the "transformation" part of the test because, according to binding Federal Circuit precedent, manipulating data does not produce a "meaningful transformation.")
Since the machine-or-transformation test is only a "useful clue," the court also analyzed the patent under Section 101 of the Patent Act, which has been held to exclude laws of nature, physical phenomena, and abstract ideas (including mathematics). In invalidating this retrograde patent under 101, the court relied heavily on Gottschalk v. Benson, the 1972 case that first clearly stated that algorithms were abstract mathematical formulae, and hence unpatentable. Given Benson's shabby treatment at the hands of the Federal Circuit over the last couple of decades, its prominence here is refreshing.
The early disposal of this patent by a patent-friendly court is an encouraging sign for everyone writing software under the shadow of patents. Congratulations to Red Hat and Rackspace on their victory.
Always ask about the business model
Blog post by Aaron Williamson. Please email any comments on this entry to <email@example.com>.
The New York Tech Meetup is an impressive gathering of the guiding lights (and hopefuls) of the so-called "Silicon Alley" community. With over 27,000 members, NYTM is the largest meetup in the world and has become so influential that it's attracted guest appearances by New York Mayor Michael Bloomberg and United States CTO Todd Park, and coaxed statements from both 2012 presidential candidates about how their policies will benefit the New York tech community. Every meetup follows a simple format: several New York technology startups present demos of their products and then answer questions from the audience.
NYTM audience members are told there is only one rule about questions: don't ask about the business model. The stated reason for this is to maintain a focus on tech; the presenters' business models tend to be familiar—advertising, freemium, etc.—and so aren't the interesting aspect of their products.
"Don't ask about the business model" could also be called the founding ethos of this community: what you're building is the important thing, how you'll make money is a distant second. Facebook and Twitter didn't have business models when they built the most popular social networks in the world. IFTTT doesn't have an obvious business model and it's the talk of the tech press. With an awesome idea and Series A funding, there's plenty of time to figure out a business model once you've realized your idea.
But "don't ask about the business model" is beginning to sound like a Freudian slip: Don't ask, because if you examine the business models too closely, what you find might make you uneasy. We're far enough into the second dot-boom to see the business models that time and over-reliance on venture funding produce, and there's plenty of reason for discomfort.
Patents: polluting the software ecology
VC funding, like all free money, isn't free. Investors are interested in startups not only for their technical excellence but also for their profit potential. They may be willing to give startups without a ready-made business model time to figure one out, but usually only if they believe their investment will be protected until it pays off. And (with few exceptions) that means taking Warren Buffet's advice and building a "moat" around the business—in most cases, a moat made of patents.
By now, most software developers are aware of the tremendous harm that software patents are causing to the software ecology. Software giants are wasting hundreds of millions of dollars every year suing each other and fending off attacks from patent trolls—holding companies whose sole purpose is to acquire patents and use them to extract royalties from software producers. And while trolls were once mainly concentrated on deep-pocketed players, they increasingly target smaller companies that will go down easy and boost the perceived value of their holdings. As a recent study found, startups fare much worse than established companies in these battles and are likelier to sustain lasting damage or even shut down as a result.
Despite these grave problems, startups feel like they have no choice but to seek patents, because VCs demand it. Maybe they try not to think about it, or maybe they believe they're not part of the problem, that they'd never use their patents to keep other developers down.
But this misses the point. VCs don't want their startups to get patents to keep other software companies from beating them to market. A startup's meager portfolio—at best a handful of patents—won't deter a troll or stand up against the war chest of a large company like Google or Apple. Even against a smaller competitor, a couple of patents aren't much use, because the legal fees required to assert them can swallow even a decent Series A round whole.
The truth is that the patents aren't a moat around the startup's product, but around the VC's investment. As every VC knows, a huge proportion of startups fail—as many as 90%. Given this high failure rate, VCs don't see startups as investments in themselves, but as pieces of an investment portfolio; they've placed bets across the board, expecting most of them to lose.
Patents are VCs' hedge against these inevitable losses. When a startup with patents fails, its patents become the property of its funders, compensation for the unrecouped startup capital. The funders have little use for the patents once the startup that produced them is out of the picture, so the patents become commodities to be sold to the highest bidder. Increasingly, the highest bidders are patent trolls, and the failed startup has inadvertently made the environment for software innovation more radioactive by exactly one (or two or seven) patents.
Strip-mining user data
If 90% of startups fail, then 10% succeed and need a business model to ensure their continued growth after the VC money runs out. Startups without a built-in business model have a few established paths before them: a handful of direct-payment models (pay-per-play, subscription, e-commerce, etc.) and advertising.
Depending on the startup, some of these options are a tough sell. Those that target professional users or businesses can put a price tag on their services without too much grumbling. But social media services (like Twitter and Facebook) and convenience services (like bitly) can typically only attract enough users by starting out free, and users used to free service can rarely be convinced to pay up later. The time-honored solution to this problem is to trade in the currency that users have been paying you all along, but don't particularly value: their personal information.
Facebook, Twitter, Foursquare: all of the most successful social media services have ultimately balanced their books by ratcheting up their exploitation of users' data bit by bit. Each gathers an ever-more-detailed profile on every user and sells advertisers the ability to target highly particularized user demographics. Each exploits sharing between users to derive their social networks and learn how information—product preferences, political affiliations, news items—propagates through those networks, all to improve advertising partners' results.
As with software patents, the problems with commoditizing user data are well-known. The hidden nature of the bargain is problem enough: most users do not fully understand what they're giving away to these free* services, and fewer still comprehend that merely by tagging their friends or uploading photos of them, they're giving as much away on behalf of others.
More troubling is the tremendous value of this data to governments eager to understand the social links between persons of interests: terrorists, say, or just troublemakers or dissidents. Facebook and Google, to name just two examples, routinely comply with requests for user data from governments without demanding a warrant. While these problems seem distant to most Western users—at best a concern for criminals here, at worst an unfortunate reality for protesters in Cairo—they're nonetheless the product of the business models we're not asking about. And they're really not so far off, as the US Justice Department demonstrated when it demanded that Twitter turn over private usage data on Americans associated with Wikileaks.
Always ask about the business model
Software patents and data mining are the major ecological issues confronting technologists today. The prevailing business models, far from being uninteresting, have predictable consequences that pollute the environment for innovation and endanger users. Startups that elect these models, either by design or by default, no longer have the luxury of ignoring their inherent ethical problems. We have to start designing for sustainability. We have to ask about the business model. If we don't, we're selling out the future of software and the rights of actual human beings.
Twin Peaks and the GPL
Blog post by Eben Moglen. Please email any comments on this entry to <firstname.lastname@example.org>.
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.