incommunicado

An episode of the Software Freedom Law Show.

Show Notes Segment 0 (00:36)

• Aaron, Bradley, and Karen consider Aaron's status as a “special host”. Bradley wondered if that meant Aaron hosted a parasite. (Aaron subsequently got sick two days after recording, and is now playing the role of a biological “special host”.)
• Bradley joked that copyright never expires in the USA due to retroactive extensions enacted by Congress. Aaron noted the Sony Bono 1998 Copyright Extension Act was the most recent act to do this. (05:47, 06:28)
• Public domain dedications are relatively easy in the USA, but moral rights issues in European jurisdictions make public domain dedications difficult. (17:19)
• The Berne Convention respects the issue of public domain, insofar as something definitely in the public domain in one country doesn't fall under copyright restrictions in other countries, but doesn't do much more than that regarding public domain. (17:30)
• Creative Commons wrote CC0 to attempt to harmonize public domain dedication around the world. (18:53)
• Bradley pointed out that the “WTFPL” license FAQ points out that it exists in part because of difficulties in putting things in the public domain in some jurisdictions. (25:36)
• Karen looked up the word merchantability in Black's Law Dictionary. (30:07)

Segment 1 (29:52)

• Bradley was apparently wrong, saleable is a word, and some few online dictionaries say sailable is a word (30:30)
• Aaron mentioned the Typography for Lawyers website, which has a good section on using all-caps text. (33:27)
• Bradley encouraged use of \textsc{} in LaTeX instead of writing in all caps, but laments that lawyers he's talked to about it can't be convinced. (34:30)
• Black's Law Dictionary says public domain is the rule; intellectual property is the exception. Bradley lamented that he wishes that were actually true. (35:17)

Send feedback and comments on the podcast to <oggcast@softwarefreedom.org>. You can keep in touch with the SFLC on our IRC channel, #sflc on irc.freenode.net, and by following SFLC on identi.ca.

If your not-for-profit FLOSS project needs legal assistance, write to <help@softwarefreedom.org>. If your project needs an organizational home, write to <conservancy@softwarefreedom.org>.

The Software Freedom Law Show is produced by Dan Lynch of half baked media. Theme music written and performed by Mike Tarantino with Charlie Paxson on drums.

The content of this podcast and the accompanying show notes are licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.

An upcoming event related to the SFLC .

GPLv3: Better Copyleft for Developers and Users

Where: Linux Collaboration Summit, Hotel Kabuki, San Francisco, CA, USA

When: Thursday 15 April 2010 at 13:00

Who: Bradley M. Kuhn

Bradley M. Kuhn will deliver a talk entitled GPLv3: Better Copyleft for Developers and Users at the Fourth Annual Linux Collaboration Summit at the Hotel Kabuki on Thursday 15 April 2010 at 13:00.

An upcoming event related to the SFLC .

With Software as a Service, Is Only the Network Luddite Free?

Where: Texas Linux Fest, Monarch Event Center, Austin, TX, USA

When: Saturday 10 April 2010

Who: Bradley M. Kuhn

Bradley M. Kuhn will deliver a talk entitled With Software as a Service, Is Only the Network Luddite Free? at the 2010 Texas Linux Fest at the Monarch Event Center in Austin, TX on Saturday 10 April 2010.

An upcoming event related to the SFLC .

Update from SFLC

Where: LibrePlanet2010, Harvard Science Center, Cambridge, MA

When:

Who: Karen M. Sandler

An upcoming event related to the SFLC .

Software Freedom In Network Services

Where: LibrePlanet 2010, Harvard Science Center, Cambridge, MA, USA

When: Sunday 21 March 2010, 10:30-11:30

Who: Bradley M. Kuhn

Bradley M. Kuhn will hold a panel with Benjamin “Mako” Hill and Matt Lee regarding the issue of Software Freedom for Network services during the Sunday session at Libre Planet 2010 at the Harvard Science Center.

An upcoming event related to the SFLC .

Open Source Business Conference

Where: The Palace Hotel, San Francisco, CA

When:

Who: Karen M. Sandler

Karen Sandler presents "Understanding and Resolving Conflicts Between Free and Open Source Software Licenses"

Blog post by James Vasile. Please email any comments on this entry to <vasile@softwarefreedom.org>.

Earlier this week, the Office of Foreign Assets Control announced the relaxation of rules prohibiting export of software to Iran and Sudan. The new exemptions build on a recent easing of some rules governing exporting telecommunications technology to Cuba. These moves are surely an attempt to capitalize on the Iranian election demonstrations last summer that some called the "Twitter Revolution". They are also a sign that the Obama Administration is carrying out its plans to make internet freedom a pillar of US diplomacy.

I hope the revised OFAC rules are the beginning of a broad and nuanced re-examination of US technology export policy. They are certainly good news for Free Software developers who are currently prohibited from distributing their software in embargoed countries.

Generally speaking, US companies have been prohibited from trading with Iran and Sudan, despite some exemptions for humanitarian and medical reasons. To my knowledge, those exemptions have never been applied to Free Software. Against that backdrop of general prohibition, OFAC promulgated new exceptions allowing the exportation of "certain services and software incident to the exchange of personal communications over the Internet." As examples, OFAC lists "instant messaging, chat and e-mail, social networking, sharing of photos and movies, web browsing and blogging."

That list, however, is not exhaustive. The exemption is broad and applies to a wide range of technology. I asked an OFAC representative how broadly to interpret "incident to," and he confirmed that the exemption includes such software as web servers, content management systems or operating systems on which one could run an IM client. If those are incident to personal communication, presumably much other Free Software is too.

Though the decision to loosen export regulations is a step in the right direction, it falls far short of what the Free Software world really needs: permission to publicly distribute Free Software everywhere on the planet without jumping through invisible and innumerable hoops. First, the new rules are limited to Iran and Sudan. Other embargoed countries are still off limits. Second, while "incident to personal communication" applies to a lot of software, it does not describe everything, and its limits are unclear. Third, the exception is limited to software that is publicly available at no cost to the user.

This last point deserves some extra attention. If you charge for Free Software, the exemption does not apply. Also, other export controls are still in effect. This is true no matter how you structure it. A download fee to recoup the cost of distribution would be a problem. A paid service agreement to support the software would be a problem. Accepting donations from embargoed countries could be problematic. In other words, if your project gives away software but raises money by accepting money for ancillary goods or services, those ancillary charges can run afoul of the embargo rules.

Other caveats exist (especially regarding software that does encryption), and this post isn't meant to be legal advice on how to comply. My objective is to shed light on a decision that could signal the beginning of a gradual shift in US technology policy and a shift in the Free Software development landscape. If your project is trying to comply with export regulation, you should seek legal advice.

Export regulation is a patchwork quilt of mystifying rules. Most projects are wholly unaware that putting their code on the web might put them at risk of violating export laws they've never heard of. Those that try to comply face many difficulties. It's heartening to see inter-agency cooperation aimed at simplifying the legal environment for Free Software developers. By broadening exemptions to include certain communication technologies, the government acknowledges that internet access is a fundamental human right. These are welcome signs for the SFLC and the free software community overall. I hope the Commerce Department joins in and extends the personal communication technology exemption to include trade with Cuba and Syria as well.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to <bkuhn@softwarefreedom.org>.

[Crossposted from Bradley M. Kuhn's personal blog].

Boy, do I hate it when a FLOSS project is given a hard time unfairly. I was this morning greeted with news from many places that OpenSSL, one of the most common FLOSS software libraries used for cryptography, was somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded a copy of the academic paper that was cited as the sole source for the story and read it. As I feared, OpenSSL was getting some bad press unfairly. One must really read this academic computer science article in the context it was written; most commenting about the paper probably did not.

First of all, I don't claim to be an expert on cryptography, and I think my knowledge level to opine on this subject remains limited to a little blog post like this and nothing more. Between college and graduate school, I worked as a system administrator focusing on network security. While a computer science graduate student, I did take two cryptography courses, two theory of computation courses, and one class on complexity theory0. So, when compared to the general population I probably am an expert, but compared to people who actually work in cryptography regularly, I'm clearly a novice. However, I suspect many who have hitherto opined about this academic article to declare this severe vulnerability have even less knowledge than I do on the subject.

This article, of course, wasn't written for novices like me, and certainly not for the general public nor the technology press. It was written by and for professional researchers who spend much time each week reading dozens of these academic papers, a task I haven't done since graduate school. Indeed, the paper is written in a style I know well; my “welcome to CS graduate school” seminar in 1997 covered the format well.

The first thing you have to note about such papers is that informed readers generally ignore the parts that a newbie is most likely focus on: the Abstract, Introduction and Conclusion sections. These sections are promotional materials; they are equivalent to a sales brochure selling you on how important and groundbreaking the research is. Some research is groundbreaking, of course, but most is an incremental step forward toward understanding some theoretical concept, or some report about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections that focus on the negative implications for OpenSSL. In the rest of the paper, OpenSSL is merely the software component of the experiment equipment. They likely could have used GNU TLS or any other implementation of RSA taken from a book on cryptography1. But this fact is not even the primary reason that this article isn't really that big of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce. You have to cause very subtle faults in computation at specific times. As I understand it, they had to assemble a specialized hardware copy of a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the specially-constructed faulty hardware must be collected and operated upon by a parallel processing computing environment over the course of many hours. If it turns out all the needed data was gathered, the output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention. Very specific faults have to occur, and they can't occur such that any other parts of the computation (such as, say, the normal running of the operating system) are interrupted or corrupted. This is somewhat straightforward to get done in a lab environment, but accomplishing it in a production situation would be impractical and improbable. It would also usually require physical access to the hardware holding the private key. Such physical access would, of course, probably give you the private key anyway by simply copying it off the hard drive or out of RAM!

This is interesting research, and it does suggest some changes that might be useful. For example, if it doesn't slow a system down too much, the integrity of RSA signatures should be verified, on a closely controlled proxy unit with a separate CPU, before sending out to a wider audience. But even that would be a process only for the most paranoid. If faults are occurring on production hardware enough to generate the bad computations this cracking process relies on, likely something else will go wrong on the hardware too and it will be declared generally unusable for production before an interloper could gather enough data to crack the key. Thus, another useful change to make based on this finding is to disable and discard RSA keys that were in use on production hardware that went faulty.

Finally, I think this article does completely convince me that I would never want to run any RSA computations on a system where the CPU was emulated. Causing faults in an emulated CPU would only require changes to the emulation software, and could be done with careful precision to detect when an RSA-related computation was happening, and only give the faulty result on those occasions. I've never heard of anyone running production cryptography on an emulated CPU, since it would be too slow, and virtualization technologies like Xen, KVM, and QEMU all pass-through CPU instructions directly to hardware (for speed reasons) when the virtualized guest matches the hardware architecture of the host.

The point, however, is that proper description of the dangers of a “security vulnerability” requires more than a single bit field. Some security vulnerabilities are much worse than others. This one is substantially closer to the “oh, that's cute” end of the spectrum, not the “ZOMG, everyone's going to experience identity theft tomorrow” side.

0Many casual users don't realize that cryptography — the stuff that secures your networked data from unwanted viewers — isn't about math problems that are unsolvable. In fact, it's often based on math problems that are trivially solvable, but take a very long time to solve. This is why algorithmic complexity questions are central to the question of cryptographic security.

1 I'm oversimplifying a bit here. A key factor in the paper appears to be the linear time algorithm used to compute cryptographic digital signatures, and the fact that the signatures aren't verified for integrity before being deployed. I suspect, though, that just about any RSA system is going to do this. (Although I do usually test the integrity of my GnuPG signatures before sending them out, I do this as a user by hand).

An episode of the Software Freedom Law Show.

Show Notes Segment 0 (00:33)

• The Chaos Computer Club was founded in Berlin on September 12, 1981. (03:30)
• Bradley mentioned the Heinrich Böll's short stories, Dr. Murke's Collected Silence. (06:45)
• Bradley mentioned the Samuel Beckett's play, Breath. (08:42)
• Karen spoke about trademarks at Scale 8x. (11:30)

Segment 1 (14:06)

• Karen mentioned the slides of her talk would be on the SFLC website. (14:20)
• Trademark rights originate when you use a certain name and/or logo. (15:30)
• You have to use the mark “in commerce” (though for a short period of time you can file for registration with “intent to use”); to have the mark; however, the rules and lingo seem a bit “old fashioned” when focused on online publication and distribution of free software. (16:30)
• The most obvious benefit of registering a trademark is that registration is clear notice that the mark is being used, and creates a presumption of notice and ownership. (18:15)
• There are other Karen Sandlers, such as a Romance novelist and HIV researcher and doctor. (19:49)
• There is a Brad Kuhn (not Bradley) race car driver and a Bradley Kuhn killed in Arizona in 2008. (20:17)
• Bradley mentioned an issue of Sony's Restaurant in Baltimore in 1987, which was Bradley's first introduction to trademark law. (22:23)
• The Madrid Protocol is a treaty that helps people who have registered trademarks in one country to easily obtain registrations in other countries. (27:05)
• Trademarks are indefinite. A trademark can be kept as long as you maintain it and continue to use it. Copyrights, by contrast, are supposed to be limited by how long they can be held (but in reality don't seem to be, due to copyright extension lobby). (37:15)
• The GNU name actually carefully avoid trademark infringement of Unix by having the name say explicitly: GNU's Not Unix. (39:50)
• The classic example of a genericized trademark is “xerox” becoming a verb to mean “to photocopy”. (41:43)
• Bradley used a Used a vi implementation called vile on MS-DOS before he had a Unix-like system on his computer. (45:10)
• Karen recommends that Free Software projects adopt explicit trademark policies that explicitly permit all the types of uses that the project wants to permit. (47:13)
• Trademark implies some sort of quality control; “naked licensing” refers to giving a license without monitoring quality. (48:50)
• Trademark policy statements can be good tools to help handle “naked licensing” issues. (52:10)
• Bradley briefly mentioned the Iceweasel rename of Firefox in Debian. (52:40)

Send feedback and comments on the podcast to <oggcast@softwarefreedom.org>. You can keep in touch with the SFLC on our IRC channel, #sflc on irc.freenode.net, and by following SFLC on identi.ca.

If your not-for-profit FLOSS project needs legal assistance, write to <help@softwarefreedom.org>. If your project needs an organizational home, write to <conservancy@softwarefreedom.org>.

The Software Freedom Law Show is produced by Dan Lynch of half baked media. Theme music written and performed by Mike Tarantino with Charlie Paxson on drums.

The content of this podcast and the accompanying show notes are licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.