You are here > Home > News Columns HOME > NEWSPAPER COLUMNS> The Protection of U.S. Software and U.S. National Security

 

Previous U.S. Acquisition of Greenland; The Story and Impact	The Protection of U.S. Software and National Security	Next The SAVE America Act
Published by The Galveston County Daily News Published: February 10 28, 2026
A disconnect needs to be addressed, not only for the wellbeing and protection of U.S.-developed software, but also for U.S. national security.  Drafters of legislation and regulations need to be on the alert for unintended consequences.  There are always self-serving interests who will seek loopholes to get around the intended purpose of our laws and regulations. Historically, the U.S. has enacted bills to protect domestic industry.  In doing so, legislators should determine how regulators will implement measures. It’s a “sanity check.”  Too often legislators don’t ask such questions and simply rely upon the regulators to do this for them.  Instead, they should ask, “Are the law’s requirements and purpose realistic and can it be realistically enforced?”  A close friend who is a software engineer focusing on software security is very concerned.  As a person working to keep companies in compliance with U.S. export controls (which includes software and technology transfers), he works extensively with governmental agencies, providing technical input during the developmental and interpretation phases of such laws. He contends that as technology evolves, the enforcement mechanisms must evolve with it. A clear example is the Trade Agreements Act (TAA), which was updated in 1979.  Keep in mind, back then there was no internet and we were dealing with a limited number of supercomputers.  The TAA was designed to encourage companies to domestically manufacture products or source components from foreign countries with whom we have trade/security agreements.  It’s designed to prevent the importation of components from non-TAA countries, assembling these foreign-sourced components in the U.S., calling them “Made in the USA” and thereby undercutting U.S. manufacturers or TAA compliant suppliers.  Today, countries such as China, India, Russia, Malaysia, and Indonesia cannot sell components (even those assembled in the USA) under TAA-covered contracts unless it meets a “substantial transformation” criterion. When the TAA was originally written, there were few software or computer programs, those that existed were developed in the U.S.  and then “translated” from human-readable source code into machine executable code.  Recently, software development has moved off shore and away from trade-agreement countries, with some companies fully replacing U.S.-based developers with non-U.S. development teams. Under the TAA the “translation” from human-readable source code into machine-readable executable code has been interpreted as a “substantial transformation.”   Under this interpretation, software may be considered TAA-compliant regardless of how or where the source code was developed.  Under this interpretation, software written in China but compiled (i.e., assembled) in the United States is considered TAA-compliant, because the government contends the compilation process provides a “substantial transformation” (human-readable source code versus machine-executable code).  I strongly disagree with this interpretation and contend a “compilation” is not a “substantial transformation”. The issues are: 1) should the simple “translation” of code be considered a “transformation” under the TAA and 2) should there be national security concerns over software developed by nations unfriendly to the U.S. being integrated into U.S. products, especially those products with military or other sensitive applications.  The answer should be NO to the former and YES to the latter. Congress and the Administration need to clarify a simple “translation” isn’t a TAA-“transformation” and software developed by our enemies should be prohibited from use by our government agencies.
	About the Author | Columnist 2026 Bill has written over 300 guest columns and editorials over the last ten years for numerous publications across the country and he continues to do so. He worked for the U.S. Department of Commerce (1973-2004) and the Bureau of Industry and Security (BIS), which regulates and enforces the export of "dual use" products and technology (1987-2004). Among other things, during his tenure at DOC/BIS, Bill was instrumental in getting Congress to authorize police powers for BIS' Special Agents in the Office of Export Enforcement. After retiring from federal government service, Bill served for six years as the Chief Deputy Clerk for Elections in the Galveston County Clerk's Office, overseeing and adminisering federal, state, and local elections held within Galveston County, Texas.
Comment from a cyber software engineer residing in the Houston Metropolitan area: Great article.  Here are three minor points of clarification that your readers might find helpful: The TAA is designed to disadvantage components from non-TAA countries, not to prevent the importation of components from non-TAA countries. You also state that TAA compliance allows a product to be labeled Made in the USA. That isn’t correct. The TAA only governs country-of-origin eligibility for federal procurement purposes, while Made in the USA labeling is governed by the Buy American Act, which requires that at least 51% of development cost be incurred in the United States.  From a policy and risk perspective, there is a strong case to be made for encouraging U.S. software companies to perform core development domestically rather than offshoring it. We are seeing experienced U.S. engineers displaced while lower-cost, less experienced labor is substituted overseas.  Often, we see the predictable impact of these decisions on software quality, security, and long-term maintainability.  Federal procurement rules partially address this through domestic-content requirements, but private-sector or critical infrastructure buyers are not subject to the same constraints.  Comment from a retired software engineer residing in Utah With so much of the development of software being done overseas because of lower labor costs, if we really wanted to see it brought back to the United States, we would take a play from the Trump playbook – impose tariffs!  Compiling code is about 1% of the total work. Marrying code with hardware -- like with Apple products -- creates usable and valuable products.   Allowing half of the development to skip the tariffs just makes no sense. Applying tariffs will help encourage the development of domestic companies and bring job back to America.    Additionally, do we really want the critical elements of our needed technology to be sourced elsewhere and even by nations unfriendly to the U.S. It just doesn’t make sense. Feedback from a cyber security expert living in Houston: I really appreciated this column and strongly agree with your two points: - Software programs can be translated (compiled / assembled) anywhere in the world and sent to the US.    Compiling in the U.S. serves no additional purpose than to get around the TAA requirement of a substantial transformation. - Your second point is something we must seriously consider.  Software developed in unfriendly nations shouldn’t be integrated into the U.S. defense systems, U.S. critical infrastructure (i.e. finance, energy, healthcare, telecommunications, transportation, etc.), or even the day-to-day U.S. cyber world. Action to do so this needed to be done yesterday!  We need a smart and intelligent legislator to step up and do this, but then, finding such a person is perhaps an oxymoron!

.