There is one huge difference between the free and non-free software that has some very practical implications in the way we use it. One of those implications are the dependencies between single software packages in the free software model. What do they have to do with the free software philosophy and why should not you be afraid of them? Read on to find this out.

Author: Borys Musielak

What are these dependencies?

In short, a dependency means that one program (software package) needs another program for proper functioning. This situation is almost unknown for the Windows’ users since most Windows applications do not have such requirements (although this happens sometimes as well, e.g. in case of media players and codecs). In GNU/Linux it is common that software packages are not independant and need other libraries or tools to do their work. This sometimes leads to a so called dependency hell — a situation where one application needs a specific version of another application but the required version is not available in the system. The dependency problem is partly solved in most common distributions by introducing the software (package) managers. They are programs that take care of the installed software and try to resolve all the dependencies automatically by using the large software repositories together with the information provided by package maintainers.

Free software vs proprietary software

Putting it simple, we can divide the software into two large categories: free and non-free. Obviously, the reality is not black & white — there are hundreds of licences, some of them more “free” that others. However, for pragmatical reasons, we are going to assume that we only know these two major software models and focus on them for the moment to explain the major differences in the process of developing free and non-free software.

• Free software – this is the software that is free as in freedom, it is usually published on GPL-like or BSD-like licence. Users can get it for free from the Internet, and programmers can modify it and publish/redistribute their own versions thanks to the liberal licence and access to their source code. Examples: OpenOffice.org, Firefox, Linux kernel, OpenSSH, Eclipse and thousands of others.
• Proprietary software – the software owned by a single company which gives the user the right to… just use it. And even the plain usage is a subject to additional constraints. Examples: Microsoft Office, Photoshop, Opera, IntelliJ Idea and a lot of others.

The process of creating both types of software is very different and requires explanation, since it also reflects in the way you can use both categories of computer programs.

Process of creating non-free software

Closed-source non-free software is usually developed within a single software company. The whole code is developed from scratch, since non-free software cannot use the GPL-ed software by default. Thus, lots of effort is put into “reinventing the wheel”, that is reimplementing the tools that are already widely available on free licences. The good thing of such approach is that the closed-source software is often a monolith, it’s not built from external libraries and modules — the program is usually designed and built by one well-integrated team, so it should be more consistant and well-thought.

The downsides of such approach are: worse cooperation with external tools, slower developement process, inferior community feedback and bigger package size.

Cooperation with external tools

Due to the nature of closed-source programs, it’s much harder to write external applications that cooperate with such packages. The lack of source code usually comes with the lack of friendly API for external programmers and lack of documentation (there are exceptions to this rule of course).

Slower developement process

Since all the software components (even the simplest ones) need to be developed from scratch, the whole software development process is much (sometimes even a few times!) longer than the process of creating open source programs. The alternative is to use boxed closed-source componemnts purchased from another company or try using those open source components that are published on a very liberal licences (like BSD), which allows to others use it even in non-free software packages.

Inferior community feedback

Since the developement is performed within a commercial company, the potential users are not so interested in testing the software (this also has a few exceptions in case of very popular software and friendly providers). Thus, the whole testing phase needs to be performed using the company’s resources which both slowers the release process and decreses the quality at the same time (unless a considerable amount of resources is invested for testing only).

Bigger package size

The effect of bundling own libraries and tools in the software package, the size (in megabytes) of such package is usually way bigger than the size of typical open-source applications. In effect, the user gets lots of programs that contain the different implementations of the same basic features. The system gets bigger and bigger, the user loses control.

Process of creating free and open-source software

Free software is created in a very different manner. A group of programmers decide to start a project, usually with a goal to perform one single well-defined task. Next, another group of programmers, using the source-code of the first program, writes another program which extends it or just uses some functions provided by the first one. This way, the programs can take advantage of each other to build a more complex solution. Open source apps usually consist of many inter-dependant modules, each of them playing a certain role (implementing a certain function).
Sounds unclear? We have some examples, don’t worry.

Real life examples

• K3B and GnomeBaker – they are popular CD/DVD burning apps. But wait a second, they can’t even burn a single CD left all alone! What they do is they use another, third-party command-line tools like cdrecord or cdrdao to do the recording tasks and many others (like dvd+rw-tools, cdparanoia, etc) for additional features. The program is just a graphical frontend, a nice user interface for controlling the settings and simplifying the user experience.
• Firefox, SeaMonkey, Epiphany or Galleon – the web browsers that look different and provide different functionality, but they use the same engine for rendering web pages: Gecko. Without it, they would not be able to produce a singe readable web page!
• Kaffeine and Totem – great multimedia players for KDE and GNOME. What they do is only provide a container for certain multimedia engines (like xine or gstreamer). The frontends differ in looks but they use the same engines to play videos or music! Moreover, even those engines use other external programs, called codecs, for decoding the multimedia streams.

There are hundreds of similar examples in the GNU/Linux world. Practically any Linux program uses other applications for certain tasks. This is the actual reason for the dependencies. One app depends on other to perform its tasks, just because the programmers were smart enough (lazy enough) to use someone else’s work instead of reinventing the wheel for the 100th time.

Problems with dependencies

The dependencies have their bad sides, as well. It’s especially visible when a developer (or someone else responsible for packaging the software) does not define the dependant applications well (i.e. does not point the exact version(s) of external applications that should be used with the software). This may result in unmet dependencies when installing a program from a repository and lots of frustrations for the user to get the program to work.

There are two solutions to this problem:

• static packaging
• using a good package manager

Static packaging means that the software is packaged with all the dependencies. This makes it much larger in size and produces a situation when the users can have hundreds of versions of the same application installed in their system. Despite that, the static packaging approach is actually used in some operating systems, like PC-BSD since it eliminates the dependency problem completely.

The alternative to static packaging is using a fine package manager, a program which takes care of the dependencies of your software automatically when you install or upgrade some apps. The example of such program is Smart Package Manager. It can handle multiple package formats and multiple repositories and works fine in most popular GNU/Linux distributions. If configured properly, Smart can almost completely eliminate the side effects of using packages for software management. The alternatives to Smart are native package managers for each distribution, like APT, yum, urpmi, pacman and others.

Conclusions

OK, so.. what’s the message here? Should I drop all static packages now or just completely ignore the non-free software? Well… what we just explained is the diffrerent ways of managing software in your operating system, depending on the way the software is provided to you. In real life you will probably always need to use all of the described methods. However, I encourage to promote free software and good package management instread of proprietary apps and static packaging, since it just helps keeping your system clean and managable, something that is almost impossible for the Windows users currently.

Read more

• APT-HOWTO: Managing Packages in Debian GNU/Linux and derivatives
• SMART: Package Manager — review from Linux and Open Source Blog
• Building Binary PC-BSD Packages by Dru Lavigne