I previously did a posting on the US government’s successful invocation of sovereign immunity in a claim alleging copyright infringement and an anti-circumvention claim under the DMCA. The opinion in that case came from the Court of Federal Claims, a trial-level court. The decision has now been affirmed by the Federal Circuit, Blueport Company, LLC v. United States, 2008 WL 2854127 (CAFC, July 25, 2008)(No. 2007-5140), available here.
Congress abrogated the federal government’s sovereign immunity for copyright infringement in 28 USC 1498(c), but a DMCA anti-circumvention violation is not an infringement action; instead, chapter 12 of title 17 is a sui generis right, like semiconductor chips, bootlegging, and vessel boat hull protection. There is no express abrogation of sovereign immunity for DMCA violations, and thus the US government is free to – and appears quite happy to – engage in activity, which if done by individuals or companies, would be illegal, perhaps even criminal. The hypocrisy in the US government’s conduct is breathtaking given USTR’s vigorous efforts to peddle the DMCA internationally. Where are the IIPA, BSA, and other “pro-IP” groups on this scandalous treatment of creators? Will they now press for an amendment to 1498(b) to include violations of the DMCA?
The facts in the Blueport case fully support the sense of outrage we should all have over this situation. I will simply copy them verbatim from the CAFC’s opinion so there is no slanting of them. After reading them, ask yourself whether we should ever believe again government officials who talk about the importance of intellectual property:
BACKGROUND
In this case, Blueport claims that the Government-specifically the U.S. Air Force-infringed Blueport's copyright on a software program known as “the AUMD program.” The AUMD program was written by Air Force Technical Sergeant Mark Davenport. On March 6, 2000, Davenport assigned all his rights in the AUMD program to Blueport.
When Davenport wrote the AUMD program, he was employed as a manager of the Air Force Manpower Data System (“MDS”), a database containing manpower profiles for each unit in the Air Force. In his capacity as an MDS Manager, Davenport updated the MDS with new data and provided reports from the MDS to Air Force personnel upon request. Davenport was also a member of the Air Force's Manpower User Group, a group of manpower personnel from each of the Air Force's major commands who provided guidance on the use of the MDS. Based on his experience with the MDS, Davenport concluded that the software the Air Force used to run the MDS was inefficient and began seeking ways to redesign the software program. Davenport initially requested training in computer programming from the Air Force, but his request was denied. Undeterred, Davenport learned the computer programming skills necessary to write the AUMD program on his own time and with his own resources. Davenport then wrote the source code for the AUMD program while at home on his personal computer. Although he wrote the program solely at his home and at his own initiative, Davenport's intent in writing the program was that other Air Force manpower personnel would use it.
In June 1998, Davenport shared an early version of the program with a fellow coworker, and both tested the program on the MDS at work during regular business hours. Based on the results of this testing, Davenport made changes to the source code of the AUMD program on his home computer. Davenport did not at that time, or at any time thereafter, bring the AUMD program's source code to work or copy it onto Air Force computers.
After these initial tests, Davenport began sharing copies of the AUMD program with other colleagues. At first, Davenport shared the AUMD program with colleagues by giving them a computer disk containing the program or by personally installing the program on their computers. Later, Davenport posted the AUMD program on an Air Force web page so that Air Force manpower personnel could download it directly. As the program became popular within the Air Force manpower community, Davenport's superiors asked him to train additional personnel in its use. During this time, he continued to modify the program based on feedback he received and, as a result, improved its functionality and eliminated programming errors. At some point, Davenport added an automatic expiration date to each new version of the AUMD program so that users were required to download the newest version when the older one expired.
In September 1998, Davenport gave a presentation to senior Air Force manpower officers at an annual conference and, according to one of Davenport's superiors, “absolutely sold his audience” on the AUMD program. Davenport's performance report deemed him the “go to troubleshooter for [the] entire [Air Force] manpower community ... [and] the most knowledgeable database manager in [the] career field.” The performance report concluded with a recommendation to promote Davenport immediately.
Despite Davenport's success in creating the AUMD program and his willingness to share it, the Air Force eventually decided it was becoming too dependent on Davenport for access to the program. Accordingly, Davenport's superiors asked him to turn over the source code for the program, which Davenport had always kept on his home computer. When he refused to turn over the source code, his superiors threatened him with a demotion and a pay cut, and excluded him from the Manpower User Group's advisory authority.
Davenport then assigned all his rights in the AUMD program to Blueport. Subsequently, Blueport attempted to negotiate a license agreement with the Air Force. However, the Air Force refused Blueport's offer and solicited other contractors to recreate the AUMD program. The Air Force ultimately contracted with Science Applications International Corporation (“SAIC”). At the request of the Air Force, SAIC programmers modified the AUMD program's object code to extend its expiration date. This modification allowed Air Force manpower personnel to continue to use the AUMD program despite Davenport's refusal to provide the source code.
In 2002, Blueport brought the present claims against the Government for copyright infringement and violations of the DMCA. Specifically, Blueport argues that the Air Force infringed its copyright in the AUMD program. In addition, Blueport argues that the Air Force violated the DMCA by extending the expiration date in the AUMD program's object code-thus circumventing the measures taken by Blueport to prevent unauthorized use of the program. The CFC dismissed Blueport's claims for lack of jurisdiction on the ground that the Government had not waived its sovereign immunity for any of the claims. Blueport now appeals.
Subscribe to:
Post Comments (Atom)
6 comments:
While I appreciate the irony of the government ignoring the DMCA, it can be argued they have some stake in the creation of the AUMD software. While the actual coding was performed by Sgt. Davenport, he received some benefit from the Air Force, in terms of resources and personnel, to test and improve his software. These activities are part of the typical software development cycle and are usually considered as part of the developer's costs (yet Davenport got them, seemingly, as part of his paid service to the Air Force).
While the extent of the government's role in the program's development is unclear, it seems misleading for Davenport to imply he did all the work himself.
Dear Mr. Baumstark, the opinion didn't turn on the considerations you note, but in any event I don't think they go the issue of whether the work was one that should have been considered a work of the United States. None of the facts support that view. Moreover, testing is something that occurs in the private sector too. The sense I get from the opinion is that Sgt. Davenport was doing what we want developers to do: tailor the product toward customers' needs. But to me, even giving your views full weight, none of that excuses the Air Force's conduct, IMHO.
Dear Mr. Party,
Thank you for another interesting post. I understand your point about the hypocrisy of the government circumventing the DMCA while simultaneously trying to promote it worldwide. Taking that aside, and taking aside the claim of sovereign immunity. To what extent do employees maintain intellectual property rights over code they write for their work, that is directly related to their work?
What are the mitigating factors? Exempt/hourly employee status. Whether the job description includes programming? Where the code was maintained?
I work at a university and I know the deal is that faculty share/surrender their intellectual property rights to some degree with the University, regardless of where the actual work is done. But there is a contract that spells this out. I'm suprised there is no similar blanket contract like this for the armed services.
This is a case that is different simply because the "employee" was a service member. Question: When are you "off-duty", Answer: never. I was in the Army and in a special ops unit. We got called at all hours, including ringing phones at 2am. I even once ran off a soccer field in the middle of a match. Even on the weekend, you are subject to any restrictions your commander deems fit for the unit and its mission.
Point is that even "on his own time" is a complicating factor in this case. As for the review that was written, the culture on these job performance reviews is such that competent job performance should reflect the members role in saving the world so you have to discount any glowing language in such documents (stating the member is competent translates to "he was napping whenever my boot wasn't connected to his rear").
Further, remember in the military, EVERYTHING is viewed in light of national security. The Air Force's thinking is probably one of this now being vital to accomplish smooth management of its personnel without disruption in light of wartime operations.
That all being said, giving sovereign immunity to swipe intellectual property WITHOUT JUST COMPENSATION is a dangerous concept. Anybody think the government can stiff the makers of the Humvee? Even the infamous Jeep was taken from a company deemed too small to build its own design in the numbers needed and the design given and contracted to a major car company (Ford originally). But even then, the company was given royalties and compensation for its design.
I find the anti-circumvention claim rather dubious on its face. In order for a technological measure to "effectively control access to a copyrighted work" by the definition of the statute, there must be a process by which otherwise unreadable works are transformed into readable works.
If, in this case, the main body of the object code is the copyrighted work and the portion of it which checks the date is the protection mechanism, then that mechanism does not meet the definition of an effective copyright protection mechanism proscribed in the statute. The remaining object code can be read and executed both before and after the date check is executed. The date check code merely instructs the computer to cease running the code. If the object code were encrypted and the date check mechanism also decrypted the code, then that would be another matter. But clearly, it is not an effective copy protection mechanism, either on its face or by the book.
Hey.. been blogging for a while but never ever came across to your blog. Interesting reading here....
LLCB
Post a Comment