In some ways it is a fair question, you bought a license to play the game, but in reality it is not going to happen. Let me explain why.

When LGP ports a game, it takes time and money. We only get revenue back from people buying the Linux version. This means that if we were to say ’sure’ to that question, we would then suddenly get no revenue, as buying the windows version will earn us nothing.

We license games from companies who make the Windows version, and we do not get paid for making the games, and so selling them is the only revenue we receive. If, for example, you bought a game for Windows, you wouldn’t expect to be able to get a free copy of the same game for the Playstation. This is pretty standard for any industry. If you go pay to see a film at the cinema, you wouldn’t expect to get free pay-per-view access of the film on TV later on just because you paid money to the cinema.

We have had many people try and justify why they should have a free installer. We even had one bright spark take the demo for X2, hack the Windows datafiles into it, and then came asking for help wondering why he couldn’t save the game. The answer of course being ‘its a demo, its meant to not save the game’. Our demos are all written in such a way that they will not run the full version of the game.

Some Linux games, for example Quake 4, you get a downloadable installer because the same people who made the Windows version made the Linux version. They went to the expense and they recoup the money by selling the Windows boxed version. Other times, such as Unreal Tournament, where Loki released a downloadable installer for the Windows boxed version, the company who made the Linux version were paid to do so, and so the revenue is generated in that way. This is not the case with LGP games, and is unlikely to become so.

Of course, to leave things on an optimistic note, when Linux finally becomes the ruler of the desktop, then of course, Linux versions will be released first, and Windows gamers will end up in the shoes we Linux gamers currently wear. However, that will be a while coming, so until then, the answer is no. No installer!

A contradiction? Probably.

Now I am writing this from a personal perspective, on how I, as the CEO of the company, feels about this. If you don’t like what I say, don’t shun my poor devteam, who may often think differently.

Now, I love open source. I think it is vital, I think its is the best thing that has happened to computing since the invention of the silicon chip, but, it doesn’t answer all of the questions. I think that closed and open source have a place in the world.

My personal belief is that operating systems and file formats need to be open source. NEED to be. After that, looking logically, the rest of the computing world becomes a level playing field, and you can only become a dominant product by being best. You cannot lock people in if file formats are open, and operating systems are open.

Another fact is that programmers need to eat. Some very few developers are lucky enough to be able to make a living making open source software. But for most, that isn’t going to work. Programmers need to eat, need to support families and pay rent and occasionally buy a luxury or two. To do that they need to make money on their core skill, making software. This can be done in one of three ways:

1. Open Source Beg-ware. Spend ages making software, and hope to hell that people that use it feel generous enough, or guilty enough, to give you some money.
2. Open Source Supportware. Make great open source products and make money on supporting it.
3. Closed source, pay for it.

Looking at those options, well, beg-ware may make some people enough to live off of, but really, people as a whole just aren’t that nice. The natural instinct of a human is to get the most benefit for the least money. Some people will pay, not many though. Supportware is the common way of making money in open source. People pay for extra features or for support. Great. But hold on. This means that it is financially better for a developer to make a product that is hard to use, or lacking in features. Do we REALLY want that? Closed source makes you money, no doubt about it, but who knows what is going on. Really, any piece of closed source airline or medical equipment is always one semicolon away from crashing and killing whoever depends on it, and you would never know.

So by this example, there is no good option. Nothing works perfectly.

A lot of people these days refuse to use the closed source Nvidia and ATI graphics drivers, because they are closed source. I wonder, if the instructions were all hidden by hardwiring them into a ROM chip on the card, and the only part of the driver was some kind of instruction pipeline to the ROM, but that pipeline was open source, would that be any better? Fact is, it would be exactly the same situation as now, closed and hidden blobs of instructions, but without even the ability of the manufacturers to fix problems without a flash upgrade of some kind.

Because of course this is exactly what the open source drivers do, they talk to closed hardware. You are still dealing with proprietary systems. I expect that even RMS, in his infinite dedication to open sourcing (sorry, free-ing) everything, uses a computer that has hardware that has closed and hidden instructions. Is it any better that the instructions are hard wired into a chip? I doubt that a single modern computer in the world has a completely open specification with no hidden bits.

But this doesn’t really matter, I am not answering the question, I am just muddying the waters a little. Showing that the question is not as clear as it seems.

For most software, Open Source seems to be the way to go. In games however, it seems to be failing us. Why have so few open source games been created. I don’t mean one of several hundred tetris or breakout clones, I mean big games, of the scale of X3, or Cold War. I think the problem is creative goals. Open source, to attract volunteers, needs to be something that a developer WANTS to work on. And so a game must be the game that that developer has always wanted to play. And the problem with games, where making a game is mostly a creative process, is that everyone wants something different. And so most open source game projects fall apart, or just fade away.

You can see large numbers of small games for Linux. Games made by one or maybe two people. You can find a large number of clones of commercial games. These are all easy to find developers for, they all want to play the game they used to play, but on Linux.

But original, new, high quality games on Linux, well, there are less than a handful, and none of them would get shelf space in a commercial store They may be technically great, they may be a marvel of collaboration, but they probably wouldn’t sell copies to the random public, and those are the people that Linux needs to target to become more mainstream.

One idea is that commercial companies would make a game and release it with the source. That may be something for the future. People could fix the bugs, but to distribute it you must only distribute the official boxed copy. That way the game is open, maintainable, but the company still gets its money. Put it under a license that restricts use or modification for any other reason. Unfortunately, in reality I doubt it would work. People would abuse the license terms. Call me a cynic, but, I just don’t believe people would respect the license.

In the end, I believe in the best tool for the job, as long as the playing field is level. Firefox is doing a good job of getting to the top, by being better, assisted greatly by open standards. OpenOffice is making inroads by doing the same job as MS Office without charging. It would be doing a better job if all of the file formats used by MS office were open, and that is the biggest thing that is holding it back. A clear example of an un-level playing field preventing the better product winning because of lock-in.

As for games, I started in this industry cos I love Linux and I love gaming. I believe in open source (I’ve been writing and contributing to open source software since 1993), I just do not have confidence it can solve every problem. If open source obsoletes commercial gaming, I’ll be happy as anything cos I’ll get all my games for free, and I’ll be able to go get a job and earn money. Until then, commercial gaming is a vital thing for Linux, and does nothing but help push the platform forwards. Even if it is in a way that RMS doesn’t approve of {:-)

For years, LGP has been working with libraries such as SDL, ffmpeg, and others that are licensed under the LGPL (GNU Lesser General Public License). Without these invaluable tools from the open source community, LGP would not exist, and nor would hundreds of open source projects.

The LGPL states that an application that links against an LGPL library is not bound by the LGPL itself, but then goes on to qualify this, and make exceptions, and even itself states that the boundaries between what counts as simply linking against a library, and what counts as a derivative work, are ‘not precisely defined by law’.

The problem we have always faced is finding a way to make sure the game is portable. To do this you MUST make sure that you are using a known version of as many libraries as you possibly can. There is no point in exhaustively testing a game against SDL 1.2.12 when next week SDL 1.2.13 comes out, changes a few of our assumptions, and means the game crashes. Multiply the problem by the number of versions a library has, multiplied by the number of libraries a game links against, and you can see why this is a big problem. And so, we like to make sure we build the game, test the game, and run the game, all against exactly the same libraries as the end user will use, in as many cases as is possible.

Since the beginning of commercial Linux games, the common practice has been to create a release of each game such that there was a static and a dynamic linked version of the game in each release. The dynamic version of the game would be completely in compliance with the word and spirit of the LGPL, using the users own system libraries, while the static linked version of the game was released because linking the libraries directly into the game ensured we knew which libraries were being used. The statically linked executable though, was really not very much in the spirit of the LGPL. We always got away with it because we included the exact same game in full LGPL compliance,and because of the wording of the LGPL, it was fairly ambiguous as to whether this was allowed. But even so, we were never happy with it. Loopholes are not something to be proud of using.

There was another method of course. The other method involved forcing the game, via the LD_LIBRARY_PATH to use libraries in a certain directory. However that had issues of its own. To do this you either have to tell the user ‘before you start your game type this long command into the commandline’ or you start the game from a shellscript. Shellscripts are all well and good, but they bring problems of their own, such as (for security) making changes to the euid, resetting values from /etc/profile, and of course, assuming that the shell in use has exactly the same syntax as the shell at the time of release. It was decided that because of this, and many other issues, starting from a shellscript was too much of a risk for portability and was ruled out.

And so, we were left with the method that has been being used for the last 12 or so years. That is until recently, when we found a nice new way to fix this problem once and for all.

Most people are probably unaware of the linker option, -rpath. Most of you don’t ever need to be. This option lets you tell an application where to look for libraries. It works just like adding a new path into the LD_LIBRARY_PATH. Great, but it doesn’t really help like that. It is set at compile time and so we would need to restrict installation to a known directory on everyone’s machine. Obviously unacceptable for most users.

And so the problem remained until one of our devteam discovered a neat little trick that isn’t even documented in the manual for the linker. You can use a special keyword $ORIGIN to say ‘relative to the actual location of the executable’. Suddenly we found we could use -rpath $ORIGIN/lib and it worked. The game was loading the correct libraries, and so was stable and portable, but was also now completely in the spirit of the LGPL as well as the letter!

For those of you a little newer to compiling under Linux, some of you may not even be aware you use the ld linker. It is done automatically by gcc for you. If you are simply using gcc in a Makefile, it is a little more difficult in syntax, but as a hint you would change an example Makefile line that started like this

gcc obj1.o obj2.o -o my_application

to be

gcc -Wl,-rpath,\$$ORIGIN/lib/ obj1.o obj2.o -o my_application

So, that’s the neat little trick I thought I’d like to share with you, maybe it will help some of you out there to organise the way your projects run, as of course it isn’t just useful for closed source, this is useful for any project that has to use a specific library version in order to work properly!