If you’re reading this, chances are you’re already familiar with some of the ways open source software (OSS) standards affect software development. Even so, developing software for the federal government presents its own unique set of problems that are further complicated by OSS standards.
In this environment, companies must assess the government’s ambivalence toward open source software, as well as address the considerable challenges of intellectual property (IP) protection when federal procurement regulations and OSS licenses get in the way. apply.
A love-hate relationship with the OSS
Regarding the purchase of software, the government has taken a strongly pro-OSS position. For example, recent policy guidance from the Department of Defense (DoD) Chief Information Officer states that the DoD “shall follow an “Adopt, Buy, Create” approach to software, preferably adopting government or OSS solutions. existing ones before purchasing proprietary offerings. »
For over a decade now, the DoD and other federal agencies have recognized the critical benefits provided by the widespread use of well-controlled OSS. These benefits include rapid adaptability to new applications, robust, efficient, and error-free code, and reduced risk of vendor lock-in.
However, these benefits are potentially offset by two substantial risks that concern the DoD: 1) the OSS may present an entry point for malicious code, and 2) if improperly shared, the OSS may allow adversaries to gain knowledge of national capabilities, limitations, and vulnerabilities the secrecy of which is vital to United States security interests.
Notwithstanding these potential drawbacks, the benefits of using OSS have led the DoD to consider all software as “open by default” (i.e. releaseable as OSS), with notable exceptions according to that the software:
- Was developed for “national security systems”, i.e. information systems supporting intelligence activities, cryptological activities, military command and control or weapons systems
- Contains “critical technology”, a broadly defined term including the categories of advanced control environments, persistent monitoring, power sources and management for distributed network sensors, high performance computing and electronic components criticism for the defense
- Is subject to export restrictions – in practice, this means that the software is subject to one or both sets of federal laws governing the International Traffic in Arms Regulations (ITAR), which regulate the sale, distribution and manufacture of defence-related articles, or the Export Administration Regulations (EAR), which regulate dual-use items that are not directly covered by ITAR, but which could nevertheless be used in defense related applications
- Is subject to user licenses that prevent distribution to the public
While these exceptions may exempt software from the DoD’s default OSS approach, unless the software delivered under contract is exempt, the contractor must provide it to the government as OSS.
Exceptions confirm the rule
Determining whether an exception applies is usually not straightforward, not only because terms such as “critical technology” are broadly defined, but also because of funding source issues arising from the supply contract itself. same. For example, many DoD software contract deliverables fall under the “national security systems” exception simply because of the huge demand and high priority of projects in these areas. Similarly, the categories involved in software purchases may involve “critical technologies”, which are designated on a project-by-project basis by the project manager. Additionally, the EAR/ITAR lists are quite long, which further limits the government’s ability to designate a software deliverable as OSS.
Government use rights limitations may also prevent software from being delivered as free software. For example, in the absence of an exception discussed above, if the government has “unlimited rights”, it can release the software delivered as OSS. However, if a vendor funds some or all of the software development costs, the vendor may limit some or all of the government’s ability to release the software as free software.
For example, for DoD contracts, if the vendor funded a portion of the software development costs privately, the government may have “Government Purposes Rights.” These rights only allow the government to distribute software in internal, government-only open source libraries, such as Redhawk SDR. The “restricted” and “commercial use” rights further limit or prevent the government’s ability to release the software as free software.
Is the OSS made for you?
Whether a company should allow its software to be released as OSS is a critical decision rooted in the company’s business model. Generally, to the extent the software is used to implement another company’s technology (for example, UAV flight control software), the company should retain the software as proprietary. Similarly, software delivered directly to consumers (eg, Microsoft Office, Adobe Acrobat, etc.) should also be maintained as proprietary.
On the other hand, if the software primarily facilitates access to other sources of income, such as the way Google’s search engine facilitates access to advertising revenue, the OSS version is beneficial, allowing rapid innovation in many disciplines to support these flows. Similarly, software-as-a-service (SaaS) products are often initially marketed as OSS (either for free or for a nominal fee), while revenue from such services is generated through implementation services or of personalization.
It’s OSS, not philanthropy
Given the disclosure and licensing requirements associated with OSS, what intellectual property protection strategies, if any, will work for OSS? This issue is further complicated by the Supreme Court’s Alice decision, as well as other Federal Court decisions that followed Alice, which led to the post-grant invalidation of a multitude of software-related patents.
Due to the continued uncertainty arising from these cases, as well as the cost and rapid pace of software-related innovation, the use of patents to protect software innovation is now often impractical. However, while software-related innovations may relate to unique or specialized technical systems (e.g., software that operates a suite of wearable sensors), the use of patents remains a viable intellectual property protection strategy, and the probability of obtaining a strong software patent improves considerably by limiting the scope of the patent in this direction.
Despite the challenges, inventive software content can still be patented and creative aspects of open source software can still be copyrighted, bringing value to intellectual property owners.
Patent and copyright coverage for open source software can provide a valuable safety net to better control the rights granted when releasing innovative software as open source software. Although OSS licenses may limit certain performance rights normally enjoyed by copyright and patent owners, OSS licensees may use their OSS licenses as a defense, if any, against unauthorized uses of software using OSS.
Additionally, offensive paths are available when others use a company’s IP-protected software without a license or if they violate the authorized OSS license for that software. In this way, legal intellectual property protections can serve as a safety net, ensuring that software innovations are used by others in more predictable ways and preventing free software from becoming the gift of hard-won innovation.
About Martensen PI
At the intersection of business, law and technology, Martensen understands the tools of intellectual property. Martensen knows the business of intellectual property. We understand the technology market, especially when government is a customer, and we know how to plan, assess and adjust. Patents, trademarks, copyrights, trade secrets, licenses are our tools.
Media contact Martensen IP
Mike Martensen | Founder
Build ID: 305460