CDT believes it would be inappropriate to create redundant penalties for accessing car software. Sec. 302 of the draft vehicle safety bill is unnecessary insofar as it duplicates the Computer Fraud and Abuse Act (CFAA) and the Digital Millennium Copyright Act (DMCA). Although tampering with car software can pose safety issues, this is not unique and does not require a new regulation – the computers and software already covered under the CFAA and DMCA include everything from web servers to sensitive critical infrastructure.

The draft bill forbids “access without authorization” to software – but so does Sec. 1030(a)(2)(C) of the CFAA. If the purpose of forbidding access to the vehicle’s software is to prevent unauthorized modifications, this too is already prohibited under Sec. 1030(a)(5) of the CFAA. The CFAA carries both civil and criminal liability for violations, and penalties are almost universally viewed as disproportionately harsh.

If vehicle software is protected by an access control, as is often the case, then Sec. 1201 of the DMCA already forbids circumventing the software access controls without authorization. Sec. 1201 poses major problems for independent auto repairs, diagnostics, and cybersecurity research that require access to software, and numerous groups – including CDT – have repeatedly called on the Copyright Office to create exemptions for these purposes on behalf of consumers. The draft vehicle safety bill contains no such exemptions. In fact, the draft vehicle safety bill is actually stricter than Sec. 1201 insofar as it applies to software even if there is no access control.

And that's not all that's problematic with the bill. Marcey Wheeler notes that the program would basically allow carmakers to hide what they're doing with the information they collect on you, merely by ponying up $1 million to the government. The bill is, of course, sneaky, in that it pretends to demand automakers reveal what they're doing with your info, but then slips in a "cap" of $1 million for automakers that refuse to do so. In other words, car companies can just pay $1 million (pocket change) and not have to reveal anything.

There's also some bizarre stuff having to do with cybersecurity, where the bill would let automakers set their own standards, and then keep them secret. Here's Geiger again:

The Council will decide on weighty matters, including best practices for cybersecurity, fixing security flaws, coordinating vulnerability disclosure with security researchers, and even automobile design. [See pgs. 29-30.] Vehicle manufacturers may develop policies based on these best practices, yet the draft would explicitly forbid these policies from being disclosed to the public. [See pg. 31.] While companies might be wise to avoid disclosing sensitive technical details, it would be unnecessarily prescriptive and inconsistent with modern practice for the government to forbid companies from public disclosure of their own policies.

And Wheeler:

Upton’s [bill] would let the industry to establish a standard, than permit manufacturers to submit their plans that would fulfill “some or all” standards. Once they submitted those plans they would disappear — they couldn’t be FOIAed, and couldn’t be sued by FTC if they violated those terms.

The Committee’s discussion draft includes an important focus on cybersecurity, privacy and technology innovations, but the current proposals may have the opposite of their intended effect. By providing regulated entities majority representation on committees to establish appropriate practices and standards, then enshrining those practices as de facto regulations, the proposals could seriously undermine NHTSA’s efforts to ensure safety. Ultimately, the public expects NHTSA, not industry, to set safety standards.

Neither does the FTC, raising concerns about how the bill would basically exempt carmakers from FTC investigations and actions should they violate user privacy. The FTC also (thankfully!) raises similar concerns as CDT to the parts that would block security research:

Section 302 of the discussion draft would prohibit unauthorized access to an electronic control unit, critical system, or other system containing driving data. We support the goal of deterring criminals from accessing vehicle data. Security researchers have, however, uncovered security vulnerabilities in connected cars by accessing such systems. Responsible researchers often contact companies to inform them of these vulnerabilities so that the companies can voluntarily make their cars safer. By prohibiting such access even for research purposes, this provision would likely disincentivize such research, to the detriment of consumers’ privacy, security, and safety.

The FTC is also concerned about that "cybersecurity" council thing, pointing out that it would be dominated by the carmakers, as well as the fact that the setup would inevitably lead to very slow reactions to real cybersecurity issues:

The discussion draft requires the Council to meet annually to review the best practices, but leaves it up to the Council to adopt additional best practices “as necessary” in subsequent years, which could mean that risks are not addressed in a timely fashion. The discussion draft allows, but does not require, manufacturers to submit updated plans if they choose to modify their plans.

And then, of course, there's this:

The proposed safe harbor is so broad that it would immunize manufacturers from liability even as to deceptive statements made by manufacturers relating to the best practices that they implement and maintain. For example, false claims on a manufacturer’s website about its use of firewalls, encryption, or other specific security features would not be actionable if these subjects were also covered by the best practices.

Yeah, that seems like a concern.

So who could possibly like this bill? Why, the automakers of course. The Alliance of Automobile Manufacturers -- represented by former RIAA boss Mitch Bainwol, of all people -- really likes these proposals, because why wouldn't it? The only real complaint it seems to have is that the cybersecurity council wouldn't have enough time to implement a plan and is apparently trying to push out the timeline.

Meanwhile, the key sponsor of the bill is Fred Upton who is (you probably guessed...) from Michigan, home of the American auto industry. It also probably won't surprise you to discover that the automotive industry has been a big financial supporter of his campaigns for Congress, or that Ford Motor Company has been the second largest contributor to his campaigns over his career (behind the National Association of Broadcasters). This is all, of course, part of the process of how Congress works, but it does still seem fairly sketchy when that leads to a bill that certainly looks like a big gift to the automakers, and which would almost certainly destroy security research into automotive computer systems, while similarly leaving all cybersecurity decisions up to the automakers themselves (and removing the FTC and the NHTSA from key parts of the oversight process).

from the unconfrontable-witnesses dept

Defendant Martell Chubbs currently faces murder charges for a 1977 cold case in which the only evidence against him is a DNA match by a proprietary computer program. Chubbs, who ran a small home-repair business at the time of his arrest, asked to inspect the software’s source code in order to challenge the accuracy of its results. Chubbs sought to determine whether the code properly implements established scientific procedures for DNA matching and if it operates the way its manufacturer claims. But the manufacturer argued that the defense attorney might steal or duplicate the code and cause the company to lose money. The court denied Chubbs’ request, leaving him free to examine the state’s expert witness but not the tool that the witness relied on.

That's a starkly mercenary stance to take. The "trade secret privilege" invoked here basically states that the company's potential loss of income outweighs a person's potential loss of freedom. It also asks for a level of trust it hasn't earned: that the software is as close to infallible as it needs to be. Cross-examination is next to useless when the software itself can't be examined.

Worse, this closed-off software operates in a field where nearly every previous form of "indisputable" evidence has proven to be severely flawed.

Studies have disputed the scientific validity of pattern matching in bite marks, arson, hair and fiber, shaken baby syndrome diagnoses, ballistics, dog-scent lineups, blood spatter evidence, and fingerprint matching. Massachusetts is struggling to handle the fallout from a crime laboratory technician’s forgery of results that tainted evidence in tens of thousands of criminal cases. And the Innocence Project reports that bad forensic science contributed to the wrongful convictions of 47 percent of exonerees.

Everything tied to securing convictions seems to suffer from pervasive flaws compounded by confirmation bias. For four decades, the DOJ presented hair analysis as an unique identifier on par with fingerprints or DNA when it wasn't. A 2014 Inspector General's report found the FBI still hadn't gotten around to correcting forensic lab issues it had pointed out nearly 20 years earlier. This contributed to two decades of "experts" providing testimony that greatly overstated the results of hair analysis. All of this happened in the FBI's closed system, a place outsiders aren't allowed to examine firsthand.

That's the IRL version. The software version is just as suspect. Computers aren't infallible and the people running them definitely aren't. If the software cannot be inspected, the statements of expert witnesses should be considered highly dubious. After all, most expert witnesses representing the government have a vested interest in portraying forensic evidence as bulletproof. Without access to forensic software code, no one will ever be able to prove them wrong.

If a piece of software has the ability to deprive a member of the public of their freedom, its code should be open for inspection by the defense. "Trade secrets" should not take precedence over the public's right to defend themselves in court. Even in the highly unlikely event that Chubb's defense team would have copied the code and destroyed the company's future profits, it would still have the ability to seek redress through the court system. After all, that's the line the government uses when it argues for expanded "good faith exceptions" or warrantless searches and seizures: "Hey, if we screw up, you can always sue."

The judicial system is a remedy for wrongs, both criminal and civil. What it shouldn't be is a protective haven where ridiculous assertions like those made here are used to prevent an accused person from learning more about the evidence being used to convict them.

from the is-that-domestic-appliance-lying-to-you? dept

There have been a number of stories on Techdirt recently about the increasing use of software in cars, and the issues that this raises. For example, back in April, Mike wrote about GM asserting that while you may own the car, the company still owns the software that runs it. You might expect GM to come out against allowing you to modify that software, but very recently we reported that it had received support from a surprising quarter: the Environmental Protection Agency (EPA). The EPA had a particular concern that engine control software might be tampered with, causing cars to breach emissions regulations. We've just found out that the EPA was right to worry about this, but not for the reason it mentioned, as the The New York Times explains:

The Environmental Protection Agency issued [the German car manufacturer Volkswagen] a notice of violation and accused the company of breaking the law by installing software known as a "defeat device" in 4-cylinder Volkswagen and Audi vehicles from model years 2009-15. The device is programmed to detect when the car is undergoing official emissions testing, and to only turn on full emissions control systems during that testing. Those controls are turned off during normal driving situations, when the vehicles pollute far more heavily than reported by the manufacturer, the E.P.A. said.

So, just as the EPA feared, software that regulates the emissions control system was indeed tampered with, though not by reckless users, but by the cars' manufacturer, Volkswagen (VW), which must now recall nearly half a million cars, and faces the prospect of some pretty big fines -- Reuters speaks of "up to $18 billion". The EPA's Notice Of Violation (pdf) spells out the details of what it calls the software "switch":

The "switch" senses whether the vehicle is being tested or not based on various inputs including the position of the steering wheel, vehicle speed, the duration of the engine's operation, and barometric pressure. These inputs precisely track the parameters of the federal test procedure used for emission testing for EPA certification purposes. During EPA emission testing, the vehicles' ECM [electronic control module] ran software which produced compliant emission results under an ECM calibration that VW referred to as the "dyno calibration" (referring to the equipment used in emission testing, called a dynamometer). At all other times during normal vehicle operation, the "switch" was activated and the vehicle ECM software ran a separate "road calibration" which reduced the effectiveness of the emission control system (specifically the selective catalytic reduction or the lean NOx [nitrous oxides] trap.) As a result, emission of NOx increased by a factor of 10 to 40 times above the EPA compliant levels, depending on the type of drive cycle (e.g. city, highway).

That trick was discovered by the West Virginia University's Center for Alternative Fuels, Engines & Emissions when studying the VW vehicles. Initially, VW claimed that the increased emissions were due to "technical issues" and "unexpected in-use conditions." But further tests confirmed the problem, and eventually VW admitted "it had designed and installed a defeat device in these vehicles in the form of a sophisticated software algorithm that detected when a vehicle was undergoing emissions testing."

It's significant that the trick was discovered through extensive mechanical testing. Assuming some form of DRM was employed, it would not have been possible to spot the cheating algorithm of the emissions control code because it would have been illegal to circumvent the software protection. This emphasizes once more the folly of allowing the DMCA to apply to such systems, where problems could be found much earlier by inspecting the software, rather than waiting for them to emerge in use, possibly years later.

The revelation about VW's behavior once more concerns code in cars, but there is a much larger issue here. As software starts to appear routinely in an ever-wider range of everyday objects, so the possibility arises for them to exhibit different behaviors in different situations. Thanks to programming, these objects no longer have a single, fixed set of features, but are malleable, which makes checking their conformance to legal standards much more problematic. When the VW story broke last week, Zeynep Tufekci, assistant professor at the University of North Carolina, tweeted that this was an example of "The Internet of cheating things." I'm not sure whether she coined that phrase -- I'd not seen it before – but it encapsulates neatly a key feature of the world we are beginning to enter.

from the welcome-to-the-land-of-trolls dept

The patent office for the first time made a clear interpretation of the Patents (Amendment) Act, 2002 to mean that if a software has novelty, is inventive or tangible, and has proper technical effect or industrial application, it can be patented. The guidelines serve as a reference for officers in granting patents.

India's patent law has not changed, which means that the following exclusions from patentability, found in The Patents (Amendment) Act 2002, are still relevant:

k) a mathematical or business method or a computer programme per se or algorithms;

(l) a literary, dramatic, musical or artistic work or any other aesthetic creation whatsoever including cinematographic works and television productions;

(m) a mere scheme or rule or method of performing mental act or method
of playing game;

(n) a presentation of information;

These are very similar to the exclusions listed in Article 52 of the European Patent Convention (EPC), which governs patent law in Europe. And where the EPC uses the phrase "as such" when it comes to computer programs, the India exclusions contain the equivalent phrase "computer programme per se". As Techdirt readers know, the inclusion of "as such" as a qualifier to the exclusion of computer programs from patentability has opened up a huge loophole through which clever lawyers have driven many thousands of software patents. The fear -- quite justified -- is that exactly the same will happen in India because of the new guidelines' interpretation of what that "per se" phrase means (pdf):

The JPC [Joint Parliamentary Committee] report holds that the computer programmes as such are not intended to be granted patent. It uses the phrase "... certain other things, ancillary thereto or developed thereon.....". The term "ancillary" indicates something essential to give effect to the main subject. In respect of CRIs [Computer Related Inventions], the term "ancillary thereto" would mean the "things" which are essential to give effect to the computer programme. The clause "developed thereon" in the JPC report may be understood as any improvement or technical advancement achieved by such development. Therefore, if a computer programme is not claimed by "in itself" rather it has been claimed in such manner so as to establish industrial applicability of the invention and fulfills all other criterion of patentability, the patent should not be denied. In such a scenario, the claims in question shall have to be considered taking in to account whole of the claims.

Just in case that isn't crystal clear, India's Patent Office helpfully offers some concrete examples of things that it regards as definitely patentable, as well as things that definitely aren't patentable. See if you can guess which category the following example belongs to:

A method for estimating a length of time required to download one or more application programs on a wireless device over wireless network, said method comprising operations of:

the wireless device exchanging one or more data files with server, said data files including at least information representing a size of the one or more application programs available for downloading onto the wireless device;

during the exchanging, at least one of the server and wireless device measuring one or more data transfer rates for the exchanging operation;

receiving user input of one or more application programs to download;

at least one of the server and wireless device:

utilizing the one or more measured data transfer rates and the size of the selected one or more application programs to estimate a length of time required to download the one or more application programs onto the wireless device and the wireless
device providing an output of the estimated time.

So the invention consists of sending a test file or two, measuring the average data transfer rate, and then using that to estimate the download time for another file of known size. As you will no doubt have guessed, this is regarded as patentable under the new guidelines.

from the fundamentally-not-understanding-that-apis-are-not-software dept

Copyright expert and professor Pam Samuelson, one of the most respected scholars of copyright law, has published a short paper explaining what she calls the "three fundamental flaws in CAFC's Oracle v. Google decision." As you may recall, that ruling was a complete disaster, overturning a lower court decision that noted that application programming interfaces (APIs) are not copyrightable, because Section 102 of the Copyright Act pretty clearly says that:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

But CAFC got super confused, and basically ignored 102 while misunderstanding what an API actually is. After the White House itself got confused, the Supreme Court refused to hear the case. This means that the CAFC ruling stays in place, despite it being at odds with lots of other courts. And this might not be a huge problem, since most copyright cases won't go to CAFC. The only reason the Oracle case went to CAFC was because it started out as a patent case, and CAFC gets all patent appeals, even if the appeal has nothing to do with patents. Except... of course, now there's incentive to toss in a bogus patent complaint along with a questionable "interface copyright" complaint just to get it into CAFC's jurisdiction.

Samuelson's paper is a good read (and we'll get to it), but I'd actually argue it's a bit too tame, and leaves out the really fundamental flaw in the CAFC ruling and in the White House brief: these non-programmers don't realize that an API is not software. Almost all of the mistakes stem from this simple fact. They assume that an API is software. And this is highlighted very clearly in the CAFC ruling where they quote Pam Samuelson out of context and then completely miss what she's actually saying. Here's from that ruling:

Google argues that “[a]fter Sega, developers
could no longer hope to protect [software] interfaces by
copyright . . . Sega signaled that the only reliable means
for protecting the functional requirements for achieving
interoperability was by patenting them.” ...
(quoting Pamela Samuelson, Are Patents on Interfaces
Impeding Interoperability...). And, Google relies heavily on articles written by
Professor Pamela Samuelson, who has argued that “it
would be best for a commission of computer program
experts to draft a new form of intellectual property law for
machine-readable programs.” Pamela Samuelson,
CONTU Revisited: The Case Against Copyright Protection
for Computer Programs in Machine-Readable Form.... Professor Samuelson has more
recently argued that “Altai and Sega contributed to the
eventual shift away from claims of copyright in program
interfaces and toward reliance on patent protection.
Patent protection also became more plausible and attractive
as the courts became more receptive to software
patents.”...

Although Google, and the authority on which it relies,
seem to suggest that software is or should be entitled to
protection only under patent law—not copyright law—
several commentators have recently argued the exact
opposite. See Technology Quarterly, Stalking
Trolls, ECONOMIST, Mar. 8, 2014, http://www.economist.
com/news/technology-quarterly/21598321-intellectualproperty-
after-being-blamed-stymying-innovationamerica-
vague (“[M]any innovators have argued that the
electronics and software industries would flourish if
companies trying to bring new technology (software
innovations included) to market did not have to worry
about being sued for infringing thousands of absurd
patents at every turn. A perfectly adequate means of
protecting and rewarding software developers for their
ingenuity has existed for over 300 years. It is called
copyright.”); Timothy B. Lee, Will the Supreme Court save
us from software patents?, WASH. POST, Feb. 26, 2014, 1:13
PM, http://www.washingtonpost.com/blogs/the-switch/wp/
2014/02/26/will-the-supreme-court-save-us-from-softwarepatents/
(“If you write a book or a song, you can get copyright
protection for it. If you invent a new pill or a better
mousetrap, you can get a patent on it. But for the last
two decades, software has had the distinction of being
potentially eligible for both copyright and patent protection.
Critics say that’s a mistake. They argue that the
complex and expensive patent system is a terrible fit for
the fast-moving software industry. And they argue that
patent protection is unnecessary because software innovators
already have copyright protection available.”).

But this is just wrong. If you actually look at Samuelson's quotes, she's talking about interfacesnot software. Notice in every quote she is not actually talking about the software itself, but "interfaces," "functional requirements" and "program interfaces." The absolute worst is the first quote, where Samuelson writes "interfaces" and CAFC inserts a "[software]" to imply that it's the same thing. It's not. The two paragraphs are not actually at odds. It is entirely reasonable to argue that interfaces shouldn't be protected by copyright (thanks to Section 102) and that software should not be patentable.

It only looks like they're disagreeing if you're confused and you think that an API is the same thing as the software itself. But that's like saying a recipe is the same as a meal or that a dictionary is the same as a novel that uses those words. It's not the same thing.

So while Samuelson's new paper is great, I still feel like she holds back on that key issue, which is so just blatantly wrong, and seems to underline why non-technical people (including the judges in this case) got so confused. Of course software is copyrightable. The argument is over whether or not an API necessary for interoperability is copyrightable. And, as Samuelson's paper notes, it had been widely accepted prior to the CAFC ruling that the answer is no because they're "procedures, processes, systems and methods" under Section 102.

A second flaw was the CAFC’s overbroad view of the extent to which the “structure, sequence
and organization” (SSO) of computer programs are protectable by copyright law. During the
1980s, some courts regarded program SSO as having a broad scope of protection under copyright
law. But in the last two and a half decades, courts and commentators have recognized that the
SSO concept is too imprecise and misleading to be useful in software copyright cases. The SSO
concept does not help courts make appropriate distinctions between protectable and
unprotectable structural elements of programs. Procedures, processes, systems, and methods of
operation, almost by definition, contribute to the SSO of programs that embody them. However,
this does not make those elements protectable by copyright. The design of many program
structures, including APIs, is inherently functional and aimed at achieving technical goals of
efficiency. This disqualifies them as protectable expression under U.S. law.

Anyway, the rest of the paper is a good read, and hopefully it means that eventually this issue will get back to the Supreme Court -- and one hopes, at that time, someone can at least get through to them that an API is not software.

from the urls-we-dig-up dept

Maybe you've seen some ads featuring a former California governor fighting a younger, computer-generated version of himself lately. The Terminator franchise is almost guaranteed to be rebooted every few years, just as the real life technology that could create strong artificial intelligence is getting closer and closer. Hopefully, a $10 million donation from Elon Musk to the Future of Life Institute will help delay Judgment Day, but progress in artificial intelligence can't be bargained with, it can't feel pain or mercy, and it will stop at absolutely nothing....

The appeals court ruling, by the Court of Appeals for the Federal Circuit (CAFC) (famous for getting patent cases wrong over and over and over again) didn't just get things wrong, it got things laughably wrong, confusing the difference between APIs and software throughout, and quoting people entirely out of context (including taking things so out of context that it often pitted people on the same side against each other, solely because CAFC misread what they were saying). The case was appealed to the Supreme Court, and we were shocked and dismayed to see the Obama administration further reinforce the errors of the CAFC ruling in telling the Supreme Court not to hear the case. The filing by Solicitor General Donald Verrilli repeatedly confused software with APIs and insisted that there was really no difference between the two. That's just wrong. It's not a matter of debate. It's just wrong.

One would have hoped that with a ton of computer science experts explaining to the Supreme Court how CAFC got things wrong, the Supreme Court might recognize that the Obama administration was confused, but for whatever reason, the Supreme Court has declined to hear the case.

This is dangerous. The world of software and innovation relies on the kind of interoperability and the ability to connect via things like APIs. As we've noted, this is like claiming you can copyright an entire language, rather than the creative works written in those languages. Making APIs proprietary and locked up puts a ton of innovation at risk.

As for Google and Oracle directly, this probably doesn't matter much. They're two giant companies, certainly. And now that the case returns to the lower court, they'll either settle or fight it out over fair use (and hopefully win on that front as well). But saying fair use allows this is very, very different than saying there's no copyright on the API. And for smaller companies this will have a tremendous ripple effect, and will undoubtedly lead to a slower pace of innovation. The kinds of touchstones that people build on will no longer happen. Under this ruling, it basically overrules previous rulings that said pull down menus were not copyrightable. But with this ruling in place, it's hard to see how that's still true. Expect to see a bunch of ridiculous lawsuits over minor copying of functions like that.

While this case may eventually be resolved on fair use grounds (or through settlement), there are still two potential areas of hope. First, the "precedential" power of this ruling is actually somewhat limited. CAFC precedents are more or less meaningless in this context. CAFC handles all patent cases, and the only reason it heard this case was because it started as a patent case, even though those issues were resolved much earlier. So, while CAFC has made this particular ruling, it does not mean that the 9th Circuit, where this case was actually heard has to abide by it. The appeals court for the 9th circuit could rule otherwise (though it is somewhat famous for its own nutty copyright rulings).

Perhaps if this issue returns to another appeals court, and that court gets it right, the issue will return to the Supreme Court with a clear circuit split. And by then, we can hope, the people staffing the Solicitor's General office will finally include at least one person who understands the difference between code and APIs.

The really stunning thing in all of this is just how factually wrong many of the arguments were, and that the CAFC and Obama Administration bought them. These weren't questions of interpretation or opinion. They just flat out got the facts wrong, based on an astounding level of ignorance about a rather basic concept of an API not being software. Just because they both look like "code" does not make them both code. It would be nice if the people actually making these decisions weren't so easily fooled by their own ignorance.

from the what-happens-behind-closed-doors... dept

Since last summer, we've written a couple of times about TISA, the "Trade In Services Agreement" which is another secretive trade agreement involving a ton of countries, which will likely have an impact on the internet. There have been a few leaks of the various negotiating documents, and recently, WikiLeaks released a bunch more, including the e-commerce annex (though, it appears that a similar such copy leaked a few weeks ago as well).

Frankly, there's plenty of stuff in the TISA agreement that I think would actually be good for the internet, including many of the provisions I would normally cheer on if they were being presented and debated openly. We can discuss the merits of various proposals, but only if the discussion is held openly. Unfortunately, like with the TPP and TTIP agreements, all of the details are secret other than through leaks -- and as with some of those other agreements, the parties have agreed to keep all "negotiating" documents totally secret until five years after TISA is agreed upon.

So, even as I think there are ideas within TISA that actually are desirable, I can't see any reason why the people negotiating it can't make those arguments and positions publicly, and allow the public in on the debate. The fact that they're being kept secret, even when they're good ideas, makes me question whether or not they're truly good ideas, or what sorts of stupid poison pills have been slipped in.

But one clause, in particular, found in the leaked version is immensely troubling, opening up the possibility of effectively banning many governments from requiring open source software for certain activities. That's Article 6 in the latest leaked draft, which is text proposed by Japan:

Article 6: ... Transfer or Access to Source Code
1. No Party may require the transfer of, or access to, source code of software owned by a
person of another Party, as a condition of providing services related to such software in its
territory.

2. For purposes of this Article, software subject to paragraph 1 is limited to mass-market
software, and does not include software used for critical infrastructure.

Now, this is nowhere near complete -- it is "bracketed text" which is still being negotiated, and Colombia already opposes the text. Also, some may argue that the second bullet point, which says it only applies to "mass market" software and not "critical infrastructure" software solves some of these issues. Finally, some might argue that this is reasonable if looked at from the standpoint of a commercial provider of proprietary software, who doesn't want to have to cough up its source code to a government just to win a grant.

But, if that language stays, it seems likely that any government that ratifies the agreement could not then do something like mandate governments use open source office products. And that should be a choice those governments can make, if they feel that open source software is worth promoting and provides better security, reliability and/or cost effectiveness when compared to proprietary software. That seems tremendously problematic, unless you're Microsoft.

from the oh-gosh-no dept

The Obama administration made a really dangerous and ignorant argument to the Supreme Court yesterday, which could have an insanely damaging impact on innovation -- and it appears to be because Solicitor General Donald Verrilli (yes, the MPAA's old top lawyer) is absolutely clueless about some rather basic concepts concerning programming. That the government would file such an ignorant brief with the Supreme Court is profoundly embarrassing. It makes such basic technological and legal errors that it may be the epitome of government malfeasance in a legal issue.

We've written a few times about the important copyright question at the heart of the Oracle v. Google case (which started as a side show to the rest of the case): are software APIs covered by copyright. What's kind of amazing is that the way you think about this issue seems to turn on a simple question: do you actually understand how programming and software work or not? If you don't understand, then you think it's obvious that APIs are covered by copyright. If you do understand, you recognize that APIs are more or less a recipe -- instructions on how to connect -- and thus you recognize how incredibly stupid it would be to claim that's covered by copyright. Just as stupid as claiming that the layout of a program's pulldown menus can be covered by copyright.

The judge in the district court, William Alsup, actually learned to code Java to help him better understand the issues. And then wrote such a detailed ruling on the issue that it seemed obvious that he was writing it for the judges who'd be handling the appeal, rather than for the parties in the case.

Unfortunately, the judges at the federal circuit court of appeals (CAFC) didn't pay attention and made a completely ignorant ruling, in which it became so clear that they didn't understand the difference between software and an API that it was almost embarrassing. The decision quoted people in ways that were completely out of context, where the CAFC judges clearly misunderstood what was being said. This ruling would fundamentally kill off important forms of innovation if allowed to stand. It would be a disaster.

So, of course, the case has been appealed to the Supreme Court -- and that's where Donald Verrilli steps in. The Supreme Court asked the Solicitor General if the US had an opinion on the case. This apparently led to a healthy debate within the Obama administration over the position it should take. I know that there are people within the administration who understand these issues. Hell, Ed Felten has just been appointed deputy CTO for the administration and he, of all people, recognizes the difference between an API and software (in fact, he signed onto an amicus brief saying as much). He also (more than most) understands the copyright side of things and the potential impact of getting this wrong.

But instead of listening to the people who actually understand the technology, it appears that Verrilli sided with the copyright maximilist/technology-ignorant faction in the government. The final brief argues that the Supreme Court should stay out, that the CAFC got it right, and that it's impossible to distinguish between APIs and software. Because Donald Verrilli has absolutely no clue how software works. That's a fundamentally ridiculous argument, and argued out of near total ignorance of the basic facts of this case.

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

An API is, quite simply, a "system or method of operation." It's not copyrightable. That should be the end of the story. And yet, everyone who doesn't get this keeps arguing that an API is the same thing as software itself. This is just flat out wrong. But Verrilli makes the same mistake:

Despite the inherently functional character of all computer code, the Copyright Act makes clear that such code can be copyrightable. Nothing about the declaring code at issue here materially distinguishes it from other computer code, and petitioner has identified no genuine conflict of authority concerning Section 102(b)’s applicability to circumstances like these. Although petitioner has raised important concerns about the effects that enforcing respondent’s copy-right could have on software development, those concerns are better addressed through petitioner’s fair-use defense, which will be considered on remand.

No, no, no and no. Everything about the declaring code distinguishes it from other computer code if you understand the first thing about computer programming. One is computer code. One explains an interface for communicating with computer code. They're fundamentally different things.

It's like arguing that there is fundamentally no difference between a recipe and a fully cooked meal.

And yet, that's exactly what Verrilli and the Obama administration are now arguing to the Supreme Court. Because they don't understand even the most fundamental things about code, and assume that because an API looks like computer code (because whoever wrote this brief is ignorant of coding), they're the same thing.

Later in the filing, Verrilli, again, seems to assume that an API is the same thing as "computer code."

If the Copyright Act contained no explicit references to computer code, one might reasonably conclude that such code is not protectable “expression” at all. Computer code differs in a fundamental way from many traditional means of literary expression. A book or newspaper article is meant to be read and comprehended by a human being as a description of an idea or story. Although many copyrightable written documents explain how practical tasks should be per-formed, there is typically a clear distinction between the written explanation and the actual performance of the task. Computer code, by contrast, is both expression and the actual means by which a computer is induced to perform the desired function. It therefore would not be unnatural to describe computer code as a “method of operation” or “system.” Nor would it be unreasonable to conclude that, as between a book on bicycle-building and the actual construction of a bicycle, computer code is more analogous to the latter.

Again, the entire basis of this paragraph is arguing something no one is arguing against. Everyone agrees that computer code is copyrightable. What we're arguing is that APIs are not computer code -- because they're not. But because Verrilli and others can't seem to wrap their head around this, they just lump it all together. And the argument, based on this faulty premise continues:

The Copyright Act as a whole makes clear, however, that the functional character of computer code cannot be sufficient to bring it within Section 102(b). If that were so, no computer code would qualify for copyright protection;

This makes no sense. At all. Of course, computer code is copyrightable. But an API that is just a method of how to interact with that code is not computer code.

yet the Copyright Act unequivocally recognizes that a person can own a copyright in computer code.... Rather, the uncopyrightable “method of operation” or “system” or “process” is the underlying computer function triggered by the written code—for example, an algorithm that the computer executes to sort a data set. The code itself, however, is eligible for copyright protection.

Again, yes, of course the code is copyrightable. But the code is not the API. It's incredible how fundamentally the Solicitor General doesn't seem to grasp this simple concept.

When the filing eventually tries to get around to the difference between an API and software code itself, it basically just throws up its hands, saying "well, it looks like code, so it's all the same to us."

That distinction does not withstand scrutiny. Both declaring code and implementing code ultimately perform the same practical function: They instruct a computer to work. The declaring code tells the computer to call up the implementing code, and the implementing code tells the computer to perform an operation, such as executing a sorting algorithm. Both are necessary components of a Java or Android method. And neither the declaring code nor the implementing code is what a programmer physically types when invoking a method.

Yes, and the recipe and the ingredients are both "necessary components" of a meal, but that doesn't make them the same thing. Hell, to be more specific, the recipe and the description of how to prepare a meal are both necessary and they look fairly similar. But in copyright law the recipe is not copyrightable, while the description may be. That's the same thing with software code and APIs. But because the folks who wrote this brief are either ignorant -- or ridiculously chose to ignore those who do understand these things -- we get this absolutely embarrassing brief from the US government. It's a travesty.

Furthermore, Verrilli seems to be suggesting that the important Lotus v. Borland case which found that the layout of a computer program's menu structure were not covered by copyright, was decided incorrectly!

The precise rationale of Lotus is not clear. Parts of the opinion purport to rest on the proposition that Section 102(b) can foreclose copyright protection for original expression.... But other parts of the opinion seem to apply a principle analo-gous to the merger doctrine, to the effect that, be-cause there was only one menu hierarchy that would allow users to operate the spreadsheet program in substantially the same way, the menu hierarchy (un-like the underlying code) could not acquire copyright protection.... Whatever the rationale of Lotus, however, the decision cannot reasonably be read to treat Sec-tion 102(b) as applicable to computer code itself, a form of expression that the Copyright Act clearly protects and that the First Circuit took pains to distinguish.

Also very wrong, is Verrilli's repeated claim that these are issues that can be handled by a fair use analysis, rather than the question of whether or not API's are copyrightable at all:

Indeed, many of petitioner’s specific contentions will be relevant to its fair-use defense on remand. For example, although it would be anomalous to use Section 102(b) to distinguish between different segments of a single work of authorship..., Section 107(3) instructs courts to consider “the amount and substantiality of the portion [of a copyrighted work] used in relation to the copyrighted work as a whole” in adjudicating a fair-use defense. That petitioner copied only respondent’s declaring code while writing its own implementing code should therefore be a relevant factor in the lower courts’ fair-use analysis.

But this, too, is wrong. There's a big difference in saying "this is not copyrightable" and "this can be used thanks to fair use." Fair use is (unfortunately) limited and dependent on a number of factors. Something that is not covered by copyright is open to all comers. The difference is really important and the Solicitor General doesn't even care at all.

Unfortunately, the Supreme Court often follows the Solicitor General's advice on cases (though, not always). If it does so here, it would be a travesty and truly dangerous for innovation. As a ton of top computer experts (including now deputy CTO Felten) noted in their own brief (put together by the EFF), the lack of copyright in APIs has been a key element in defining the way the digital world works. To find otherwise would be a massive hit to basic innovation. As that brief explained

Today, open, uncopyrightable APIs continue to spur the creation and adoption of new technologies. When programmers can freely reimplement or reverse engineer an API without obtaining a costly license or risking a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to develop. Moreover, compatible APIs help enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. Without the compatibility enabled by the open nature of APIs, consumers could be forced to leave their data and programs behind when they switch to a new service.

The freedom to reimplement APIs also helps developers rescue “orphan” software or data—systems that are no longer supported by their creators. When a company stops supporting a computer platform or service, the ability to freely reimplement APIs protects the communities that rely on that software. Government entities and non-profits are especially susceptible to the orphan programs problem as they often cannot afford to upgrade and are left using legacy technologies for years or decades.

It would be truly ridiculous that, just because the MPAA's former top lawyer is so ignorant that he can't comprehend the difference between an API and actual software, that the Supreme Court would allow such a terrible ruling as CAFC's to stand.

from the urls-we-dig-up dept

A common complaint for closed source software-as-a-service is that it can just go away almost any minute -- leaving users abandoned without any immediate backup solutions. There might be alternatives to switch to, but the alternatives are not exactly the same, and this is why people complained so much when [GeoCities, Google Reader, FormsCentral, etc.] shut down. Users get accustomed to certain features that may be unique. Some companies are better at handling service shutdowns than others, but in the end, it's still really annoying.