“You can have freedom without choice.”

That someone could even come up with this one is just amazing to me. Note that this is not an exact quote, but it is the summary of Friday’s topic. For example, this summary comes from the idea that Canonical is bad for considering making mainstream non-free software available for Ubuntu based on user preferences. It does not matter who came up with it, of course, but the important thing is that it be called what it is: patently absurd. The ability to choose is a major part of what freedom—or liberty—is. If you cannot make a choice on a matter, then by definition you do not have freedom in the context of that matter. It is quite simple and self-explanatory. Canonical is seeking to increase freedom here, not take it away. Some people actually want to use non-free software; others may not want to use it, but aren’t aware of alternatives. The latter group of people should have our focus with regard to education (but then we should let them make the choice for themselves!).

Note that I am not one of these people: I would rather use free software because of the liberty it gives me that I have come to expect over the years. But I am not going to tell someone else that they are harming me because they would rather use non-free software that is familiar to them. All I can do is show them that there are free alternatives that exist. I cannot—and I will not—make them use it or make them feel bad for not using it. I may not like proprietary software for a variety of reasons, but I will defend people’s right to use it just as I will defend even a stupid person’s right to spew nonsense by way of speech or written word. In other words, “I disapprove of what you say, but I will defend to the death your right to say it,” or perhaps more appropriately, “I [may] disapprove of what [software you run], but I will defend to the death your right to [run] it.” Even I use a package or two that is proprietary in nature (though it is looking like I will not have to do so for much longer, given the efforts to replace these packages with equivalent free software).

It is worth it to note that by adding non-free software to Ubuntu, the free software that is already there does not change. The mere existence of non-free software within its repositories does not make Ubuntu somehow bad or evil. It would add choices that do not currently exist, and that one such as myself or yourself can certainly opt out of—I most likely would, for the most part, as I do not need to depend on non-free application software, and I only use non-free drivers if I have hardware where anything else is nonviable (and only until there are functional free software drivers). Did you know that Ubuntu has an option in the installer to only install free software? Can you say that for your favorite desktop operating system distribution, whatever that might be?

The response to this idea, then, is that without choice, there is very little—if any, really—freedom. The thing that gives us freedom with free software is that we are able to to download the source code, to review/audit it, to change it to fit our needs or fix a problem, and to share those changes. If we cannot do those things, then it is not free software; see the essential freedoms. But non-free software inside a distribution is not something that should not cause you great consternation even if you are among the most dedicated of freedom advocates, for if you are a true advocate of freedom then by definition you must respect a computer user’s freedom of choice. Remember that we choose to run free software because of the benefits it brings to us; we choose to improve upon free software for much the same reason. Eventually, I think that free software will once again become the norm for computer software, on merit alone, for no other reason than the development, release, and usage of free software is a highly practical solution for many things ranging from library code to application software to complete operating systems. It is worth noting that free content—which is similar in concept to free software, which itself is merely a specific application of freedom itself—also appears to making major headway towards becoming mainstream; it is doing so more quickly than free software is, but there is every reason to believe that free software will follow, for it is already.

An Example

Imagine that you are in a store, because you need some milk for dinner some night. You always get 1 gallon of 2%. But, the store has stopped carrying it, because more people buy whole milk and they were throwing away the 2% milk—demand was low, supply got to be too high, so they just stopped carrying it altogether. You leave the store and head to the next in the same town and you find the same thing there. You have a choice of stores to go to, and you have made the choice to go buy yourself some milk. But there is only one type of milk. You no longer have the choice to buy 2% where you are, and so effectively, your freedom to buy it has been taken away. (Of course, you can make 2% milk from whole milk (and make whole from 2% even, or even butter), but I suspect just as many people want to do that as want to write their own free software that they demand simply must exist, but doesn’t yet).

Now, the point here is that there is more than one freedom in play: the freedom of the store to stock (or not stock) various products, which affects your freedom as a consumer to buy the product you want. In the case of software, and choice, if the software you are running gives you all the choices you want, then it fits your needs. If it does not, then you are not going to be able to use it the way you want. Now you have two choices: you can do the work that it would take to make your desired choice possible, or you can use another system (free or proprietary) that will give you the choice that you want. Many people will choose the latter, especially if they are non-programmers. Though I’ve seen programmers also choose to use proprietary systems for something that they could themselves implement. That is their choice, of course. After all, if you really wanted 2% milk, you would have the same choice: make it yourself, or drive to the next town over which might have it available for you (assuming that there is some in stock and that the stores neighboring towns have not also decided to stop stocking 2% milk).

Ubuntu One: The Reason Behind This

This discussion came up because someone on identi.ca made the claim that Canonical is forcing proprietary software into Ubuntu by way of the Ubuntu One client software. I cannot even begin to state just how woefully incorrect this point of view is. First off: the only thing added to Ubuntu is the ability to connect to Ubuntu One, and the software that was added to Ubuntu do to that is licensed under Version 3 of the GNU General Public License. The claim made in response to that was that Ubuntu One is only partly free software, because the server is somewhere else and has not been released. As we shall soon see, that claim is nonsensical—it depends on an extremely naïve view of how software actually works in order to make sense, really.

So, first things first: Ubuntu One, which was added to Ubuntu 9.04, is not proprietary software. The proof rests in the fact that it GNU GPL v3.0, and we know a priori that software licensed under the GPL is free software, so we do not need to go further on that point.

Now, because the software in question added to Ubuntu is free software, we can read it. The essential freedoms granted to us by truly free software ensure this, and the GPLv3 is indeed a truly free software license because it grants those freedoms. Because we are able to study the software and see how it communicates with the server. Once we know how to communicate with the server, we can write that up and design a server that communicates exactly the same way. From there, it is just a matter of patching the sync dæmon that is in Ubuntu to talk to an arbitrary, Ubuntu One compatible server. To determine how to do that, one need only read the Python source code contained in the python-ubuntuone-storageprotocol and python-ubuntuone-client packages. If you do not know Python well, you might expect to spend several days doing that, but if it bothers you so tremendously that you are going to practically start a flame war over it, you may find it worth it to do so.

Of course, the other side to that is this: if you really want Ubuntu One to talk to an arbitrary server that runs free software, and you want that free software to be written, you can fund the effort to write the free software. Approach a proficient developer somewhere out there on the Internet and ask them how much they’d charge to write a server for Ubuntu One. You might not be able to afford the fund the project entirely, but if you get a number from someone, you can start a coordinated effort to raise the funds. If you are lucky enough to be able to fund the whole project, then do so: it is but one way that you can help provide something back to the community. This does not apply to just an implementation of the Ubuntu One protocol, it could apply to anything that you see that is missing and needs to be created. Or you could spend time learning what you need to learn to pick up the project yourself, if you care for the project that deeply. The most important attribute that a person can have in order to get started with development is motivation—James Westby reminded me of this a couple of years ago, something which I had forgotten.

Perceptions: Another (Possible) Reason

It was suggested to me that another possible reason that people would object to having non-free software inside an operating system distribution such as Ubuntu is that they are afraid that the proprietary options have higher quality, or offer superior features, or provide functionality that is not offered by any existing free software. Thus, they have this perception that by adding such non-free software into a distribution like Ubuntu, people will automatically use and prefer it over free software. This simply is not the case. Sure, some people will use iTunes if it is available on Ubuntu. Maybe many people would. I might even do so, if it were legally available for me to use that way and if it supports the purchase of DRM-free music. However, if there were a free software client for the iTunes store, I’d much prefer to use that. To my knowledge, however, there is no such thing that exists.

If there is not a free software alternative for a non-free component inside a distribution of software, if you are offended by that, then by all means, create a free software alternative for it! As mentioned above, you can start on such a project’s development, or you can look for people that would be interested in volunteering for it and coordinating them, or you can put up funds to pay developers to implement it. If you have money, this can be the easy part: find someone who is willing to accept payment for the service of implementing the free software alternative for whatever it is that someone else has funded, wrote, and released as proprietary software. It is not like free software is developed without cost (and if you think that it is, then you seriously do not understand what free software is or anything about the world of free software and have no standing to be getting mad when a company spends money writing software and does not release it as free software. You can try to write companies that write such software and ask them if they will give you any form of written specifications for the software, or an interface definition, or something along those lines. The worst thing that could happen is that you will be told “no”. And do so nicely, or they’ll be more inclined to tell you “bugger off” instead of simply “no”.

“Allowing users to choose proprietary software is anti-freedom.”

Nothing could be farther from the truth; it is the same, in fact, as the above statement that one can have freedom without choice. For example, if Ubuntu adopts iTunes and makes it so that you can “sudo aptitude install itunes” in the future, that is not a bad thing! How can it be—It contributes to the ability to choose, and thereby contributes to the freedom of the end-user. If you are a die-hard free software supporter and do not want to run non-free software on your system, then there is a very simple solution for you: simply don’t install it.  That is a valid solution to the problem. There are tools already available that can be run as a cron job and report on any non-free software that you might have accidentally (or even intentionally) installed. If you are worried about additional non-free software getting into Ubuntu, then help enhance those tools. Or write a GUI front-end for something like the virtual RMS program and work to get that included into Ubuntu as well, perhaps something that can run every time you login to the computer, or that runs as a persistent process that watches the package database on your distribution of choice for updates and then checks to see if newly installed software is non-free and alerts the user. Of course, it’d be most effective as an opt-in system, and not an opt-out one where it would just be annoying.

There is no way, then, that freedom is actually reduced in this way when another choice becomes available. If iTunes were to be included in the repositories (and I suspect it would be, like the restricted, universe and multiverse repositories, a separate opt-in repository; perhaps simply “proprietary” would be fitting), this does not reduce your ability to choose to run a free software media player and manager like Banshee, or Rhythmbox, or even AmaroK if you are so inclined to run that KDE stuff.

Once upon a time, FUD (fear, uncertainty, and doubt) was the tool of Microsoft. We (the free software world) completely hated it when Microsoft would put out FUD, because we would then have to fight that FUD by way of explanation and demonstration. Well, some time ago, a subgroup of the free software world decided to start using FUD themselves—it was done with Mono, and it is being done now with just a survey asking people what sort of software they would like to see in Ubuntu. Now, those of us who are left who are advocates of liberty—both personal and societal—are stuck potentially fighting two battles. One with Microsoft’s FUD—such as the constant notion that you have to pay for software—and one with the “free software evangelists” FUD, who have even gone so far as to say that people should not use certain types of free software (the one who calls himself “The Open Sourcer” even still today tells people to remove certain truly free software from their systems). The truth is somewhere in the middle, between these two ends of the spectrum.

Conclusion

Back to the point at hand: to say that giving a person a choice is a constraint on that person’s freedom, that is doublespeak.; it is saying that “slavery is freedom,” albeit to a lesser degree than that very melodramatic extreme—it simply does not make sense. The concept just does not make sense unless the words that are used to express the concept are dramatically redefined to mean things vastly different from what standard English dictionaries define them to be. The only reason that one has to try to convince someone that additional choice is a constraint on freedom is to try to convince people of things that are not true; to install fear, uncertainty, and doubt into people. This is the sort of behavior that—no matter what community it originates from—is completely immoral, unethical, and absolutely unacceptable. It’s dishonest, and for those of you who know me personally, you know what I think of dishonesty.

Why?

I’ve used AllTray for a long time. It is one of those pieces of software that performs a useful function, but you have to know its quirks to make it do what you want quite often, and you have to work around some of the things that it does for it to retain that usefulness. Users shouldn’t have to do that—they should just be able to start using a program or utility and have it work properly. Also, utilities should be (reasonably) independent of the environment that they run within, which AllTray isn’t. And, good utilities should integrate with the system pretty well, which AllTray does not, since it carries a hard dependency on GDK/GTK. (Kdocker is an alternative piece of software, and while I don’t know how well it works compared to AllTray, I know that it is bound to Qt, which is just as bad.)

The license will most likely be GPLv3, since nothing will actually link to it and it’s not a library. If there is a library component, it will be LGPLv3.

The actual “braindump”

The actual *docking* part isn’t terribly hard, it would seem. With GTK+ it can be done in only a few lines of code (especially in C#). However, C# wouldn’t be the language to use for the this tool, because of the dependency on Mono. My thinking is that the proper language to use would be C itself. It makes me think of how easy everything would be if only the desktop environment and all its software were already written in managed code… the effective cost of using C# would be significantly less than it is already.

Using C as the language isn’t that big a deal to me. What is a big deal to me is that the application be well-integrated and well-behaved. For example, AllTray depends on GTK for some of its tasks, and uses a custom (ugly, IMHO) widget for displaying its title when you over over it in the system tray. There’s another program out there, KDocker, that would appear to be slightly more featureful than AllTray, but it carries with it a dependency on Qt, which I don’t like. Ideally, the core for such a docking utility should be able to have various back-ends that serve the purpose of integration with the system, with a single back-end that would apply without dependencies on anything else for the rare scenario where neither GTK+ nor Qt are available.

What would this thing be required to do?

• Dock any arbitrary application to the system tray, not just a single window from the application. (Using the System Tray Protocol Specification)
• Run in a single instance, managing multiple applications within that instance if necessary.
• Provide session management for those who use it, and act as a session manager for applications that are run underneath it that support session management.
• Be able to use something like inotify to be able to show an indication of when the application’s title for its windows change.
• Use a single icon for the application, with a window list if the application carries more than a single window.
• Use individual backends which provide a native look and feel depending on the desktop environment currently in use.
• Use the application’s icon to represent the application in the system tray.
• Support blinking the icon when the application decides to do something like present a modal dialog box or something (if this is even possible, that much I am not quite sure of).
• Detect the desktop environment currently in use and (if possible) load a backend to integrate with it.
• Carry a dependency on GLib so as to make implementing it quicker and less error-prone.
• NOT carry any hard dependencies on any widget libraries like GTK+ or Qt.
• Return an error to the user if there is no running system tray, and there isn’t one after some sort of timeout (say, when starting the desktop environment, there may not be a system tray right away). (I don’t think that sort of situation would be commonplace, but it’s not really the job of this program to create a system tray if one doesn’t exist, since this is the job of the desktop environment.)

The backends would not have any specific configuration items (the entire configuration would be housed somewhere like ${HOME}/.config/docker, for example). There probably ought to be a backend entrypoint that would show a dialog for configuration, but I haven’t really figured out if that’d be the case yet. The docker should probably do all of its configuration by way of the command line for each invocation, which is suitable for use as a desktop shortcut or panel launcher.

This approach requires that each individual desktop environment have its own backend, which might become a bit of a pain for supporting a great number of desktop environments, but the upshot of that is that the application then feels native no matter what environment the user is using. Obviously support for GNOME and KDE would happen, and most everything else would depend on someone with programming experience for various environments to implement a backend for it.

The backend doesn’t handle, say, docking, since there’s a standard for that already. It would handle things like displaying the tip when hovered over or displaying a menu when right-clicked. So, the job that each backend would do would be pretty lightweight. And as much as possible should be handled in the core, with the backend consisting of just enough “hooks” into the target system to be able to provide a useful interface.

The way that this would have to work, using C as the programming language, would be that the core would have to use dlopen() and friends to load the backend and then use the entrypoints that the backend provides. Since dlopen, dlclose, dlsym, and dlerror are defined by POSIX.1-2001, support for those should be in every reasonably modern Unix-like system that supports at least a subset of POSIX. This of course eliminates Windows, but I am not terribly worried about that since there are probably other Windows-only utilities that serve this purpose.

The primary goal, then, is to replace other DE-dependent and toolkit-dependent dockers with a utility that carries the goal to be universally useful and highly robust. The aim of this goal is to replace AllTray entirely in (at the very least) Ubuntu, and hopefully be seen as useful in other distributions as well.

I’ll need some help…

This is the part where it’ll get interesting. I’ll need some help in actually doing this, in many areas.

For the moment, where I’ll need help (be that from Google, or from people in-the-know that happen upon this post) is to find all of the documentation that I’ll need to understand how to implement the software. I can use software that already exists to try to learn how the underlying system works, to a degree anyway. But some of the software doesn’t handle various situations correctly (or I don’t have a way to see if it does) and so studying them would be less than useful for everything I am trying to do. Namely, the things I need to find out yet are:

• How to run a program in such a way as to be able to reliably know what windows belong to the program and be able to dock them. I suspect that it’d involve using LD_PRELOAD and some monitoring trickery, but I would hope that there is some sort of API to do this already. Also, need to know how to manage the application itself; say it continues running but without any windows, the tray icon should obviously disappear while it’s running like that, until it has windows to manage again.
• How to perform session management and be a session manager for subordinate programs. (I might be able to study the source for KDocker to learn the answer to that, though I am not 100% certain yet of that.) I also have a paper to read yet on the subject that may have all the information that I am looking for, though I am not certain there yet, either.
• How to reliably detect the running desktop environment without resorting to ugly kludges and ad-hoc trickery.
• How to work independent of the currently-running window manager and operate reliably for any standards-compliant WM that is running, without having to special-case for various types of software or various types of window managers.

I suspect that there is useful documentation out there for most (if not all) of those things for X11 and other relevant points. I just haven’t found what I am looking for yet for all of it. Standards documents and system documentation are useful things to find, and maybe an example or two of source code on how to do it as well, are what I am looking for, so that I can try to understand these things better.

At some point down the road, I’ll need help with getting the backends written when they have an API to conform to. I can, in all probability, write a GTK+ backend that will work for XFCE and GNOME since I use GNOME. However, I don’t use KDE or anything that runs on top of Qt, so I will definitely need help from someone that is familiar with writing software for Qt to get a Qt backend written. If XFCE has any sort of non-standard special UI guidelines that are incompatible with GNOME, then I’ll need some help there, too. Any other non-GNOME or non-KDE environments (such as GNUstep, if it supports it anyway) that support the System Tray Protocol Specification will need backends written for them by people that are able to do so.

$ sudo apt-get build-dep libgtksourceview2.0-cil \
 libgecko2.0-cil libgtk2.0-cil libgnome2.0-cil mono \
 libgluezilla

The usage screen for the script:

Mono 2.0 Home Directory Installer

Copyright (c) 2008 M. Trausch <mike@trausch.us>
License: GPLv3

Total download: ~206 MiB, total installed size: ~161 MiB.
Download & build takes ~35 minutes on an AMD Phenom 9500 Quad-Core CPU w/ 8Mbps
downstream Internet connection (and happy servers, of course).

Logs are output to '/tmp/mono2-build.3044/log'.

usage: install-mono2.sh [options]

Available options:
  -s PKG
  --skip PKG	Skip building package PKG (one of libgdiplus, mono, mono-basic,
		gtk-sharp, gnome-sharp, gnome-desktop-sharp, gluezilla,
		monodoc, mono-tools, mono-addins, gecko-sharp,
		gtksourceview-sharp, heap-buddy, nant, monodevelop).  May
		be specified multiple times.

  -d
  --download-only
		Only download the packages, do not install them.

  -r
  --monodevelop-revision
		Specify which SVN revision of MonoDevelop trunk to install.
		Defaults to SVN HEAD.

  -S
  --skip-download
		Skip the download (if you're rebuilding, use this to
		save bandwidth.

  -m
  --monodevelop	Download, build, and install MonoDevelop only.  ONLY USEFUL
		FOR UPDATING MONODEVELOP AFTER YOU'VE RUN THIS SCRIPT TO
		INSTALL MONO 2.0.

  -1
  --single-cpu	Use ONLY single CPU/core for building.  Use this if you have
		trouble building and think it might be related to 'make -j'.

Now, when this script runs, it will download the Mono files (and MonoDevelop from SVN) into /tmp/monosrc. It will do the build in /tmp/mono2-build.XXXXX where XXXXX is the process ID number of the install-mono2.sh script. When you’re finished and happy with the installation, you can safely remove those directories:

$ rm -Rf /tmp/mono2-build.* /tmp/monosrc

If you want to track MonoDevelop within SVN, then it is better to not delete /tmp/monosrc, because the script uses svn to pull from the MonoDevelop Subversion repository. This means that it can, if the directory already exists, save you bandwidth by only pulling a delta from the revision that you have and the current HEAD revision. The astute probably noticed that you can select a revision explicitly as well. I am currently using r115695, and have used it for a grand total of 20 minutes (and debugging, as best as I can tell, works quite wonderfully in it, but it is a work-in-progress, coming directly from the development mainline). In short, the MonoDevelop is great for toying with but not for production use. I may release a version of this script that lets you choose between the latest stable released version of MonoDevelop and an SVN revision, but I haven’t gotten there yet because I wanted to play with the SVN version (which uses features in Mono 2.0… that was the whole point of me wanting to play with Mono 2.0, actually).

In any case, the script is available for download here from my Web site.

A few words about the script: This script is released under the terms of the GNU General Public License, Version 3. It is version 3 ONLY. There is NO SUPPORT for this software; I wrote it for myself, and it may change or it may stagnate. I provide it in the hope that it is useful to someone out there other than myself, but it is AS-IS, WITHOUT WARRANTY, UNSUPPORTED software. If it changes your dog’s gender, bursts your house into flames, destroys your whatchamacallermicroflobbermajag, do not come and yell at me. That having been said, I welcome any modifications (at least to view them). You can modify it for your own use, you can share it (in fact I expect you to!) and you can tinker with and tweak it. Suggestions? Welcome! Comments? Welcome! Flames? Hey, free speech is your right…

Lastly, I RECOMMEND THAT YOU RUN THE SCRIPT ON A CLEAN USER ACCOUNT, WITHOUT YOUR DATA, WITHOUT YOUR ANYTHING IN THE WAY. Just create yourself another user, and login to it using Xnest or something, or log out of your user account completely—I don’t care how you do it. Why do I make this recommendation? Because while nothing bad should happen, it’s always best to sandbox things that you don’t trust. After all, what reason do you have to trust me if you don’t know me? You can also of course read through the script and audit it if you wish. It doesn’t handle EVERY exceptional condition, but it handles just about anything that needs to be and tells you where things went awry if they go wrong. And it logs everything (see the program output when you run it). It also takes advantage of multiple processors or cores if you have them for those (few) builds that will permit it without going nutso, but YMMV. If you have an issue with this aspect of the script, see the usage text. If there are any issues that you can’t solve with that, or installing build-dependencies, then paste the relevant segments of your failing log file to something like pastebin and ping me a comment here, and I can take a look at it and (try to) offer advice, depending on where the fail is.

Oh, yeah, and I used a hell of a lot of bandwidth putting it together and making sure that it did things like downloaded things right and all of that. Sorry for hitting your servers repeatedly, Mono people—and thank you for the software!

First off, if you are a developer (open source, closed source, doesn’t matter), you need to know the area of licensing. You should actually have read, studied, and understood at least the most popular licenses out there, so that you know what you can (and cannot) do when you link with code that uses those licenses.

Secondly, JavaScript code runs on the client, not the server, and cannot link to the server’s code. This also means that a JavaScript framework can be licensed under the GPL, and you have no requirement to release the source code to the back-end processing code. When you design a Web application, there are two components to it: The front-end and the back-end. These can be further subdivided a bit, if you were to employ the use of the MVC architecture for your application. However, no matter how sloppy you write it, there are two distinct components: The front-end and the back-end. That’s it.

Now, these are logically speaking two separate programs. They may work cooperatively, but think about it like this: The Web browser is a framework for zero-install client application software, which uses a network connection to talk to server application software. The front-end code, logically speaking, can be used on different back-end servers, too. It doesn’t have to be only for the backend it was designed for, nor does anything stop the backend from talking to a third party client application that isn’t in a Web browser.

Think about it this way for a minute: Amazon’s S3 service publishes only an API. You must write a front-end to sit on top of it. Your front-end being GPL’d will not force Amazon to open up S3, no matter what. It’s clearly separated.

So, think about those licenses and their interactions and do not spread FUD when you do not understand the interactions that are there. If you cannot distinguish between the front-end and back-end of a Web application by looking a working copy of it, you should probably consider learning more before you continue to write software. Writing software is a construction activity and does require real knowledge and experience, as well as the ability to think critically about problems—and a few minutes of critical thinking would save a lot of people from reading ranty, panicy posts on things like licensing issues. (This is also why management, unless they are technical-minded, really should not be making technical decisions, but that’s another post for another time.)

Not that I was terribly worried myself, anyway.

Of course, with Novell owning the rights to Unix, there is the entire question of what they’ll do with that. Hopefully, they won’t be influenced by their “partnership” with Microsoft to use the Unix source code rights to do evil things, like try to trash Linux more with it. I should think that would not be in their best interests, anyway, since they themselves distribute a distribution of GNU/Linux systems. That does bring up an interesting point, though: if Novell owns the rights to Unix, perhaps it is in Linus Torvalds’ best interests to gather up all the contributors and get them to relicense their code under the GPLv3. Ditch the code written by people that cannot make the decision to move to GPLv3 for one reason or another (there are many people that have contributed to the Linux kernel under the terms of the GPLv2, for example, that are no longer living), and rewrite code with similar or identical functionality to be released under the terms of the GPLv3.

I think that things would be far better for the Linux kernel if Linus would’ve required that all copyright ownership be transferred to him if he accepted the code for inclusion in the kernel. That would avoid the large licensing mess, no matter what happened. Though, it would also require that there be a large amount of trust be placed in Torvalds’ for always doing The Right Thing™. I should think that he would, but who knows—there are many people and businesses in the world that have similar trust placed in them and they seem to not care about doing the wrong things to the wrong people. Two examples that come to mind are Brad Fitzpatrick and Six Apart, but of course those are just recent examples.

Version three of the GNU GPL license is released and now available after much revision. It is a good license, and I watched the streaming Ogg netcast of RMS announcing the release (or as much of it as I could—they were using a 700kbps stream, which is big as far as streams go; and 500kbps was sound). Today is a great day for the free software world, and for freedom in computing.

This is a good thing, because it lets people who like to modify things like their routers, set-top boxes, and more to tweak them and make them behave the way that they want them to behave—much like people who run Ubuntu or other GNU/Linux distributions can do the same with their systems. Some hardware already allows this to happen (in the spirit of the GPLv2, but the situation wasn’t something that was thought about when the GPLv2 came out so the letter doesn’t specify it). Others, though, make the devices shut down if they detect modified firmware or software on them.

It also addresses some of the issues of DRM and how they are affected by the GPLv3. Patent deals, such as the one made by Microsoft with Novell regarding open-source and free software, are also addressed. The good news is that the GPLv3 is going to be a great license to write software under, because if it is used for all the currently-existing GPLv2 software, it will make fair competition possible in today’s quite anti-competitive software world. Here is the mail from RMS:

Version 3 of the GNU General Public License will soon be finished,
enabling free software packages to upgrade from GPL version 2. This
article explains why upgrading the license is important.

First of all, it is important to note that upgrading is a choice. GPL
version 2 will remain a valid license, and no disaster will happen if
some programs remain under GPLv2 while others advance to GPLv3. These
two licenses are incompatible, but that isn’t a serious problem.

When we say that GPLv2 and GPLv3 are incompatible, it means there is
no legal way to combine code under GPLv2 with code under GPLv3 in a
single program. This is because both GPLv2 and GPLv3 are copyleft
licenses: each of them says, “If you include code under this license
in a larger program, the larger program must be under this license
too.” There is no way to make them compatible. We could add a
GPLv2-compatibility clause to GPLv3, but it wouldn’t do the job,
because GPLv2 would need a similar clause.

Fortunately, license incompatibility only matters when you want to
link, merge or combine code from two different programs into a single
program. There is no problem in having GPLv3-covered and
GPLv2-covered programs side by side in an operating system. For
instance, the TeX license and the Apache license are incompatible with
GPLv2, but that doesn’t stop us from running TeX and Apache in the
same system with Linux, Bash and GCC. This is because they are all
separate programs. Likewise, if Bash and GCC move to GPLv3, while
Linux remains under GPLv2, there is no conflict.

Keeping a program under GPLv2 won’t create problems. The reason to
migrate is because of the existing problems which GPLv3 will address.

One major danger that GPLv3 will block is tivoization. Tivoization
means computers (called “appliances”) contain GPL-covered software
that you can’t change, because the appliance shuts down if it detects
modified software. The usual motive for tivoization is that the
software has features the manufacturer thinks lots of people won’t
like. The manufacturers of these computers take advantage of the
freedom that free software provides, but they don’t let you do
likewise.

Some argue that competition between appliances in a free market should
suffice to keep nasty features to a low level. Perhaps competition
alone would avoid arbitrary, pointless misfeatures like “Must shut
down between 1pm and 5pm every Tuesday”, but even so, a choice of
masters isn’t freedom. Freedom means _you_ control what your software
does, not merely that you can beg or threaten someone else who decides
for you.

In the crucial area of Digital Restrictions Management–nasty features
designed to restrict your use of the data in your
computer–competition is no help, because relevant competition is
forbidden. Under the Digital Millenuium Copyright Act and similar
laws, it is illegal, in the US and many other countries, to distribute
DVD players unless they restrict the user according to the official
rules of the DVD conspiracy (its web site is http://www.dvdcca.org/,
but the rules do not seem to be published there). The public can’t
reject DRM by buying non-DRM players, because none are available. No
matter how many products you can choose from, they all have equivalent
digital handcuffs.

GPLv3 ensures you are free to remove the handcuffs. It doesn’t forbid
DRM, or any kind of feature. It places no limits on the substantive
functionality you can add to a program, or remove from it. Rather, it
makes sure that you are just as free to remove nasty features as the
distributor of your copy was to add them. Tivoization is the way they
deny you that freedom; to protect your freedom, GPLv3 forbids
tivoization.

The ban on tivoization applies to any product whose use by consumers,
even occasionally, is to be expected. GPLv3 tolerates tivoization
only for products that are almost exclusively meant for businesses and
organizations. (The latest draft of GPLv3 states this criterion
explicitly.)

Another threat that GPLv3 resists is that of patent deals like the
Novell-Microsoft deal. Microsoft wants to use its thousands of
patents to make GNU/Linux users pay Microsoft for the privilege, and
made this deal to try to get that. The deal offers Novell’s customers
rather limited protection from Microsoft patents.

Microsoft made a few mistakes in the Novell-Microsoft deal, and GPLv3
is designed to turn them against Microsoft, extending that limited
patent protection to the whole community. In order to take advantage
of this, programs need to use GPLv3.

Microsoft’s lawyers are not stupid, and next time they may manage to
avoid those mistakes. GPLv3 therefore says they don’t get a “next
time”. Releasing a program under GPL version 3 protects it from
Microsoft’s future attempts to make redistributors collect Microsoft
royalties from the program’s users.

GPLv3 also provides for explicit patent protection of the users from
the program’s contributors and redistributors. With GPLv2, users rely
on an implicit patent license to make sure that the company which
provided them a copy won’t sue them, or the people they redistribute
copies to, for patent infringement.

The explicit patent license in GPLv3 does not go as far as we might
have liked. Ideally, we would make everyone who redistributes
GPL-covered code surrender all software patents, along with everyone
who does not redistribute GPL-covered code. Software patents are a
vicious and absurd system that puts all software developers in danger
of being sued by companies they have never heard of, as well as by all
the megacorporations in the field. Large programs typically combine
thousands of ideas, so it is no surprise if they implement ideas
covered by hundreds of patents. Megacorporations collect thousands of
patents, and use those patents to bully smaller developers. Patents
already obstruct free software development.

The only way to make software development safe is to abolish software
patents, and we aim to achieve this some day. But we cannot do this
through a software license. Any program, free or not, can be killed
by a software patent in the hands of an unrelated party, and the
program’s license cannot prevent that. Only court decisions or
changes in patent law can make software development safe from patents.
If we tried to do this with GPLv3, it would fail.

Therefore, GPLv3 seeks to limit and channel the danger. In
particular, we have tried to save free software from a fate worse than
death: to be made effectively proprietary, through patents. The
explicit patent license of GPLv3 makes sure companies that use the GPL
to give users the four freedoms cannot turn around and use their
patents to tell some users “That doesn’t include you.” It also stops
them from colluding with other patent holders to do this.

Further advantages of GPLv3 include better internationalization,
gentler termination, support for BitTorrent, and compatibility with
the Apache license. (For full information, see gplv3.fsf.org.) All
in all, plenty of reason to upgrade.

Change is unlikely to cease once GPLv3 is released. If new threats to
users’ freedom develop, we will have to develop GPL version 4. It is
important to make sure that programs will have no trouble upgrading to
GPLv4 when the time comes.

One way to do this is to release a program under “GPL version 3 or any
later version”. Another way is for all the contributors to a program
to state a proxy who can decide on upgrading to future GPL versions.
The third way is for all the contributors to assign copyright to one
designated copyright holder, who will be in a position to upgrade the
license version. One way or another, programs should provide this
flexibility for the future.

Copyright © 2007 Richard Stallman
Verbatim copying and distribution of this entire article are permitted
worldwide without royalty in any medium provided this notice is preserved.

I have omitted the last call draft of the GPLv3, which can be found online. (This essay is also up on their web site at that link, actually, but I decided that it was more interesting to post it here as well).