US Government Making Another Attempt To Regulate Code Like It Regulates International Weapons Sales

from the a-zero-day-may-now-last-20-years dept

When code is treated like weapons, bad things happen. Governing bodies have previously treated encryption as weaponry, ensuring that only the powerful will have access to strong encryption while the general public must make do with weaker or compromised variants.

More recently, the US government went after the creator of a 3D-printed gun, claiming the very existence of printing instructions violated international arms regulations. So, it's not just the end result that's (potentially) covered under this ban (the actual weapon) but the data and coding itself. That's currently being fought in court, carrying with it some potentially disturbing implications for several Constitutional rights.

Now, it appears the conflation of physical weapons/weaponized code is possibly going to make things much, much worse. The EFF notes that the US government's adoption of recommended changes to an international arms trafficking agreement (the Wassenaar Arrangement) will likely cause very serious problems for security researchers and analysts in the future.

The BIS's version of the Wassenaar Arrangement's 2013 amendments contains none of the recommended security research exceptions and vastly expands the amount of technology subject to government control.

Specifically, the BIS proposal would add to the list of controlled technology:

Systems, equipment, components and software specially designed for the generation, operation or delivery of, or communication with, intrusion software include network penetration testing products that use intrusion software to identify vulnerabilities of computers and network-capable devices.

And:

Technology for the development of intrusion software includes proprietary research on the vulnerabilities and exploitation of computers and network-capable devices.

On its face, it appears that BIS has just proposed prohibiting the sharing of vulnerability research without a license.

As if things weren't already dangerous enough for security researchers, what with companies responding with threats and lawyers -- rather than apologies and appreciation -- when informed of security holes and the US government always resting its finger on the CFAA trigger. Violating the terms of this agreement could see researchers facing fines of up to $1 million and/or 20 years in prison.

Wassenaar was originally limited to physical items used in conventional weapons, like guns, landmines and missiles. It was amended in December 2013 to include surveillance tech, mainly in response to stories leaking out about Western companies like Gamma (FinFisher) and Hacking Team selling exploits and malware to oppressive governments, which then used these tools to track down dissidents and journalists.

The push to regulate the distribution of these tools had its heart in the right place, but the unintended consequences will keep good people from doing good things, while doing very little to prevent bad people from acquiring and deploying weaponized software.

The Wassenaar Arrangement's attempt to wrestle a mostly ethereal problem into regulatable problem was, for the most part, handled well. It defined the software it intended to control very narrowly and provided some essential exceptions:

Notably, the controls are not intended apply to software or technology that is generally available to the public, in the public domain, or part of basic scientific research.

But, even so, it still contained the potential to do more harm than good.

We have significant problems with even the narrow Wassenaar language; the definition risks sweeping up many of the common and perfectly legitimate tools used in security research.

Either interpretation (Wassenaar, BIS) is a problem. The BIS version is much worse, but both will result in a less-secure computing world, despite being implemented with an eye on doing the opposite, as Robert Graham at Errata Security points out.

[G]ood and evil products are often indistinguishable from each other. The best way to secure your stuff is for you to attack yourself.

That means things like bug bounties that encourage people to find 0-days in your software, so that you can fix them before hackers (or the NSA) exploit them. That means scanning tools that hunt for any exploitable conditions in your computers, to find those bugs before hackers do. Likewise, companies use surveillance tools on their own networks (like intrusion prevention systems) to monitor activity and find hackers.

Thus, while Wassenaar targets evil products, they inadvertently catch the bulk of defensive products in their rules as well.

And the results will disproportionately negatively affect those who need these protections the most. This is the end result of controls written with physical items (which originates from physical manufacturing plants and travel on physical means of conveyance) in mind but copied-pasted to handle "items" that can traverse the internet with no known originating point.

That's not to say export controls would have no leverage. For example, these products usually require an abnormally high degree of training and technical support that can be tracked. However, the little good export controls provide is probably outweighed by the harm -- such as preventing dissidents in the affected countries from being able to defend themselves. We know they do little good know because we watch Bashar Al Assad brandish the latest iPhone that his wife picked up in Paris. Such restrictions may stop the little people in his country getting things -- but they won't stop him.

The "open-source" exception in Wassenaar can be useful, up to a point. Researchers could post their findings to Github, as Graham points out, to ensure they're still protected. This, of course, means the Arrangement is still mostly useless, as the moment it's put into the public domain, any entity cut out of the distribution loop by this agreement can immediately make use of posted vulnerabilities and exploits. It also makes research destined to be open-sourced forbidden weaponry until the point it's actually made public. So, a laptop full of research is a prohibited weapon, while a Github post containing the same is not.

When security researchers discover 0-day, they typically write a proof-of-concept exploit, then present their findings at the next conference. That means they have unpublished code on their laptop, code that they may make public later, but which is not yet technically open-source. If they travel outside the country, they have technically violated both the letter and the spirit of the export restrictions, and can go to jail for 20 years and be forced to pay a $1 million fine.

Pro tip:

Thus, make sure you always commit your latest changes to GitHub before getting on a plane.

Statements made by the BIS aren't exactly comforting. The BIS's implementation doesn't include an open-source exception, but supposedly, this will still be taken into consideration when the US government starts throwing around fines and prison sentences. Randy Wheeler of the BIS:

"We generally agree that vulnerability research is not controlled, nor is the technology related to choosing a target or finding a target, controlled." However, she undermined her message by stating that any software that is used to help develop 0-day exploits for sale would be covered by the proposal.

Again, bad for researchers. This gives the government leeway to imply intent when prosecuting, because the allowed and the forbidden look very similar while still in their formative stages.

[T]he only difference between an academic proof of concept and a 0-day for sale is the existence of a price tag.

Even if the exploit is not on the market at the point the government steps in, it would take very little to insinuate that it would have been headed to market, if not for the speedy intervention of regulators.

There is some good news, however. The BIS is accepting comments on its proposed adoption (and partial rewrite) of the amendments to the Wassenaar Arrangement. The comment period ends on July 20, 2015, so sooner rather than later would be good if you're interested in steering the government away from doing further damage to the livelihoods of security researchers.

Filed Under: code, regulations, security research, wassenaar, weapons

Obama Administration Files Totally Clueless Argument Concerning Software Copyrights In Supreme Court Case

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.

Just as a quick refresher, copyright law clearly states 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.

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.

Filed Under: api, code, copyright, donald verrilli, method, software, supreme court
Companies: google, oracle

DRM Is The Right To Make Up Your Own Copyright Laws

from the why-anticircumvention-laws-are-a-problem dept

We've written about the problems of DRM and anti-circumvention laws since basically when we started way back in 1997. Cory Doctorow has been writing about the same stuff for just about as long (or perhaps longer). And yet, just when you think everything that can be said about this stuff has been said, Doctorow comes along and writes what may be the best column describing why DRM, combined with anti-circumvention laws, is so incredibly nefarious. Read the whole thing. It's so well done, and so important, I'm actually going to write two posts about it, because there are two separate issues that deserve highlighting.

The first concerns just how the combination of DRM and anti-circumvention is effectively a way that the content industry (and many other industries since) have been able to void the limitations on copyright law. Here's the key paragraph, which follows a discussion of the Reimerdes case, which more or less said that breaking any DRM is illegal in itself, even if the circumvention is done for legal reasons. And, because of that, we've taken copyright out of the law, and put it into the DRM:

Ever since Reimerdes, it's been clear that DRM isn't the right to prevent piracy: it's the right to make up your own copyright laws. The right to invent things that people aren't allowed to do – even though the law permits it -- and to embed these prohibitions in code that is illegal to violate. Reimerdes also showed us that DRM is the right to suppress speech: the right to stop people from uttering code or keys or other expressions if there is some chance that these utterances will interfere with your made-up copyright laws.

This is an important point summarized so perfectly that it deserves to be repeated over and over again. Because any circumvention of DRM is considered illegal, even if the purpose of the circumvention itself is legal, it basically gives not just "the copyright industries" but pretty much any industry the road map to stop people from making, say, fair use of copyrighted works. Or, worse, preventing them from tinkering with products they own. It allows them to wipe out fair use and other important user rights -- by just writing into code that it's not allowed, and even though that code is easily breakable, making that code breaking itself a form of "infringement."

In short, DRM with anti-circumvention restrictions lets industries simply route around the aspects of copyright law that are designed to protect the user's rights.

And, because of that, Doctorow wonders if there's a chance go to back and revisit the Reimerdes case, and bring back freedom to the public. As we've noted in the past, fair use is not, as some would have you believe, a "limitation and exception" to copyright, but rather a definition of the public's rights, whereby copyright is a limitation on those rights. DRM with anti-circumvention actually blocks those rights. Cory further points to another milestone case involving software, Bernstein v. US, in which it was determined that software was a form of speech, and that restricting it was a First Amendment violation. Doctorow notes that Reimerdes goes against that ruling -- and he thinks that this, plus a decade plus showing the damages done to the public's rights because of the anti-circumvention provisions of the DMCA, open up a real opportunity to revisit the issue:

No court case is ever a sure thing, but I believe that there's a good chance that a judge in 2014 might answer the DMCA/free speech question very differently. In 14 years, the case for code as expressive speech has only strengthened, and the dangers of censoring code have only become more apparent.

If I was a canny entrepreneur with a high appetite for risk -- and a reasonable war-chest for litigation – I would be thinking very seriously about how to build a technology that adds legal features to a DRM-enfeebled system (say, Itunes/Netflix/Amazon video), features that all my competitors are too cowardly to contemplate. The potential market for devices that do legal things that people want to do is titanic, and a judgment that went the right way on this would eliminate a serious existential threat to computer security, which, these days, is a synonym for security itself.

We've seen entrepreneurs take on these kinds of high risk/high reward challenges before (Aereo comes to mind, though so do ones that ended up failing in court, such as ivi and Zediva), so this seems like a very real possibility. This would be an important ruling not just to free up innovation, but to bring back the rights of the public, and to stop an encroachment that began years ago, entirely at the behest of a legacy entertainment industry who was focused on using mechanisms of control to remove the freedoms of the public, solely to protect an obsolete business model.

Filed Under: anti-circumvention, bernstein, code, copyright, cory doctorow, drm, fair use, free speech, reimerdes

How Washington DC Went From Locking Up Laws To Releasing Them In The Public Domain Within Days

from the good-move dept

In past years we've had stories about both Oregon and California claiming copyright over their own laws, which is ridiculous. If copyright is supposed to be about the incentives for creative expression, then it should have nothing to do with lawmaking at all. It's not as if the state needs a copyright incentive to write laws -- though some states have tried to argue that it needs the incentive to entice big corporate entities to print the laws. That, too, is ridiculous, as plenty of public domain info gets printed all the time -- and it really has no bearing on the simple fact that laws are public domain material, considering that the public is expected to know and obey them. While the Copyright Act makes it clear that any work done directly by federal government employees is automatically in the public domain, it's just slightly squishier when it comes to works from state governments, though there, too, it is generally believed that they fall in the public domain, as they should.

In the last week, a lot of attention was paid to the fact that Washington DC had been claiming a copyright on its laws, saying that you could not download a digital copy, and the state couldn't even release an entire copy of its own laws under a FOIA request, because of the copyright and the contract it held with outside publishing firms (initially West and, more recently, Lexis). As with the stories in Oregon and California, the person who helped drive attention to just how crazy this is was Carl Malamud, hero to everyone who believes in the importance of open access to public information. This time, he paid $803 for a copy of the code, scanned it all, and sent copies on USB drives in the shape of famous American Presidents to a bunch of folks.

Normally, at this point in the story, we hear about the local government hemming and hawing or even issuing vague threats. But not in the case of DC. Over the course of a few days, it appears that Washington DC's tech savvy General Counsel V. David Zvenyach quickly moved to deal with the problem. Part of the issue was that the only digital copy of the code that they had was the one given to them by West, and it contained a variety of extraneous information that was West's IP, including West logos on each section of the law (representing many thousands of copies). Zvenyach had Joshua Tauberer come by and spend a day removing every bit of West IP from the document and quickly releasing a downloadable copy of the DC Code with a CC0 public domain license.

That's pretty awesome. To go from having the code locked up for no good reason to a public domain downloadable release in days is pretty cool. Kudos to Malamud, Zvenyach and Tauberer for their part in this, as well as Tom MacWright, who first sought the copy of the code and brought this issue to the attention of Malamud and others.

Of course, it's not a perfect solution. As MacWright notes in his post about this release:

There are a few things that this isn’t: it isn’t the official copy of the code, and lawyers would be ill-advised to cite it alone. It isn’t up-to-date – the council is fast-moving and this is just a snapshot. In time we’ll fix these problems too.

Yes, even though it's being released directly by the DC Council on their website, it's designated as an "unofficial copy" and it's only up-to-date through last year. However, hopefully others will get it up to date, and eventually the DC Council will be able to list an "official" copy as well. Oh, and for those living in or around DC, MacWright is also planning a hackathon around this new code, to see what awesome and useful tools people can build on top of it.

Filed Under: code, copyright, laws, public domain, washington dc
Companies: lexis, west

Should People Learn To Code? Yes � If They Are Judges Ruling On Cases Involving Software

from the you-can't-fool-me dept

Recently Techdirt wrote about the heated debate on the subject of whether people should learn to code. We pointed out that some knowledge of that subject could be particularly useful in helping people understand why copyrighting APIs or patenting software is just crazy -- whatever the abstract legal arguments, in practice both make programming much, much harder.

An obvious situation where such practical knowledge could be crucially important is in court cases dealing with software. Rather neatly, the long-running court case between Oracle and Google, where the former is accusing the latter's Android of infringing on its code in various ways, has thrown up a perfect example of this.

It arose in an exchange between Judge Alsup and Oracle's main lawyer, the high-profile David Boies, best known for representing the US Justice Department in the United States v. Microsoft case. Boies claimed that the fact that the jury had decided Google's "rangeCheck" code had copied Oracle's implementation of the same function was evidence that Google was trying to save time. The argument of Boies was that Google consciously copied those few lines from Oracle in order to accelerate development -- and thus to start making money faster through daily activations of phones running its Android operating system.

But Judge Alsup was having none of it:

I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There's no way you could say that was speeding them along to the marketplace. You're one of the best lawyers in America, how could you even make that kind of argument?

This is a perfect example of a judge being able to draw on his personal experience of coding to dismiss what a clever lawyer probably thought was a clever argument.

Contrast this with another judge, talking this time about software patents, as recently reported on Techdirt:

Judge Michel seemed unaware of the depth of the software industry's dissatisfaction with the patent system. He suggested the patent system's critics were relatively marginal figures not representative of the views of the broader technology industry. And he didn't seem to understand the dynamics of the patent arms race currently affecting the software industry.

"If software is less dependent on patents, fine then. Let software use patents less as they choose," Michel said. "If other industries are terribly dependent on patents, then let's not wreck the system just because software people are unhappy."

No one who has tried to code in any depth could dismiss the problems caused by software patents so glibly -- it would be hard, for example, to imagine Judge Alsup saying this.

Learning to code certainly isn't a panacea, nor is it relevant for everyone. But for those professionals who must make important decisions about software -- judges, for example -- a basic programming literacy is indispensable. As it is, the tech industry must count itself lucky that the Oracle vs. Google case seems to have ended up in front of one of the few judges qualified to decide it.

Follow me @glynmoody on Twitter or identi.ca, and on Google+

Filed Under: android, code, david boies
Companies: google, oracle

Can You Understand How Technology Works Without Understanding Code?

from the yes-and-no dept

There's an interesting debate that's broken out in the tech world, kicked off by tech/coding superstar Jeff Atwood arguing that people shouldn't learn to code. He was mostly responding to an announcement by NYC Mayor Mike Bloomberg that he wanted to learn how to code: Jeff found this to be a misuse of Bloomberg's skills:

A noble gesture to garner the NYC tech community vote, for sure, but if the mayor of New York City actually needs to sling JavaScript code to do his job, something is deeply, horribly, terribly wrong with politics in the state of New York.

He goes on to explain why he thinks this is a bad idea, even as he's a fan of programming himself. I won't go through his full list of points. You can read them on his site yourself, but it does feel like a lot of his complaint isn't so much about people learning to code, but the idea that people learning to code will mean more people coding for a living. For example, there are these two points:

• It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that's true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can't even code, so please pardon my skepticism of the sentiment that "everyone can learn to code".
  
  
• It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.

While I understand the points he's raising in both of these cases, it feels like he's taking the "everyone should learn to code" argument way beyond what is generally meant in that discussion. I don't think anyone is saying that people should learn to code for a living. Lots of people learn math, but don't become mathemeticians or even use math in their daily jobs -- but it doesn't mean it hurts to understand math.

In fact, I think that Jeff recognizes this. He notes that a better focus would be:

The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.

And that's something I think everyone agrees on. It's just that some folks are suggesting that the way to better understand computers and the internet is if they have some familiarity with code. And thus, I actually think that Jeff and those arguing against him, may actually be in agreement. It's just that some people think that understanding code is a good way to understand computers and the internet.

One of the better responses to Jeff points out that learning to code is different than preparing for a job as a coder. As that post notes:

Learning to program is not the same thing as training for a programming career. Learning new skills opens up new perceptual avenues and cognitive spaces. I'm learning to sew right now, not because the world needs another tailor but because I want to be able to recognize quality in clothing and create pieces that I can't find. Novice coders feel the same way about their digital goods and should be encouraged to continue. Learn to program.

Perhaps where the major difference comes in is that Jeff believes that learning to code is not a stage in understanding computers and the internet, and he compares it to plumbing:

I can also recognize plumbing problems when I see them without any particular training in the area.

However, as esmoov writes in his response, Jeff may have just internalized what he has learned about plumbing:

He may not have had formal training (the professional/personal equivocation again) but he has been trained by an unruly digestive movement, a low water tank and the horrible things 18-22 year-olds do to and around toilets. My dad showed me how to fix a broken chain in the tank. Before I learned that, toilets had three states: working, clogged and broken. After learning to fix the chain, I added a new state to which my toilet-perception could resolve: loose or broken chain. Again, the ability to take in, cut up and categorize the world is a product of the things learned.

Indeed. I don't think that learning the basics of programming solves all internet/technology illiteracy, but it certainly helps people to understand the lay of the land better. It's not necessary, but it can help them better understand the problems and potential solutions when they come up -- even if they don't intend on programming themselves. It can lead them to recognize, for example, how bizarre it might seem to copyright an API or patent software itself. That's a concept that's a little harder to comprehend if you don't understand programming at all. That isn't to say that understanding programming is completely necessary, but it certainly can help in getting people to a point of digital literacy.

Filed Under: code, jeff atwood, mike bloomberg, nyc

EU Court Of Justice Says Software Functionality Is Not Subject To Copyright

from the good-ruling dept

We've been following the legal fight between SAS and World Programming Limited (WPL) for quite some time. If you don't recall, WPL essentially recreated some functionality of SAS's offering, not by copying the software itself or the source code, but basically by reading SAS's manuals about what its software did. The UK's High Court said this did not infringe, and the case got kicked up to the European Court of Justice (which has been pretty good on copyright issues lately). In the fall, the EU Advocates General recommended that the court make clear that software functionality is not subject to copyright, and it appears that's exactly what the court has now done.

In a relatively short ruling, the court points out that, while software itself may be covered by copyright, "the ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright." Basically, the EUCJ properly recognized the difference between protecting the idea (not copyrightable) and the expression (copyrightable). The court points out that actual code can still be covered, but the features generated out of that code is a different story:

As the Advocate General states in point 57 of his Opinion, to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.

Also important in the discussion is whether or not the software maker could use a license agreement to effectively prohibit this. This is a question that courts have been dealing with for a while: can you effectively remove exceptions to copyright -- or can you effectively expand the power of copyright -- via an overly inclusive license agreement. Here, thankfully, the court rejects that idea:

Consequently, the owner of the copyright in a computer program may not prevent, by relying on the licensing agreement, the person who has obtained that licence from determining the ideas and principles which underlie all the elements of that program in the case where that person carries out acts which that licence permits him to perform and the acts of loading and running necessary for the use of the computer program, and on condition that that person does not infringe the exclusive rights of the owner in that program.

[....]

It must therefore be held that the copyright in a computer program cannot be infringed where, as in the present case, the lawful acquirer of the licence did not have access to the source code of the computer program to which that licence relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program.

It's always nice to see courts getting copyright rulings right (or, at least, mostly right). It's been much rarer in the US, but it seems like the EUCJ has really been thinking a lot more carefully about copyright law lately.

Filed Under: code, eucj, european union, software copyright, uk
Companies: sas, world programming limited

French Tweeters Get Around Ban On Tweeting Election Results Using WWII-Era Codes

from the gouda-cheese dept

Last week, we wrote about how French Twitter users were being warned not to use social media tools like Twitter to reveal local polling or election results before all the French voting booths closed in the Presidential election. We pointed out how silly this was, and it appears that folks in France used a simple mechanism to get around the rules: using WWII-era coding techniques to share information in the same manner that the French Resistance used:

As a result, incumbent Nicolas Sarkozy became either Tokaji wine which, like his father, comes from Hungary, or Rolex because of his perceived "bling-bling" lifestyle.

His Socialist opponent Francois Hollande was either Gouda cheese (from Holland) or a soft, sweet "Flanby" caramel desert -- an old and unforgiving nickname for the portly frontrunner.

Far-right candidate Marine Le Pen was associated with the names of totalitarian regimes or rodents and Communist Party-backed Jean-Luc Melenchon was either a rotten tomato or something linked to the former Soviet Union.

From there, it sounds like people just had fun with it, figuring out all sorts of ways to obliquely refer to the different candidates and how well they were doing without directly referring to any of them. Once again, the internet views censorship as an obstacle, and routes around it, through a rather creative form of "encryption."

Filed Under: code, election, france, social media, world war two

Judge Admits She Was Wrong To Order Playstation Jailbreaker To 'Retrieve' Code From Elsewhere

from the good-for-her dept

A few weeks ago, we noted the problem of judges who don't understand technology in highlighting how the judge in the case concerning the Sony PS3 jailbreak had ordered that George Hotz (Geohot) "retrieve" the jailbreak code that had been distributed. As we pointed out, you can't retrieve code that out's there on the internet. It's not a physical good. The comments on our original article had some claims from some of our usual critics, claiming that our statement that the judge had asked for the impossible was "FUD" and not accurate, and even accused me of intentionally misleading readers here.

Well, it appears that the judge has reconsidered, and actually agrees with me and apologized for the original order:

The judge also backed off on an order that Hotz "retrieve" the code from anybody who he may have forwarded it to.

"It's information. It can't be retrieved. It's just not practical," Illston said. "What would they do, Xerox it and mail it back?"

Illston said she changed her mind because she was not clearly aware of the details in her earlier order.

"This kind of got away from me and I apologize for that," she said from the bench.

That said, the article does still highlight how she has allowed Sony to comb through Hotz's computers looking for any information "that relates to the hacking of the PlayStation." Hotz's lawyers had protested this, and the judge said that it's standard to search through the entire contents of someone's computer to find things like child porn, to which his lawyer noted that "we're certainly not dealing with child pornography," but the judge didn't bite. Despite concerns from Hotz's lawyer, the judge told them "That's the breaks."

Filed Under: code, jailbreaking, ps3, retrieving

Plurk Overplaying Hand After Microsoft Code Copying; Meanwhile Status.net Says 'Take Our Code, Please'

from the take-the-publicity-and-go-with-it dept

Lots of people got a good ironic laugh from the news that Microsoft, which has repeatedly complained about "piracy" in China, got caught blatantly copying code from a small startup named Plurk. Microsoft blamed a vendor and shut down the service. Plurk, for its part, got a ton of free publicity, and apparently it doesn't want to give it up. It's sent out a statement to lots of media folks (and us) with absolutely nothing of substance, but which says that the company is still considering legal action, while going on and on about how its just a small company that can't even afford sales people or a marketing person to write this email. And yet, it thinks it wants to distract itself with a lawsuit against Microsoft? If it can't afford sales people, those lawyers might be a bit costly. Yes, Microsoft copied your code. Time to use that to your advantage, and whining about the legal action you might take doesn't get anyone else to actually care about your product.

Meanwhile, another provider of similar software (though open sourced), Status.net took a smarter approach. Blaise points out that Status.net put up a blog post telling Microsoft to go right ahead and take its code. After all, it's open source (and they have a Chinese translation already). That's what you're supposed to do.

Filed Under: china, code, copying
Companies: microsoft, plurk, status.net