Blog post by Aaron Williamson. Please email any comments on this entry to <aaronw@softwarefreedom.org>.

Google recently disclosed a draft cross-license under which patents related to the VP8 video compression format—held by Google, MPEG-LA, and several other companies—would be licensed to the general public. SFLC reviewed these terms and considered some criticisms that have arisen in the free software community. Our opinion expressed here is ours alone, and does not necessarily reflect the position of any client of SFLC.¹

Compatibility with Open Source and Free Software Definitions

It has been suggested that the proposed license is incompatible with Open Source Initiative's Open Source Definition and the Free Software Foundation's Free Software Definition, the documents that define which terms are appropriate in free and open source copyright licenses. But the VP8 license is not a FOSS license,² and these definitions' criteria apply only indirectly to third-party patent licenses.

Critics focus on two provisions in particular: §2, which requires would-be licensees to explicitly accept the license terms, and §3, which limits the license's "field of use" to implementations of VP8. Both would be unacceptable in a FOSS copyright license on software, but in the context of this particular free-standing third-party patent license, neither provision interferes with FOSS licensing or the freedoms it protects.

Should the developers of a FOSS VP8 implementation accept this license, they would not be required to pass on any restrictions limiting users' rights to copy, modify, and redistribute free programs. Users would be neither required to accept the patent license nor restricted from adding new capabilities to the software. They would have the same rights as they would if the developers had never accepted the patent license: those granted by the software's FOSS license.

If this patent license interfered with the freedoms guaranteed to users by FOSS licenses, it would be incompatible with the OSD and FSD. Because the patent license does not restrict those freedoms, but rather affords some new, limited protections to users and developers within the field of use, it improves on the current situation. Without this license, the patent holders would be in a position to threaten those users and developers as well as others.

The acceptance requirement: an unacceptable burden?

A related objection to the acceptance requirement is that it is a burden for projects with no collective legal identity, because each developer must accept the license personally to be covered (as must each downstream licensee). This inconvenience is largely mitigated by §4 of the draft license, which provides a full release from past infringement upon acceptance. This means that a developer of a VP8 implementation can accept the license at any time—including after being threatened or even sued by a VP8 licensor—and acquire a retroactive release. This feature makes the license functionally identical to a covenant not to sue.

There is some valid concern that the VP8 licensors could subsequently change or withdraw the offer of retroactive release. The license could be improved by a promise not to do so. But the law doesn't reward manipulation; if the retroactive release appears in the final, published license, the VP8 licensors may well be estopped from subsequently seeking to enjoin developers or distributors who have relied on it in good faith.

Conclusion

SFLC, like the Free Software Foundation, believes that software standing alone should not be patentable subject matter. We join skeptics of the VP8 license and the broader FOSS community in rejecting software patents in all forms, and we will continue to oppose them. But until software patents no longer threaten FOSS, we will look for every opportunity to preserve community development from their destructive effects. The VP8 cross-license provides such an opportunity, in an area of particularly active patenting. It's not perfect, but no other modern web video format provides nearly the same degree of protection for FOSS implementations.

Update (5/30/2013): the cross license involves patents from several companies other than Google, MPEG-LA, and their affiliates.

Blog post by Aaron Williamson. Please email any comments on this entry to <aaronw@softwarefreedom.org>.

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

1. 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.
2. 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:

1. 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...
2. 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."
3. 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:
   1. notify the sender of the original notification that you will put the content back up in 10 business days; and then...
   2. 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.

Conclusion

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.

Blog post by Aaron Williamson. Please email any comments on this entry to <aaronw@softwarefreedom.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: [1] converting a floating-point number memory register representation to a floating-point register representation; [2] rounding the converted floating-point number; [3] performing an arithmetic computation upon said rounded number resulting in a new floating-point value; [4] converting the resulting new floating-point register value to a floating-point memory register representation.

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.

Blog post by Aaron Williamson. Please email any comments on this entry to <aaronw@softwarefreedom.org>.

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.

Blog post by Eben Moglen. Please email any comments on this entry to <eben@softwarefreedom.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.