Open Source Software has been findings its way into various governments and government entities throughout the world. And it is finding its way more and more into defense industry. And the stringency of defence industry regulations may cause conflicts with the open source license requirements for openness. One example is the co-existance of OSS licenses (GPL2, etc) with International Traffic in Arms Regulations (ITAR). The software used in defense industry apps is being ported to Linux more and more. Yet there are restrictions in use and distribution which may come in an apparantly direct conflict.
As long as there is a clear boundary between the app and the OSS modules, the issue of conflict is minimal to non-existant. But what if there are changes required in the OSS code to make sure the apps function correctly and with the required performance. Again if the change is not deemed to be of such significance that its open-ness does not cause any concerns, then it is quite likely that releasing the changes to the community may not be prevented and in fact be encouraged.
And there might be the possible codes that are derivatives and or complete new modules in the relam of an OSS, and its release is not recommended and is indeed prevented by oposing regulatory requirements. In such instances, what are the paths of most benefit and least resistance.
The general attitude in the defense and related industrues is a matter of minimization of exposure and legal precendenses, and it does not quite jive with the OSS community attitude for code openness.
A more unified co-existance is bound to develop between closed and open source codes as more and more OSS apps are being developed and used in a more regulatorily structured setting.
ITAR supersedes, not conlficts with oss
I've been spending an inordinate amount of time around open source and export control laws the past week or so. Which means I know enough to be dangerous, a caveat on what I am about to say. Consider that I am asking as much as saying here.
I also work for a defense contractor and while trying to push/promote/prod them into being a producer, not just a consumer, of open source - we have to be aware of these distinctions.
ITAR classification happens when Dept of State State finds your application to have military/defense application(s). ITAR supersedes Commerce Dept export controls and you have to do things like collect social security numbers, validate citizenship, etc, before you can distribute. The same burdens and restrictions on who you can provide the product to apply to secondary distribution. I don’t believe ITAR restricts me from providing source code, however it does put national defense ahead of unbridled worldwide distribution.Is this unlike Redhat’s choice to distribute RHEL to just their 'friends'? A friend in their case happens to be someone who pays for support. Redhat then leverages Trademark law to put speed bumps in the path of secondary distribution. The US Gov puts a similar, albeit larger roadblock in place to redistribution.
I've no doubt that ITAR and National Security trump some aspects of the intent behind open source, but I doubt anyone is going to make a compelling case that these ideals should trump National Defense, or enable the 'bad' guys.