Elonis v. United States; a very brief summary

On Monday, the Supreme Court will hear oral arguments in Elonis v. United States (docket number 13-983). The case tests the limits of the First Amendment in the context of threats on Facebook (and other social media, of course). You can get more interesting coverage of the case on NPR, Slate, and The Atlantic (highly recommended). I thought you might enjoy a brief but more technically correct description of the issues.

Background of the Case

Anthony Elonis posted a series of graphically violent posts on his Facebook page menacing his ex-wife, his former employer, a kindergarten class, and even an FBI agent that stopped by his house. The posts are so graphic and so explicit that it’s hard to feel much sympathy for him and hard to defend his right to make the statements under the First. In fact, the case isn’t about whether he’s guilty or not — it’s just a question of how the law should have convicted him, which is a nuance you won’t see much in the major media.

What’s the Issue in Elonis v. United States

The issue the Supreme Court needs to answer is actually the kind only a lawyer could get excited about. Should it be a crime to make threatening statements of Facebook only if the person subjectively intended to intimidate someone? Or is it enough if a reasonable person would know the statement would intimidate someone (the objective test)? I don’t follow First Amendment jurisprudence very closely, so I don’t fully understand the distinction but my understanding is that it’s much easier to convict someone under the latter than the former.

Here’s what’s not at issue: whether making legitimate threats on Facebook (or anywhere else) is protected by the First Amendment; it’s not.

License Operations

contracts-case-bookYou already know this: devops is worth your time and energy. Once you get it mostly right, devops processes and technologies help you get developers’ code from their laptops to the customer faster than anyone imagined even five years ago. There are lots of reasons for it, but speaking as a developer I think one important reason is that it automates routine, error prone steps in the development process.

Can that automation (and process discipline) apply to other parts of the software development process? I think so.

My goal in writing this post is to start a conversation about how that same devops mindset, both the processes and technologies, can apply not only to moving bits from a developer’s laptop to a production machine but how the discipline can apply to licensing third-party dependencies for developers.

One developer’s perspective on the value of the devops discipline

For me, writing strongly from the developer’s side as opposed to the operations side of the dev/ops “portmanteau” (seriously from the Wikipedia entry), devops’s value is that it gives me both processes and tooling to automate away the tedious and error-prone aspects of development to make the process as low-friction as possible.

As a developer, I know it takes a little discipline and requires me to try ensure that every git push my code has solid code. But when I do, then I’m confident not only in my code but the whole code base because I know the build will break if the unit tests fail. I’m even more confident about the build when integration tests run. Moving further up the release, the devops approach leads me to believe that the nodes that support my application in production have lots of fail over and resiliency so that the code I write for the customers stays available. Put simply, even though it makes me think a little up front, devops takes a lot of friction out of the process and technology of getting quality code from my laptop to the end user.

So it would be even more awesome if the process made adding new dependencies similarly frictionless.

There’s hidden friction in adding new third party dependencies. No, really.

Wait. How could adding a new dependency be any more fluid with modern dependency management tools like Bower, Ivy, or the eponymous Maven? I’m telling you there’s some kind of friction here? Yes, yes I am. The vast majority of developers think nothing of adding a new dependency (assuming they like the technology, of course). Seriously, when’s the last time you checked a dependency’s license before including it? I’m a lawyer and I’ve never been consistent about it.

But adding each new dependency does add friction. You’re bringing in new licenses, new source code from unknown contributors, and a new legal risk every time. (Don’t get me wrong, I’m very pro-open source.)

Nobody checks licenses, yet it’s the state of the art — a very immature state. I’d argue that the in licensing process we’re following is roughly at the maturity level that our industry was at before we ran automated unit tests. Remember when you’d write the code and then just see if it got past the QA team? If you were testing before deploying, it was all ad hoc –just like we’re doing now as an industry when it comes to bringing in external dependencies.

Software developers in almost all industries (some are pretty tight about this) do one of the following:

  1. Just include the dependency and never even considered whether there could be an issue or just hope there’s not going to be an issue.
  2. Build it, and then let the lawyers review the dependencies on their lawyer schedule sometime before go-live and simply run the risk that the engineers will have to scramble if the lawyers veto something.
  3. Ask (when we remember to) the lawyers to review dependencies on a case by case basis before adding the dependency, which can really slow down development and cause developer moral issues among your most talented developers.
  4. The engineering team maintains some kind of white or black list of licenses or specific dependencies that developers can or can’t use, which needs to be manually consulted each time (unless you’re using my Maven license-check plugin!).

Since every time a developer brings in a new third-party dependency, that developer binds the company to a new licensing agreement, all these options are bad ones — especially in light of the speed, assurance, and power of modern devops approaches.

In a best case scenario, the developers will have incorporated third-party dependencies that create no licensing/intellectual property risk, which is to say you’ll get lucky. In another scenario, the company will need to scramble to audit and prove that its intellectual property (remember, your IP in software is partly a compilation of other people’s property in those third-party dependencies) is clean if the company want to sell or cash out. In a worst case scenario, the company could sued for infringement. With all the outcomes, wouldn’t it have been better if you had the stability, speed, and assurance that a devops-driven discipline promises?

How could third-party dependency licensing be easier and more reliable with devops?

I think there are a lot of ways to solve this problem using devops processes and technologies. Let’s say you have a Jenkins build/delivery pipeline with these steps:

  • continuous integration step, where every developer check in gets built and deployed, assuming the build passes all tests and the code meets other requirements (like PMD, jslint, whatever).
  • release candidate step, in which release versions of the code are cut and deployed for developers and other interested parties to vet before sending to a quality assurance environment.
  • A quality assurance/QA step in which the code is deployed by the QA team to a controlled environment for full testing
  • A staging step in which the release candidate is staged for production (maybe in a blue-green style)
  • A production/go live step, which should be self-explanatory.

To the extent that a development team makes conscious license-based choices about what third-party dependencies to incorporate, they too often do it too late in the process. Imagine that you have a solid release candidate of your application in staging when your in house counsel suddenly delivers the bad news that you can’t use an open source library because the community it came from has poor contributor licensing practices.

Now you have to scramble to replace the dependency and start the pipeline over again. In a best case scenario, you’ve only wasted time and the costs of rework. In a worst case scenario, it could cause delays significant enough to trigger breach of contract issues with your clients when you miss deployment dates.

In an ideal world, every check in would either raise flags or break the build if the developer incorporates an unknown third party artifact or one that carries a risky open source license with it (my license-check Maven plugin does this). But this introduces significant friction for developers, who you don’t necessarily want to distract with licensing issues; in a developer-centric world, we want them to focus primarily on picking code coding the best technologies they can and run with it. Let the managers and lawyers fuss about things like licensing.

One proposal for keeping third party license checks easy for developers while letting managers and lawyers making conscious choices

My proposed solution is to break the release step into two linked jobs (or new steps to the new Jenkins workflow plugin). First, there would be a job to raise flags for managers or even counsel when new dependencies are introduced. Ideally, this technology could review a number of factors — not just the license (or non-license) attached to the artifact in the Maven repository. Second, there would be some kind of human approval or checkpoint to allow the build to proceed.

I’ll readily concede that my proposal slows the development process a bit when developers are trying to cut a release and get their artifact ready to test; still I think using a bit of technology and a bit of human process right at that phase of the development cycle accomplishes goals that are hard to make play nicely:

  • letting developers focus on technology without worrying too much about licensing and contractual issues,
  • forcing product teams (and counsel) to make conscious decisions about in licensing choices, and
  • catching problematic issues as early as possible in the process so engineers have as much time as possible to mitigate.

The Your Own Devices Act (“YODA”) bill

farentholdThe Electronic Frontier Foundation picked up on this bill tonight. The idea is that you should be not encumbered with copyright restrictions when selling physical devices. Interestingly, the bill is called the Your Own Devices Act (“YODA”). What state elects geeks like this to the House? Texas???? I’m confused — why is this not coming out of California or Washington?

Here’s the text of the proposed legislation:

To amend title 17, United States Code, to provide that the first sale doctrine applies to any computer program that enables a machine or other product to operate. Be it enacted by the Senate and House of Representa- tives of the United States of America in Congress assembled,

SECTION 1. SHORT TITLE.
This Act may be cited as the ‘‘You Own Devices Act’’. SEC. 2. FIRST SALE DOCTRINE AND CERTAIN COMPUTER PROGRAMS.

(a) IN GENERAL.—Section 109 of title 17, United States Code, is amended by adding at the end the following:

(f) TRANSFER OF CERTAIN COMPUTER PROGRAMS.—
(1) IN GENERAL.—Notwithstanding section 106 or section 117, if a computer program enables any part of a machine or other product to operate, the owner of the machine or other product is entitled to transfer an authorized copy of the computer program, or the right to obtain such copy, when owner sells, leases, or otherwise transfers the machine or other product to another person. The right to transfer provided under this subsection may not be waived by any agreement.

(2) SECURITY AND ERROR CORRECTION.—Any right to receive modifications to the computer program described in paragraph (1) relating in whole or in part to security or error correction that applied to the owner of the machine or other product described in paragraph (1) shall apply to the person to whom the machine or product and the copy of the computer program are transferred.

(3) TREATMENT OF UNAUTHORIZED COPIES.—Nothing in this subsection should be construed as permitting the owner of a machine or other product to retain an unauthorized copy of the computer program described in paragraph (1) after transferring the machine or other product and the copy of the computer program to another person.

(b) EFFECTIVE DATE.—The amendment made by subsection (a) shall take effect on the date of the enactment of this Act and shall apply to transfers of computer programs occurring on or after such date.

By the way, the legislative geek in question is Blake Farenthold from the 27th District of Texas. Please tell me that the 27th encompasses the patent rocket docket of the Eastern District federal court or at least Austin.The bill is not even on OpenCongress as I write this.

Those who sue on their patents lose 75% of the time

When patent holders are in court, they only win 26% of the time according to a recent research paper by well known intellectual law professors John Allison, Mark Lemley and David Schwartz. Considering all the noise surrounding patent litigation, I think that’s a shockingly low number.

While I think this statistic is related mostly to motions in court, not actual verdicts, here are some other points from the paper you might want to consider:

  • Previously, the defendants in patent cases challenged patents based on obviousness, which is to say that they argued in court that the patent was invalid because it was obvious. These motions were expensive and had low success rates. So defendants are looking for cheaper and more effective arguments.
  • Unfortunately, it’s hard for defendants to win when they file motions asking the court declare the patent invalid for other reasons as well; however, defendants are doing very when the challenge the patent back at the PTO (through the PTAB). This might contribute a lot to the new emphasis on patent quality.
  • It turns out that defendants win most often in California, but the plaintiffs win more often in the Eastern District of Texas, Delaware, and in NYC.

This is my summary based on R. David Donoghue’s very excellent summary over at the EDTexweblog.com; he’s a patent litigator with Holland and Knight in Chicago.

Consider reading The Uneasy Case for Software Copyrights Revisited

uneasy-case-for-software-copyrightsTonight I spent some time reading Paula Samuelson’s The Uneasy Case for Software Copyrights Revisited. If you don’t know who Paula Samuelson is, you should. She’s been a hugely influential voice in the world of IP and software.

And you should know that this is a law review article (put differently, set aside some time to read it, preferably with a glass of wine or something). But if you have any interest in the history of intellectual property law and its intersection with software, Samuelson’s article will give you a great summary of the major industry and legal developments over the past forty years — where we were and how we got here.

And it’s a little meta too (so you get to feel like you’re part of the academy) in that Samuelson’s article starts with another law review article written by Stephen Breyer way back in the early 1970s (yes, that Stephen Breyer) questioning whether copyright was really a good vehicle for encouraging software developers to invest in software development. Breyer was equivocal about it, believing that it may not even be necessary considering the growth the industry experienced (even back in the 1960s).

oracle-v-googleIn Samuelson’s 2011 article, The Uneasy Case for Software Copyrights Revisited, the Berkeley Law prof reviews Breyer’s predictions and generally concludes that those predictions landed very close to their marks.

In the process, Samuelson takes you on a whirlwind ride through some of the most famous cases in software history; and despite the fact that many of those cases are ancient history in Internet time, the law is exceedingly relevant in very recent cases like Google v. Oracle.

So get yourself a glass of wine and read it!

 

Consider reading Kappos’s post on Alice v. CLS

David Kappos is the former head of the US Patent and Trademark Office. A few days ago, he wrote a SCOTUSblog post about the Supreme Court’s recent Alice Corp. v. CLS Bank, a case many were watching to see if the Supreme Court would somehow put a stop to software patents. Kappos says their silence was “deafening.”

Wisely, rather than labor through a lengthy discussion about software, the Court focused on the abstract nature of Alice Corporation’s claimed “invention,” declining to delineate a wooden rule for what constitutes unpatentable abstraction.

One thing I really love about his post is that he’s thinking of software patents in exactly the opposite way that the anti-software patent advocates think of it. That is to say, rather than ask “why should be software be patentable?” Kappos asks, “why would we exclude a whole field of ultra-valuable innovation just because of the category it’s in?” I guess that’s the perspective you get as the former head of the PTO.

Sort of unrelated, I have this crazy idea that I think the main problem with software patents is the way the claims are drafted. I got this after talking with both a director as well as a manager of software engineering at a very, very well know consumer company. Essentially they complained that the “metes and bounds” of the claims are useless to a software engineer.

As a software engineer myself, I totally agree. When I read claims (the only real important part of a patent), I can’t really tell whether the patent covers the technology I’m developing or not. So just thinking out loud, I wonder if software patent claims could be written in pseudo code. That would certainly make it easier, even if it would be harder for patent lawyers to write.

UPDATE: if you want more than just Kappos’s point of view, consider also reading the Patently-O version of SCOTUSblog’s “symposium” on Alice v. CLS.

The New New Relic ToS — how not to do it

Maybe, you got this email from New Relic tonight. I did:

Dear Michael,

New Relic has updated our Terms of Service to support additions to our product suite. You can review the new Terms of Service here.

On or before June 20th, 2014, we ask that users accept these new Terms of Service. Any user within your New Relic account may accept these new Terms of Service on behalf of your account by agreeing to the terms via a pop-up notification.

Please contact us at terms@newrelic.com if you have any questions about this update.

Thanks, New Relic

Really? That’s it? The email looks like it was written by their lawyer — or at least someone who isn’t sensitive to how people will react to these kinds of emails. Other services I’m using make changes to their terms of service. They either (a) said nothing (which isn’t good either) or (b) have sent an email that summarizes the changes and at least tries to give me a warm and fuzzy feeling about the changes.

Worse, I ran a diff on the old and the new versions of the license. They basically changed every single line of the terms of service, so I really don’t feel like parsing through it tonight. I’ll guess I’ll have to leave it to you.