This writer should do a little research and educate himself on the DoD software community a little bit.
The DoD has been using Linux for years. Red Hat has HUGE contracts within the DoD, there is an entire cloud ecosystem stood up on Linux hosted by Defense Information Systems Agency (DISA).
Part of the reason so many people use Red Hat specifically instead of Debian, say, is rules prohibiting the use of "freeware". But if you pay Red Hat for Linux, suddenly it isn't freeware anymore.
You're completely wrong on this. The software released under the GPL should not at all be assimilated to freeware and even Stallman encourages to sell GPL software. http://www.gnu.org/philosophy/selling.html
Companies pay Red Hat to get QA, support, liability and some level of interaction with the development community.
I know its not actually freeware, that's why I used scare quotes. The thing is though, that under the purchasing rules we used when I was working for the DOD all software acquired free of charge was categorized as "freeware" and we couldn't use it in deliverables. Hence the use of Red Hat, we couldn't actually make use of their support because it was going on classified machines but the mere fact that they took our money meant that we could get past certification.
> the DOD’s use of open source code will alter the GPL for said code (they can’t, for obvious reasons, release any code they use and modify back into the wild)
Making changes to a GPLed program, and then keeping them to yourself, is completely within your rights under the license. It's only when you sell or give away the updated product that the GPL's rules start getting triggered.
Mind you, that might be an issue when the DoD sells some technology to another country. Take as an example all the software running a plane such as the F16. If you sell the plane to Brazil, then you'd have to share the source code for the modules with the Brazilian DoD, something that I think is not the current policy.
(I'm mentioning Brazil because, if memory doesn't fail me, one of the requirements they asked of countries/companies bidding to provide them with 4+ generation planes was that they should be able to audit and modify all the software running the planes.)
You can always pack it as a blob and claim it's firmware. Also, I would think twice before annoying someone who sells F-16s and is willing to use them (as well as the newer toys) against those who annoy them.
And yes, being able to audit the complete code for all components was one of the initial conditions and, IIRC, the reason why the Grippen NG was originally selected by the military. But then politicians took over and nobody really knows what will come out of that.
You're not getting it: This isn't some special military privilege. You or I could do the exact same thing. Anyone can take GPL'ed code, modify it, and keep the changes to themselves.
I get it. However, the scenario you are envisioning is not really consistent with how the US DoD operates.
It's not usually some E-4 sitting at a terminal writing the software that runs sophisticated modern weapons systems.
Instead it is a civilian contractor who is writing the code and then selling the software along with the system to the US military, i.e. the software is being distributed for money.
The GPL requires you provide the source code of the modified application to anyone you distribute it to. Most military projects already require source code from their contractors. Thus, most contractors already comply with the terms of the GPL.
Besides, if you're distributing the application to anyone besides the DoD you're going to have bigger problems than GPL license compliance.
If Alice takes a GPL program, modifies it, and sells it to Bob, nobody but Bob can demand Alice share the source. If Bob does nothing, nobody but Alice ever sees the source.
Sure, the GPL allows it, but the GPL doesnt allow Bob to dictate what Alice does with the source once she has it (GPL v2, term #4). If she decides to distribute it, his recourse is to not do further business with Alice. That could be enough, but if Alice sees sufficient short-term benefit, that may be a risk she is willing to take.
And those rights are automatically passed on -- if Alice sells the product to Bob and he resells it to Carol and she compiles it and gives the binary away to Doug, Doug can call Alice and demand the source.
I think he's implying that if there was a question about it being shared with other organizations in the government (or other governments or defense contractors), they would use that to justify not re-releasing the code.
I'm glad someone pointed this out, I was wondering the same thing when I was reading it.
That said, it would be nice if they decided that certain bug fixes and such could be sent back to developers, not at the expense of national security, but I can hardly see how a bug fix being pushed back out could hurt the military though.
You should read the GPL more closely and expose yourself to some of the legal commentary on interpretations of the word "distribution," as used in the GPL.
Your right to keep your changes to yourself end when you distribute your derivative work to a third-third party. The question is: what constitutes distribution? Some have argued that some hosting and outsourced management operations may constitute distribution for the purposes of the GPL.
Your approximation of the implications of the GPL are probably sufficient for most startups, but your understanding is insufficient if you are so eager to insist that your approximation is still applicable for an organization of the scope and complexity of the DoD.
That said, the article doesn't really seem to get it either.
Would the DoD be producing the code, though, or contracting it out? If that latter, that would seem to me to constitute "selling", as the producer would be paid to write the code, then give it to the customer.
That doesn't make sense. If you write code based on GPL-licensed software, then sell that to me, all the GPL says is that I have the right to the source code (not just the executable) and the right to modify/distribute/sell it as well.
However, if the DoD is hiring outside help, I'm not sure the above case is even relevant. When a startup hires an individual to write code, the individual doesn't necessarily maintain the rights to the code he writes, because he's acting on behalf of an organization (so the rights are automatically assigned to the company instead). And a company is free to distribute GPL code internally without releasing its source externally.
A separate question is whether the fact that the DoD is a government agency makes this aspect of corporate law not apply. Most writings of the public government are automatically in the public domain (a law which was pivotal in the Pentagon Papers proceedings), and the fact that the government is comprised "of the people" may make this issue more complicated.
> And even though the DOD’s use of open source code will alter the GPL for said code (they can’t, for obvious reasons, release any code they use and modify back into the wild)
This is what I don't understand. What are they altering about the license? And what are these seemingly 'obvious' reasons? The NSA was fully capable of releasing SE Linux. As for software to control missiles, etc., the real issue is that individuals (and even nations, as we've seen) can't create the physical weapons easily - the software itself is not necessarily the biggest hurdle.
(And, depending on what type of use we're talking about - though we'll probably never know exactly - the GPL may not even need to take effect, just as GPL and proprietary software can both coexist on an underlying GPL operating system, for example).
That would require contractors to give the code back to DoD. As far as I know you have to give source of GPLed code to the users you are distributing binaries to, not necessarily to the general public.
I assume that he is talking about security concerns, not licensing concerns. For example: the specific areas of code that the DOD uses will become public. This may leak more information than the DOD would like.
The more fixes you see them sending upstream in particular area, the more likely they're using that area of code.
If you suddenly see a new project getting contributions from some particular source, you may be able to correlate that with a project they're working on.
As others have said, nothing requires them to do this.
And, as a practical matter, the fact they used Windows seems to indicate they can either maintain a kernel entirely in-house (as essentially no MS developers have security clearance) or that they aren't focused on what the kernel does in the first place and do all of their special software in userspace. My money's on the second of those possibilities.
Linux looks increasingly unstoppable these days. I find it easy to believe that in 100 years time, everything with a CPU in it will be running some descendant of it - and quite possibly it will have Android in its ancestry too.
If you're creating any kind of new computing gizmo now, Linux gives you so much existing value for free (allowing you to add your own stuff on top) that it's hard to see why you'd use anything else.
I think you are exactly right. Why pay thousands of dollars for operating system features that are either unstable or unnecessary, when you can use Linux for free and usual make it do exactly what you want.
I think that things like Raspberry Pi and OLPC will also help move linux into the hands of regular consumers.
As much as I like Linux, is this really the best outcome? A monoculture of any form is not helping anyone.
There are other operating system platforms like the various flavors of BSD that might work just as well. Having more than one option is always a great benefit.
God I hope not. I use Linux at work, because it's currently the best option in terms of software & hardware support, but if you've EVER done anything with the Linux kernel, you should hopefully have realized how helplessly terrible it really is. It's an enormous beast, the turnaround time for testing changes is terrible because it takes so long to compile even after you change a single file, etc.
If we're still using Linux in 2112, we should just launch all the nukes and end ourselves.
It takes on a modern machine (in my case a laptop from last year) about 4-5 mins, full with modules. In comparison, some random java project I am working on, it takes maybe 7-8 mins.
And actually, if you ever compiled a kernel, which I highly doubt, the make system does not recompile everything, only your change. Besides that, modules you can compile individually.
i7 laptop with 4 GB of RAM. I haven't measured it, but whenever I kick off a kernel build it certainly takes long enough that I end up going off and checking email, etc. But you're right, I haven't built Linux kernels for desktops and Android devices and BlueGene systems, hacking in changes or just putting in debug prints to try and figure out what the fuck Linux is doing so I can write a hardware simulator. Oh wait, yeah, I fucking have.
The kernel I'm working on now, non-Linux, can build in about 5 seconds--and this kernel works on a pretty large segment of hardware, too.
There have been a number of articles / studies on this, the ones I'm largely familiar with in the early aughts / late 90s.
It mostly boils down to fundamental architecture, monolithic design, UI decisions, conflating data + code (e.g.: a "Word Document" or "Spreadsheet File" is really a general-purpose computer program, not merely static text), and ingrained user practices (see today's PHP rant for a somewhat parallel discussion of culture), as well as an inherent lack of transparency, a filesystem model which prevents being able to delete in-use files, etc., etc., etc.
It's a pile of small faults which, in total, create gross instabilities.
Worse: the reasons for this are deeply linked to Microsoft's need to maintain a deep monpolistic lock on the personal computing sector.
And as much as Microsoft continue to address small aspects, the big picture eludes them. Empirical data continue to show that Microsoft systems are far more vulnerable to exploits than alternatives, particularly Linux and Unix derivatives. OpenBSD being the most preemptively secure, in part by digging deep into infrastructure (classic example: string handling to avoid buffer overruns, and an entire huge class of security blunders). There's a humorous bit about various Linux, BSD, and Microsoft responses to security disclosures that's pretty close to truthful (sorry, can't dig it up right now).
My understanding is that Vista and beyond have a fairly indepth and rebuilt security architecture that actually quite good.
Am I wrong?
Further, Linux doesn't seem to have a different design when it comes to monolithic design and tends to actually have worse permissions problems out of the box WRT granularity.
"Linux" can apply to a lot of things, ranging from the kernel to general userland. Clarifying that, there are numerous ways in which it is not monolithic (not in the microkernel architecture sense, but in a general sense) to the same extent Windows is. I'll distinguish here from the kernel and system as a whole (kernel + libraries + executable).
First, a given Linux system can be virtually entirely divorced from userland. Android would be a great example: it runs the Linux kernel and a very, very small set of standard features, on top of which the Android infrastructure itself is place. Android by itself is nowhere near POSIX compliant, though it can be made so by adding additional software (e.g.: busybux, terminal app, etc.).
More generally, any given utility for a Linux system can generally be provided from multiple independent sources, from system libraries to common utilities (e.g.: numerous awk and vi implementations) to services (webservers, databases, etc.). Any one component can generally be replaced or even removed without impacting other components (barring tight dependencies).
It's possible to build very minimial, or very complete, Linux systems. Lightweight bootable images based on little more than a kernel, shell, and busybox. Heavy server or desktop systems with thousands of packages.
The kernel itself is highly modular, both in terms of features (networking, filesystems) and devices (disk, ports, network devices...). Unless specifically added in, graphics are not included in the kernel (obviating large classes of b ugs), and systems can be run without a GUI or even a directly attached terminal. This is a level of flexibility you simply do not have with a Windows box.
Permissions granularity in my experience is largely a bogeyman -- you don't need a highly complex system, you need one that works. The important things are appropriate and usable permissions within an understandable framework. Linux supports user/group/world read/write/execute permissions, SUID, SGID, and sticky bits. It also supports ACLs, though these are very rarely implemented -- they're a maintenance nightmare. If you'll stick to Debian, you'll fidn that permissions matter and are generally set to be both safe and sane by default.
If you've got something specific in mind, I or someone else might be able to address it.
As for Vista: Microsoft have played the "we've fixed the security problem" record so many times over the past 15-20 years that the grooves are worn smooth. While things may have improved, I still see a landscape littered with exploits and attacks, as well as a security infrastructure (virus, spam, network intrusion, and other scanners) I in large part don't have to worry about on Linux systems. Yes, there's vigilance required. But it's at a whole different level of intensity. While I don't work with Vista (and apparently few will), I don't see any fundamental changes which would be required to change the Linux vs. Microsoft security picture.
I still don't see any _fundamental_ difference on the points you make between Windows and Linux: monolithic design due to performance considerations, both have bugs, etc.
A given bug in a GNU/Linux distro tends to affect a single piece of software which any given user may or may not have installed, may or may not be using, and/or may or may not be using in a way that exposes them to the vulnerability. There are classes of bugs for which this is not true, mostly affecting the kernel itself, but these are fairly rare.
Bugs affecting Windows frequently exploit features which are deep and broad, have profound systemic effects, or are easily exploitable on large classes of systems. The Sapphire/Slammer worm comes to mind -- you wouldn't think that the Microsoft SQL Server would be a widely installed desktop component, but as the Desktop Engine, it was.
http://en.wikipedia.org/wiki/SQL_Slammer
Other factors affecting this:
With Linux, I have one-stop shopping for most of my security updates affecting virtually ALL software on my system. Updates are atomic, can generally be applied without rebooting, and (due to nearly two decades of process improvement and strong policy) nearly always work. There are differences even among distros -- I find Debian tends to have the most robust practices, so long as you stick with stable, RHEL is a lot more hit-or-miss. This is a direct consequence of Debian Policy. Read it and understand it.
Linux software components tend to do one thing and one thing well. Rather than ship kitchen-sink "Enterprise Solutions", most Linux software and subsystems focus on a single task, are principally controlled and configured via commandlines and textfiles (lending themselves to scripting, version control, and configuration management generally, hence, better and more consistent processes). Again, not uniformly true, with GNOME (not a server package) and Systemd being notable exceptions.
There's an unprecedented level of transparency. Even as a mostly shell-tools kind of sysadmin, I can directly monitor system state through shell tools, strace, and /proc. Even finding myself on Linux-like environments (e.g.: Mac OS X, Solaris) lacking all of these features, I feel their absence profoundly. There's little about a process or system I can't examine directly and/or log.
There's more out there. If you're not willing to be convinced, there's little I can say or show you that will change your mind. But you're more than free to do your own legwork.
>Nick Petreley's "Security Report: Windows vs Linux: An independent assessment" remains largely valid
No, it doesn't.I skimmed through it and it's pretty outdated, especially with the changes in Windows Vista and Windows 7 and with regards to things like IIS.
They're all fundamentally insecure, because they are designed around the notion that we trust certain users and not others, instead of the notion that we trust certain code and not other code, depening on what it wants to do.
How does that work? It's going to be impossible to draw the line.
With that clause you clearly couldn't put the software into the guidance computer on a warhead or the missile launch system itself. But what about a system on the weapons launching platform that isn't a weapon. Is the computer running the engines on a navy cargo ship 'used for the purposes of warfare'? What if the system controlled by the software is completely incidental, or defensive in nature? The fire control system saves lives, is that 'for the purposes of warfare'?
And what about the computers used to design weapons? Is an engineer working on a weapon using the software 'for the purposes of warfare'?
And what about the accountant at the company that makes weapons, is he using the software for the purposes of warfare even if he doesn't know anything about the weapons?
Is the machine shop that gets 1% of its business from selling parts that end up in weapons using the software for the purposes of warfare?
It's impossible to make that distinction in any meaningful way.
Should machines that are used to create weapons part of that clause? Is a scout drone a weapon? Is the control software for that drone a weapon? What if it's a scout drone? What if this scout drone is used for reconnaissance by the coast guard to find criminals? What if it's used to find ships in peril and provide fast assistance? There are some black and white extremes, but there's also a lot of grey in between. I'd rather prefer my license to stay out of that mess. The GPL stipulates that apart from the restrictions in the GPL, no further restrictions can be applied to a software. But you're certainly free to license your code under a "no-weapons" clause, I just don't think that the GPL is the right place to do that.
I thought you said you worked in the industry? If you really did, then you'd know that more and more civilian grade technology is being used by military contractors to build military solutions. For this reason, such a clause would get complicated really fast:
- Is it ok to license audrino code under this license? (yes)
- Is it ok to combine other components with audrino under this license? (yes, for non-weapons)
- Can audrinos be used to build a drone? (yes)
- Can this drone be purchased by the government and it's contractors (yes)
- Can the military use the drones? (yes as long as it doesn't "kill or cause harm")
- Can this drone be used for reconnaissance? (yes as long as it doesn't "kill or cause harm")
ok, so now the military is using these drones all over the place. Pictures are taken, stored in databases, and distributed throughout the military. Eventually, some of those pictures are used to strategically bomb an insurgent encampment. Who violated the license?
Even better, what it were Google who purchased the drones and Google maps was instead used for the bombing strategy. Who's at fault now?
I did work in the industry before I developed some sense.
You distinctly miss the point there. Military hardware is controlled heavily. No commercial entities use their data. That chain if events doesn't waist and never will.
There is a wall between the two sides that is rarely crossed.
Which is entirely not true. The fire scout drone for example is a military development based on the Schweizer 330 civilian heli. The S-434 is partially based on changes developed for the Fire Scout drone. The Bell Eagle Eye drone was initially conceived for the military but at a later stage, plans were made to make it a coast guard drone. Many helicopters have two versions, a civilian and a military version, for example the Bo-105 series which was extensively used by the german army but also formed the backbone of the german air ambulance network from the 1970s until the last one was replace in 2007. Which one of those is "military hardware"?
Most of technology initially conceived for military purposes was at some point repurposed for civilian use (Think: That packet-based network nowadays called 'The Internet')
I am also against warfare but if Linux (or OSS in general) helps to enhance the security and realiability of weapons so that they don't kill civil people accidently then it's ok. It's not Linux or GPL what makes things good or bad - it's the people who use it.
If you wan't GPL to be non-violent then you also have to forbid GPL usage in embedded systems, because air planes, cars etc. also can kill people.
And don't forget that Linux users normally pay back to the community. Look at SE-Linux, or SE-Android, for example.
A drone is designed for un-manned flight, nothing more or less. Sure you can strap weapons to it and use it to make it easier to kill people, but you can do the same with a car. But you can also strap cameras and sensors to a drone and use them to do neat science (like these people: http://espo.nasa.gov/missions/hs3/)
Please don't misunderstand me: Weapons are bad. But if we can't avoid them then it is better to use the best option to make bad things a little better.
I don't know, somehow I would feel better being shot to death by flying drones running Linux instead of Windows. After years of having to suffer with Outlook, Exchange, Sharepoint and Internet Explorer it would really just feel like the end of a long torturous assault on my existence by Microsoft.
I increacingly question the notion that there are any just wars, but I don't really see how such a clause is practical or enforceable.
Even if it were practical and enforceable at keeping "evil" from co-opting code contributed by "good," it would also reduce opportunities for "good" to co-opt code contributed by "evil."
I'll point out that the technology we are using to have this discussion was underwritten by the military. The military dumped a lot of money into integrated circuits before commercial applications could fund Moore's Law, and the Internet was also the outcome of a military project. You can argue that there should be other means to fund such advancements, and I'd agree, but this is where we are now.
It is a win for Linux, just may not be for humanity.. But A lot of the software wouldn't be created for offensive weapons and they are going to still be made whether they be run under linux or some other OS.
This is contrary to certain definitions of freedom. For example, Debian's requirements[1] are that "The license must not restrict anyone from making use of the program in a specific field of endeavor".
As others have said "warfare" and "suffering" are too hard to define anyway.
I think it's pretty clear. The definitions have been made ambiguous by the permanent state of military action across the world. We're desensitised to it.
The problem with this is that they are adopting a good tool because a wrong reason. Linux is not immune to virus, and then what would happen when Linux is popular enough to bring malware's writers attention? Are they going to switch to OSX?
You have to be kidding. What are the requirements for this? I haven't seen any published but I'd wager it involves something along the lines of "gigabytes of memory and disk space".
>Another example: If everyone drove BMWs, they would be just as crappy as a Ford Fiesta, right?
If BMW makes the compromises to equal a Ford Fiesta price tag, then probably they are going to be quality comparable.
However, this case is completely different. I don't think Linux share is greater than 10% on the desktop market and that's the target for most malware software.
Edit: BTW I do run Linux on both sides, Desktop(Home) and Server. :)
> the desktop market and that's the target for most malware software
I think that's only the case to the extent the desktop world is tied to the insecure monoculture of the Windows world. You can't tell me there wouldn't be money to be made from being able to reliably infect Linux webservers, for example.
The article is going on about how it's unimaginable to be running Windows in that environment, but I recall a few instances of military vessels running Windows in previous years/decades. Some report of US submarine(s) being dead in the water whenever NT crashes, a cruiser losing propulsion due to Windows crash, etc. I think running Windows on subs is not that uncommon.
The funny thing is that I think everyone here could have predicted those outcomes, i.e. blue screen of death and in-operational craft. You wonder what it is like to work in an environment where the obvious is not allowed to be taken into account or ignored when you build systems.
Yeah, military drones using Linux, what a big win. The fact that the military uses Linux is a big negative for Linux in my eyes. If you support Linux, you're indirectly supporting the U.S. military and by extension murder, aggression and terrorism.
I wish more software licenses had a clause forbidding military use of the code.
Exactly! And let's not stop there. The fact that the military uses steel is a big negative for steel in my eyes. If you work in steel production, you're indirectly supporting the U.S. military and by extension murder, aggression, and terrorism.
That's why I use flint knives and ride a bicycle made of bamboo.
If we were in the steel industry, the right thing to do would be to see that the military doesn't get steel. But we're not, we're mostly programmers here, so I'm saying we should exercise caution and be aware of how the stuff that we make gets used.
Sort of, but the main difference is to what extent are you supporting killing and suffering and whether you have a choice.
The question of social responsibility of programmers (and other professionals) is not an easy one, and I think every programmer should think hard and often about the politics of their work.
Many programmers often dismiss such questions by saying that code in itself isn't moral or amoral, but what is done with it. But when you think more about it, it's just an easy excuse so that they can get on with their lives with a clear conscience.
How do you participate in civilization without being indirectly responsible for its negatives? The only paths I see are to either opt out or accept the downsides while working to improve things.
The second is the most sensible option. I'm not saying people should stop using Linux, I'm just saying that programmers should be more aware of the politics of their work (professional work is almost never apolitical) and strive to actually use their skills and talent to make the world a better place.
There's also a big difference between buying some gum and having the tax you paid on it go to the military vs. actively developing military drones. I'd say that contributing to Linux would fall somewhere in between these two.
So let's purposely write bugs in FLOSS because all of it can be used for evil. For well written comments of the sort you write they can't be any more insulting. This deserves an explanation so let me put it this way: I appreciate that you're voicing your concern but these kind of ideas are detrimental to progress and the prose by which you convey them is orthogonal to my comfort zone. For instance: the guy whose job is to design a military-grade drone is arguably making the world a safer place then the guy whose job is to implement new features in Linux, depending on how they're used. Yet somehow you're biased to assume the worst, which strikes me as a bit naive. Programmers shouldn't be more aware of anything, especially not politics. That's just distracting and unproductive. You choose not to contribute, fine. But it doesn't make you morally superior either way. The constraints you've set for yourself are entirely arbitrary, much like theists construe their own set of restrictions for religious reasons.
It's hard to follow to the natural conclusion. Should we stop using SELinux because the NSA is part of the same government? Should we stop buying servers and other hardware because the fuel bought to deliver it supports violent oil-supplying regimes?
We have to function to have any hope of improving the situation. That does mean supporting at some level the thing we hope to fix.
None of them. The killing machines should not exist.
I used to design guidance systems for which I'm totally fucking ashamed of myself for but at the end of the day unless you observe the process you can't change it.
Yes, let's set the clock for technology back to prehistoric levels. That'll fix all our problems. If you can't find the flaw in this kind of reasoning, go see a doctor to get your head straightened.
First let me say that I'm a long-time Linux user - the first time I installed it was in 1992 from a giant stack of 3.5" floppies. While Linux is extremely secure and can be locked down via various methods, you still cannot say that it is immune to virus infections. If the system is poorly designed and managed, is not using proper protection for services (AppArmor, chroot's, etc) then it can still be vulnerable.
Linux's primary advantage still remains that it has a smaller install base and is therefore a smaller target.
I'm not sure that Linux would be much more secure than
Windows if it was in as wide usage - the largest factor in computer security will always be humans.
Look how easily the recent Flashback virus spread on Mac's - people will continue to input their password when prompted.
It's not really "extremely" secure. Look around, you'll find that at any given time there are probably a couple local escalation exploits, at the very least.
I'm surprised to see a mainstream kernel powering military hardware at all. I'd have expected to see QNX, or something somewhat obscure with hard-realtime features.
My understanding is that the actual drones themselves do run a hard realtime operating system. Linux (and formerly Windows) is used to run the workstations on the ground that the drone pilots use.
I don't know about realtime features, but the point of the article, ( not necessarily the point the military is trying to make) is that open source produces more secure software. The power of open source is somewhat proportional to its popularity (in the sense that it is based on the whole concept of "more eyeballs"), therefore Linux is clearly a better choice.
Also, I don't think QNX is necessarily more obscure. It may not evolve on the desktop/server market, but it is an industry standard in its field.
While I find this news somewhat disturbing considering a military goes against some of the ideals of open source software, the benefits will hopefully be great.
No. Because they won't be distributing it to you, you will not be able to request the source. They will be under no obligation to release anything.
The only thing they have to watch out for is code that is explicitly licensed such that the military can't use it, or the "don't be evil" licenses... and I wouldn't be surprised they've got some sort of immunity against that buried in the law somewhere. Even if they don't, this doesn't seem to be that much code.
I wouldn't expect to see a line of code from them come back to the community... not because they're unwilling individually, but because I would imagine the process of getting it legally safe to release publicly just won't be worth it.
Yes I can't see any potential code enhancement made to Linux by the DOD/Navy ever making it back out in 'the wild'. That said it certainly helps cement Linux's credibility in areas such as this. Calling it 'single biggest win' though, ehh?
So you think the Navy (and their contractors) will be maintaining their own fork of linux and continually port changes over from mainline linux into their fork? I doubt they are that ambitious/stupid. It'll be much much easier for them to get whatever changes they make accepted into the mainline and maintained as 1st class pieces of the kernel.
I expect them to "maintain their own fork of Linux" in exactly the same way they "maintained their own fork of Windows". It seems very likely they're just porting over pure userspace-stuff. If Windows worked for them at all I doubt kernel-space stuff is necessary.
Yes, I forgot about that clause. What do you think would happen when the US Navy gave code to the US Airforce. Would that constitute 'distribution'? US --> Allied govt? Soldier --> soldier?
I wonder if this means that this sort of hardware won't be resold or distributed by the OEM to other nations. I can't imagine that they'd want Saudi Arabia to have the source code to these things.
Obviously they will not be releasing the entire source but it is certainly possible that DoD/Navy/Gov engineers could contribute certain modules, pieces, or resources back to the community.
That's a case where they see it as worth it, and the entire purpose of the project was to contribute back. Part of the NSA's mission isn't just to hack everybody else, but to help defend, as well. At least some part of the agency actually does seem a bit dedicated to that task, despite my natural cynicism causing me to be a bit surprised each time I see it.
Only they first ship you a copy of binary or a piece of hardware running that binary. As long as it's all for in house use, you have no right to the source code.
What people don't often realize is that GPL (both v2 and v3) has a "trigger" condition, where the GPL reciprocity applies only with physical distribution of the code.
As an end-user, it's perfectly fine to modify GPL code and keep the changes private.
That trickle down is going to have a serious, lasting effect in the world of Linux. Here’s how I see this working:
DOD begins Linux roll out
US Government begins wide-spread roll out
Civilian security companies world-wide begin roll out
Universities fall in line
Consumers begin clamoring for better security on their OS
erm... and then virus writers start writing viruses for Linux... Just like happened on OSX... If there is money to be made, virus writers will write for whatever OS has users... Mind you, wouldn't want to be a virus writer getting found out by the DOD...
> and then virus writers start writing viruses for Linux
If this was going to happen, it would have happened when there was a massive boom in servers running Linux, over a decade ago now. Imagine the money to be made by being able to compromise everything running the LAMP stack.
Don't confuse your personal desktop for the entire world.
but hold on a min... most people wont be checking email, or surfing the web, or anything major on a server... its kind of silly to be doing stuff like that... but if everyone was using it as a desktop OS, and was browsing, checking email, etc, there is more of a chance to attack it... yes, i agree, attacking servers running everything, but its a bit harder... and how, exactly, would you get the virus on to a server anyway?
> how, exactly, would you get the virus on to a server anyway
The kind of server we're talking about is, by definition, on the Internet, accepting connections from arbitrary people. It's entirely possible for a connection or a family of connections to bring down the server software, which often provides a way to subvert the OS while the machine is in the unusual state of the userspace server software being down. This provides the avenue.
> if everyone was using it as a desktop OS, and was browsing, checking email, etc, there is more of a chance to attack it
I think this falls down, too: Linux has never been a single monoculture. Instead, there's been broad de fact standardization of some things but not others, making it more difficult to target malware to it, as malware is, very often, intimately dependent on not only specific software, but specific configurations of software and specific versions of software.
Also, Windows has never had a trusted source of software comparable to distro repositories. This is probably partially due to antitrust rulings, and the fact Windows caught on and had its first major flowering before Internet access was especially cheap or reliable (consolidating usage patterns around a non-Internet shrinkwrap software model). This means it's hard to get all the software you need from trusted sources unless you act like a distro maintainer and decide for yourself who in specific you trust. (You can do that in Linux, too, but you don't have to.)
Finally, Windows users complain about UAC. Linux users don't complain about sudo. Applications under Linux know they won't be run as root and behave accordingly.
The same (sorry to bite on stereotypes, but I've seen a few) clueless government contractors that did a poor job with windows will do as bad with Linux.
Then next year they will switch to openbsd (because all they trust is default settings) and repeat.
That said, yes having access to source is all fine to avoid vulnerabilities that a closed source product doesn't want to fix... but i doubt this is relevant when you add incompetence.
