So, there is this old debate in the open-source world. On one side, which we will call the “BSD side”, people argue that developers should provide the source code to their software, but not mandate anything from people who use it. On the other side, which we will call the “FSF side”, other people argue that software licenses should specify quite a few things about what should be done with that source code, with the aim of actively encouraging open source software proliferation and preventing selfish copy-paste of open-source code in proprietary projects. Starting this debate among techies can be considered a form of trolling, since it will trigger long heated discussions which will invariably end up in perfectly sterile disputes. And since I am well-versed in the art of trolling, I want to propose here for this OS project a third vision of open-source software, which can be considered intermediate between the two extremes above, and which I will argue is more useful in real-world situations.
I/ All software should be open-source
This first part may sound obvious to any advocate of open-source software, but I think it’s sometimes good to recall why it is the case instead of just religiously repeating the sentence :
- Open-source is more future-proof. If an open-source software becomes unmaintained, or if the authors start to act like a bunch of dicks, a new development team can take the lead of the project or fork it as needed.
- Open-source is not based on blind trust. Wonder if your Sony CD playback software contains a rootkit ? If it’s open-source, you can check the source and find out if there’s something suspicious. Want to use a library but not sure if the authors are going to maintain it forever ? If it’s open-source, there is the temporary option of forking it and maintaining it yourself for a while until you find a better one when disaster happens.
- Open-source encourages software innovation. People who learn programming always need example code, which they can easily find when the software they use daily is open-source. And if you find a flaw in an open-source software, you can easily patch it and contribute the result back to the development team instead of just sitting there and giving orders hoping that they will be followed shortly.
- Open-source encourages hardware innovation. Contrary to closed-source binaries which are always built with a specific hardware architecture in mind, open-source software can easily be altered and rebuilt in order to support new hardware as it comes out.
- Open-source encourages better code quality. While this is not a universal law, people tend to act in a more morally acceptable fashion when they feel that they are being watched. They may write cleaner code, spend more time making sure that no library does what they want before reinventing the wheel, optimize for performance instead of just expecting users to get better hardware, and so on. This results in turn in higher quality code, so better software in the users’ hands in the long run.
Now that this is stated, here comes the bummer part…
II/ This is not going to happen anytime soon
There are, and will always be, people out there who believe that distributing software without disclosing how it works is a smart thing to do. This is particularly true of professional developers. Here are some reasons why people would act this way :
- Fear of competitors. There are rational minds out there who understand that doing your best to release the best product is a more efficient way of doing business than doing your best to make your competitor’s product as bad as possible, and who acknowledge that doing so is also best for mankind in the end. And then there are these people. They are children afraid of shadows who have never grown up, and now happen to rule important companies.
- Laziness/Cost reduction. As said before, when you write open-source software, people can see your code and you can be held accountable for the crap you put in it. You have to spend more time taking care of your code if you do not want to receive well-deserved criticism. Some people simply don’t like that.
- User-hostile behaviour. Open-source as a cooperative software ecosystem tends to benefits users and other developers as a whole in the long run. Sometimes, that’s not the goal. As an example, DRM is a technology which creates artificial and annoying limitations on what users can do, and which would as such be quickly swapped out from a fork of the DRMd software. Some parts of the media industry are not yet ready to accept this outcome. More generally, any software that is designed to harm computer users, such as rootkits or trojan horses, does not benefit from being open source, since its harmful nature becomes more apparent to knowledgeable persons.
Now, people who act like this are sadly not only your humble Joe Coder in his basement. There are also actors of the closed-source market that matter. Major hardware manufacturers and software developers come to mind, especially in realms where no effort has been made to standardize widespread technology such as GPUs, network cards, or layered bitmap picture formats. If you are building a big OS, it is clear that you will want to deal with these people at some point.
III/ Thus we should favor open-source and tolerate proprietary stuff
The logical conclusion to statements I and II, in my opinion, is that any independent piece of software should receive a copyleft license like the GPL. These licenses basically tell developers “I share my code, but I expect you to do the same. If you want to benefit from using my code without helping others in return, just fuck off”. As such, they pragmatically encourage the spreading of the open-source ecosystem, since they offer benefits to open-source software and no benefit to closed-source software, giving the former a competitive advantage over the later and as such encouraging the later to switch to an open-source model.
Shared components and interfaces, such as system APIs, should however be built with more liberal licenses like the BSDs or the LGPL, in order to allow closed-source technology to exist. We have nothing to gain by actively preventing its existence and jailing ourselves in an open-source ghetto like Linux with its unstable ABI and the FSF with its GPLd shared components, since in today’s world proprietary tech is necessary to make computers work well. We have nothing to gain by making it advantageous to use it on the other hand, because we would then allow evil multinational companies to reap benefits from your code without giving anything back. So we choose to tolerate without helping, which seems the most sensible option for now. All interfaces are alike, so our evil multinationals won’t gain much from being able to use them without contributing anything back.
Conclusion : Closed-source stuff is dangerous, handle it with care
As we have seen, the ideal software ecosystem in this vision of computing is one where the existence of open-source software is encouraged, but that of closed-source software is tolerated as a legacy feature that happens to be frequently useful. The story does not end here, though.
As we have seen before, one of the major reasons why one would not want to distribute the source to some piece of software is because it behaves in some way that is harmful to users, providing an “anti-feature” that any sane developer would be eager to disable by forking the source. As OS developers who care about our users, we do not this kind of stuff to happen. So we want to mitigate the harm with closed-source software can possibly do to a user and his data.
This is why, as I have argued several times before, software sandboxing is a very important issue.
On nowadays’ desktop operating systems, all software comes, as a default, with the ability to perform the binary equivalent of a “rm -r ~/*”. To fully wipe a user’s data without warning. Overriding this default capability with safer settings is a difficult and error-prone process, and may frequently prove impossible to do without proper knowledge of how each soft works on the inside. With proprietary software, we do not have this luxury.
It gets even worse though. Most OSs also require that software installation be performed with a root privilege level, which means that anything can happen to your machine during the installation process. To be blunt, this is a security suicide as soon as the software’s installation process may be customized by the software distributor, as it means that you let untrusted software which you have not even run once yet do anything to your computer. Blind trust at its worst.
To restore a bit of sanity, one has to provide software developers with a compromise. The compromise is that they are not forced to disclose exactly what their software is doing, but must disclose what kind of harm it may do, and are allowed to provide an explanation of why it is the case. With this information in mind, users who have never run the software yet but roughly know what it is about are more able to make an informed choice, and notice anything suspicious. The effect of such policies is also much improved if the assumption that most software is harmless and does not require security warning holds true, so this is something which should be enforced in software development practices. Developers would also be rewarded for making harmless software by the absence of suspicious security warnings at install time, which is probably a good thing too.