Another Trouble with the TPP is its foray into the software industry. One of the more surprising provisions in the TPP’s e-commerce chapter was the inclusion of a restriction on mandated source code disclosure. Article 14.17 states:
No Party shall require the transfer of, or access to, source code of software owned by a person of another Party, as a condition for the import, distribution, sale or use of such software, or of products containing such software, in its territory.
The provision is subject to some limitations. For example, it is “limited to mass-market software or products containing such software and does not include software used for critical infrastructure.” The source code disclosure rule is not found in any other current Canadian trade agreement, though leaked documents indicate that it does appear in a draft of the Trade in Services Agreement (TISA).
The provision has generated considerable uncertainty since key aspects are undefined. For instance, what is “mass market software or products containing such software”? There is no definition in the TPP nor a generally accepted definition for mass market software or products, meaning it could include software sold to businesses or software in mass market products.
The inclusion of “software used for critical infrastructure” is similarly open to interpretation, raising the possibility of conflicts between mass market software and critical infrastructure software. Indeed, Stewart Baker, the former general counsel at the NSA, has noted:
“the ban doesn’t apply to code run on critical infrastructure, which will make for endless disputes, since there’s very little mass market software that doesn’t run on computers involved in critical infrastructure.”
Baker’s concerns extend beyond the likelihood of confusion and disputes, as he also notes the long term risks of including this provision in a trade deal:
Right now, this is a measure US software companies want. That’s because we make most of the mass market software in the market. But that’s likely to change, especially given the ease of entry into smart phone app markets. We’re going to want protection against the introduction of malware into such software. The question of source code inspection is a tough one. If other countries can inspect US source code, they’ll find it easier to spot security flaws, so the US government would like to keep other countries from doing that. But I doubt US security agencies are comfortable letting Vietnam write apps that end up on the phones of their employees without the ability to inspect the source. In short, this is a tough policy call that is likely to look quite different in five years than it does today.
Confusion about the scope of the provision and worries about what it might mean longer term are just two of the concerns with the source code rule in the TPP. One more that brings in one of the founders of the Internet in tomorrow’s post.
(prior posts in the series include Day 1: US Blocks Balancing Provisions, Day 2: Locking in Digital Locks, Day 3: Copyright Term Extension, Day 4: Copyright Notice and Takedown Rules, Day 5: Rights Holders “Shall” vs. Users “May”, Day 6: Price of Entry, Day 7: Patent Term Extensions, Day 8: Locking in Biologics Protection, Day 9: Limits on Medical Devices and Pharma Data Collection, Day 10: Criminalization of Trade Secret Law, Day 11: Weak Privacy Standards, Day 12: Restrictions on Data Localization Requirements, Day 13: Ban on Data Transfer Restrictions, Day 14: No U.S. Assurances for Canada on Privacy, Day 15: Weak Anti-Spam Law Standards, Day 16: Intervening in Internet Governance, Day 17: Weak E-commerce Rules, Day 18: Failure to Protect Canadian Cultural Policy, Day 19: No Canadian Side Agreement to Advance Tech Sector, Day 20: Unenforceable Net Neutrality Rules, Day 21: U.S. Requires Canadian Anti-Counterfeiting Report Card, Day 22: Expanding Border Measures Without Court Oversight, Day 23: On Signing Day, What Comes Next?, Day 24: Missing Balance on IP Border Measures, Day 25: The Treaties With the Treaty, Day 26: Why It Limits Canadian Cultural Policies)
heavens, I’m glad I can read.
Blackberry and Linux leap to mind.
(blackberry’s security, Linux open source license. YOU
have to post derivative works.)
poor WIN NT. their stack was copies from linux.
poor blackberry. They got booted for not posting encryption algorithms.
looks like stateside treaty to me. (Only if we want to. ala softwood, fishing, potatoes, etc)
pardon me while I post 13 terras of MS goggly-gook. This is my source code (Ever seen a word HTML page?)
pat
Another aspect of the problem with this clause is the use of source code escrow when creating contracts. I recall in the 1990’s working for a Canadian owned company where we created terminal emulation sw for a US computer company. One of the requirements was that each release had its source code escrowed in the US (in the event of the Cdn company’s demise I suppose). It would appear that this is no longer possible if TPP gets ratified. Bad for both parties then, no protection of a critical asset.
The guy at the NSA is correct. Think of the innerd source code of a cpu when reading this. Cpu’s can do auto encryption/decription or be told where to do it.
I also agree with Donovan about using open source code. It goes with the philosophy of engineering.
fugsi kode yang harus di ketahui
Do a google search on his complete statement. He speaks indonesian. The result needs to be translated via g translate to see his point of view, about electronics, and their backdoors.
pastikan tidak banyak trouble di fungsi
banyak sekali problematika di dunia komputer
Pingback: Links 15/2/2016: Zorin OS 11 Lite and Business, Meizu Pro 5 Ubuntu | Techrights
Pingback: The Trouble With the TPP, Day 50: The Case Against Ratifying the Trans Pacific Partnership - Michael Geist
I really feeling bright
reading this article about security
It’s increase my knowledge about that