Intellectual Rights, not Intellectual Property
I think the phrase “intellectual property” is a misleading and dangerous phrase. Our entire economy is moving towards being a “knowledge economy”, but the term “intellectual property” misleads people into exactly the wrong understanding. Instead, use terms such as “intellectual rights”.
Not convinced? Not sure what I mean? Take a look at Intellectual Rights, not Intellectual Property.
path: /oss | Current Weblog | permanent link to this entry
U.S. Government Rules for Releasing Open Source Software (OSS)
A previous blog article announced that the January 2011 issue of the “DACS Software Tech News” (Volume 14 Number 1) is finally available. It was available in PDF form, but a few articles weren’t available in HTML form. Since that time the rest of the articles have been released as HTML (yay!).
In particular, my article “Publicly Releasing Open Source Software Developed for the U.S. Government” is finally available in HTML (it has a complicated table, which is probably why it took a while to release as HTML). That article summarizes “when the U.S. federal government or its contractors may publicly release, as open source software (OSS), software developed with government funds”. Even if you don’t work for the government or its contractors, you may still want this information, because you may want software that they’ve developed. All too often the government and its contractors don’t know what they can do (or not do).. so if you want them to release software as OSS, so you may need this information to help them determine if they can release it as OSS. But if you need the information in this article, you really need it, and I think a lot of people need it. That article is the result of a lot of work, and I thought it’d be useful to give some background about this article.
But first — why bother? This is important because the U.S. federal government and its contractors spend billions of dollars developing and maintaining software. I believe that often these could be more efficiently developed and maintained by releasing the software as open source software (OSS) and doing collaborative development. Besides, if “we the people” paid to have software developed, shouldn’t “we the people” get it? Currently, when “we the people” pay to develop software, we normally don’t get it, and that is senseless. It’s especially horrific in the research world. Often the government pays to develop software as part of research, but instead of releasing that software to everyone who paid for it (the taxpayers), it’s given exclusively to one organization. As a result, different researchers must constantly re-develop software to do further research. I think this absurd research strategy is starting to threaten U.S. competitiveness.
There are many people interested in releasing software as OSS, both in the government and in its contractors. But over the years many of them have told me that they couldn’t figure out what the legal rules were. For example, when I gave a webinar about open source software back in 2008, I was asked a lot of questions about when the government or contractors could release software as OSS. When I heard these questions, I figured that it’d be easy to answer — just read the contracts. But that’s not simple at all. A typical U.S. federal government contract is actually a huge document; just finding the relevant text is hard if you’re not an expert (you have to look for the “data rights” sections in particular). Once you find it, it’s hard to understand what the text means, even if you’re a lawyer… and most of the people who need to understand this are not lawyers.
So I began polling one lawyer after another, asking them to explain things. I then refined my summaries, and went on to others saying, “this is my understanding — do I have it right?” One thing that became clear right away is that there are a lot of sub-specialties in law. In particular, lawyers who understood the Department of Defense (DoD) contracting rules often didn’t know the rules for the rest of the federal government, and vice versa. My thanks to all the lawyers who helped clarify things, including those in CENDI! Some lawyers honestly didn’t know, even if they specialized in intellectual rights, which just goes to show how complicated this is.
I then summarized this into a set of slides, but they were still complicated. Gunnar Hellekson said that he liked the information I had gathered, but he thought my presentation was too complicated (he was right). Gunnar then tried to create a graph that simplified things, and showed it to me. I thought his graph was also too complicated, and in many cases wrong. Also, his graph made it hard to see how the different circumstances were the same and how they were different. But his work clearly showed a need to simplify things.
Gunnar and I then chatted during the August 2010 Mil-OSS conference in Arlington, VA, about how to make this simpler. The primary complication is that the copyright-related rights were hard to explain. So I decided to turn this into a big “if.. then…” table, where the conditions were on the left, and the “then” (what government and contractors are allowed to do) on the right. Gunnar gave me few more comments, and I then showed an early draft at the Mil-OSS unconference (where 30 people saw it and gave feedback on it). It was a complicated 2-page table to create, but it’s really easy to use, and that’s what matters. What I presented wasn’t “new information” — in theory this was already public information — but making information understandable is really important too.
I give this tale to show that this material, like many materials, was developed in a collaborative way, just like most open source software. I wrote the actual text itself, which is why my name is on it, but I received and responded to a lot of collaborative comments, and I thank everyone who gave me feedback. It’s not formal legal advice. But it’s impossible to follow the law or contracts if you don’t have a basic understanding of them; my hope is that it gives non-lawyers (and some lawyers) an understanding of the basics.
As I gathered this information, I was surprised to learn how often the government and/or contractors can release OSS when the government pays for software development. Often, the biggest problem with OSS release today is that the government and contractors simply don’t know what they can do. Of course, even if the government or contractors can do something, and know it, that doesn’t mean they’ll do it. Sometimes they shouldn’t release software as OSS, for example, software that gives a weapon system special capabilities over others’ should probably not be released as OSS. But often software doesn’t give an organization a special capability. Instead, all too often there are perverse incentives, encouraging government and contractors to do things that are not in society’s interest. But even if there are perverse incentives, the first step towards fixing them is to learn what the current rules are. The article helps government employees and contractors figure those out in many cases, and that’s useful too. Even if you have a special case not well covered in the article, it’s still useful to understand the “normal case”. Besides, if you want to change the system, typically you must first know where it is now.
If you read the article you’ll notice that I intentionally use the term “intellectual rights”, not “intellectual property”. I think the phrase “intellectual property” is a misleading and dangerous phrase; see my essay Intellectual Rights, not Intellectual Property for more information. (I’ll post separately about that topic.)
So anyway, please take a look at “Publicly Releasing Open Source Software Developed for the U.S. Government” or the January 2011 issue of the “DACS Software Tech News” (Volume 14 Number 1) and enjoy!
path: /oss | Current Weblog | permanent link to this entry