Please note that I am not a lawyer and this is not legal advice.

The standard boilerplate text that the FSF provides (here [gnu.org], for reference, under the “How to Apply These Terms to Your New Programs” section) includes the clause “or (at your option) any later version.” I believe this clause to be dangerous to apply to any sort of project.

First, let’s examine the benefits. The FSF (rarely, admittedly) releases new versions of their licenses from time to time. Because of the nature of their licenses (strong copyleft), new versions are generally incompatible with older ones. This is because the licenses don’t allow you to add more restrictions past what they already do, and the newer licenses normally do (anti-tivoization in the GPLv3, etc.), which isn’t necessarily a bad thing. By having the “any later version” clause, developers that wish to use your code along with code under a newer license are able to do so, because they can take the “any later version” option, and effectively re-license your project under the new license. Keeping licenses compatible is generally considered a Good Thing.

That being said, there is one huge downside. By having such a clause, any newer version of whatever license you use is automatically usable with your project. Most programmers don’t intentionally place backdoors in their programs (the white hat programmers, anyway). If you use the “any later version” clause, though, you’re giving the FSF a backdoor into your project’s license.

Worse yet, the FSF has already used this clause to do something against the spirit of the license. Wikipedia was relicensed some time ago from the GFDL [gnu.org] to the CC BY-SA 3.0 [creativecommons.org] license. Here’s the short story: Wikipedia voted to move from the GFDL to the BY-SA. The caveat was that they’d have to get the approval from every person that contributed to Wikipedia. Obviously, that’s pretty unpractical. The only other option would be rewriting everything from scratch under an explicit BY-SA license. Again, rewriting all of Wikipedia is pretty unpractical. The Wikimedia Foundation (the organization that runs Wikipedia) convinced the FSF to let them re-license to BY-SA. Hopefully, this article’s title alone should tell you how they did it. The GFDL 1.2 was released, with the addition of the “RELICENSING” section. If you wish, you can click on the GFDL link above, and search for “relicensing” to see the terms for yourself. They gave Wikipedia (actually, any public wiki or any wiki-like site) permission to relicense everything under the BY-SA for a limited window of time. I haven’t heard of any other sites using this to relicense, but it certainly is far from impossible. By doing this, the FSF used a backdoor to carry out the wishes of the Wikimedia Foundation. If you consider Wikimedia getting what it wanted (relicensing to the BY-SA) to be good, this is a good outcome. However, what of the writers? Perhaps (given the sheer number of them, no doubt) some of them actively did not want the content relicensed to the BY-SA. There was a reasonable expectation that by contributing to a GFDL project (without copyright assignment) that their contribution would stay GFDL.

Actually, the relicensing affected people that weren’t even a contributor to Wikipedia. Before the license change, Wikipedia was legally permitted to (and did) pull content from other sources that were licensed under the GFDL and add it to its own pool of content. Just by having your content added to Wikipedia, whatever was added to Wikipedia at any point before the license change is now permanently available under BY-SA. (If the content was added after the license change, it was already BY-SA, or a copyright violation.) Because the BY-SA is a non-revocable license (as it should be), people can pull content from any point in the past and use it under the BY-SA. Any content at all is now free game.

The exact same problem can happen with software projects. If a project is allowed to relicense to something else, and they incorporated part of another project’s code, that project now has effectively released some (or all, depending on how much was incorporated) of its code under a license that they never chose against their will. No one else has that power. Even if Linus Torvalds wanted to, he couldn’t license the Linux kernel under the GPLv3. Most contributions are GPLv2 only, meaning they can’t be incorporated in a GPLv3 work. This gives the FSF an unprecedented, and completely unreasonable, amount of power over any project’s licensing that uses the “any later version” clause.

It could be worse, though. Even if you use the “any later version” clause, anyone is still able to use your project under any version of the license newer than, or equal to, the original license. So if your project is GPLv3 or newer, and the GPLv4 says “you cannot use this software ever” (doubtful, but the point is clear) then people can still use your software under the GPLv4. Of course, if there’s something else in the GPLv4 that you don’t agree with, there’s no out for you. Anyone in the world is welcome to use your project under the GPLv4. Possibly the worst-case scenario is a version of the GPL being released that is equivalent to a BSD-style license. Granted, Stallman most likely would never let that happen, but he won’t be around forever. There is another very frightening possibility, though. Humans make mistakes (even lawyers!) and the FSF is no exception. A newer version of the GPL could accidentally slip in something nasty, that gets abused by some other lawyers to do something that no one intended. Even if you fully trust the FSF, even enough to give them complete control over your project, it’s still possible for them to make a mistake, and if they do, I have no doubt that someone somewhere out there will abuse it to go against the spirit of the GPL.

There is one bright side to all of this, though. Not a single bit of it has been tested in court. If something bad does get into a GPL release, it’s entirely possible that the courts would throw it out based on intent. To the best of my knowledge, the “any later version” clause itself has never been tested in court. (If I’m wrong on this, please feel free to point me to a case where it has been tested.) For all we know, the clause itself wouldn’t hold up to judicial scrutiny. Even with the possibility of the court throwing either the clause or a hypothetical newer license out, why take the chance? Most people that use the GPL do it, either directly  or indirectly, to make sure the time they sunk into their project doesn’t go to waste by some entity taking their code, making it proprietary, and contributing nothing in return. Why risk having all that work undone because a new version of the GPL has something nasty in it?

The one other thing that disturbs me that I haven’t yet mentioned (and I only will briefly) is that it goes against The Open Source Definition [opensource.org], specifically “No Discrimination Against Persons or Groups.” The relicensing section of the GFDL only applies to what they call an “MMC Site” (Massive Multiauthor Collaboration), which is a fancy way of saying wiki. If I had incorporated GFDL content on this blog, I would not be free to relicense it under the BY-SA. While they didn’t specifically mention Wikipedia or the Wikimedia Foundation, they absolutely did discriminate against a group of people: everyone that’s not using a wiki. Why this blatant discrimination was never touched upon is beyond me.

tl;dr The “any later version” clause gives the creator of the license a licensing backdoor that lets them do whatever they want to your project’s license (including relicensing it under something else entirely).

Thanks for reading,
dririan

This is a table for the different masks you can use:

Once you know what mask you need to use, run boot0cfg -m $MASK /dev/$DISK, replacing $MASK with the mask in the table above, and $DISK with the disk you want to configure. The disk should be the disk, not a partition (for example, /dev/ada0 instead of /dev/ada0s1). In our example above, the command would be boot0cfg -m 0x5 /dev/ada0. The next time you reboot, you should only see the enabled partitions. The mask won’t, however, force a partition boot0 wouldn’t normally show to be shown. It is only capable of disabling partitions that boot0 normally shows.

An important note: you cannot boot from disabled partitions, at all! Trying to hit the key for a disabled partition just results in boot0 printing # and waiting for another key to be pressed.

The first step, of course, is to install mod_macro. Both Debian and Ubuntu include mod_macro as libapache2-mod-macro, so it’s just an apt-get install libapache2-mod-macro away. It’s also included in Gentoo as www-apache/mod_macro.

Next, make sure you enable mod_macro in your Apache configuration. This part is distro dependent as well. On Debian and Ubuntu, run a2enmod macro. In Gentoo, add -DMACRO to Apache’s command-line options in /etc/conf.d/apache.

Once mod_macro is enabled, you can define your own macros. For the sake of brevity, I won’t be telling you where to put these configuration snippets. In Debian/Ubuntu I use /etc/apache2/sites-available/{macros,vhosts} to define my macros and use them, respectively, and symlink them to /etc/apache2/sites-enabled/{000-macros,010-vhosts} respectively.

Macros are defined in Macro blocks, for example:

<Macro MacroName $arg1 $arg2>
    SomeStatement $arg1
    SomeOtherStatement $arg2
</Macro>

You can then use the macro with Use MacroName foo bar, which would be equivalent to:

SomeStatement foo
SomeOtherStatement bar

It’s important to note that mod_macro doesn’t actually write the expanded macros to a file. The expansions will only be seen by Apache itself, though you can use mod_info [httpd.apache.org] to dump the configuration, which will show you the expanded macros.

A naive implementation of HTTP and HTTPS virtual hosts would use duplicated configuration, such as:

<Macro HTTPandHTTPSMacro $name>
    <VirtualHost *:80>
        ServerName $name
    </VirtualHost>
    <VirtualHost *:443>
        ServerName $name
    </VirtualHost>
</Macro>

Obviously, that’s an over-simplified example. The difference is much more pronounced in real-world configurations. On my servers, I use a uniform layout, where the document root is /srv/www/$host/htdocs, the HTTPS private key is /etc/ssl/private/$host.key, and the HTTPS public key is /etc/ssl/private/$host.crt. You can nest macros and insert them in other contexts, so my macros look like this:

<Macro PHPVHostMixin $host>
    ServerName $host
    DocumentRoot /srv/www/$host/htdocs

    AddHandler application/x-httpd-php5 .php

    <Directory /srv/www/$host/htdocs>
        Order allow,deny
        Allow from all
        AllowOverride All
    </Directory>
</Macro>
<Macro PHPVHost $host>
    <VirtualHost *:80>
        Use PHPVHostMixin $host
    </VirtualHost>
    <VirtualHost *:443>
        Use PHPVHostMixin $host

        SSLEngine On
        SSLCertificateFile    /etc/ssl/private/$host.crt
	SSLCertificateKeyFile /etc/ssl/private/$host.key
    </VirtualHost>
</Macro>

Once you get your macros set up, you can just add Use PHPVHost dririan.com to your configuration file to add a new virtual host! While there may be more work initially, if you ever have to change your configuration, things will be much easier. Editing all PHP virtual hosts in Cherokee means logging into cherokee-admin and manually tweaking every single virtual host. With mod_macro, you can tweak the macro and every virtual host will be updated with it. As usual, any changes to your macros requires you to reload Apache’s configuration.

If you have any questions or comments about using mod_macro, please post a comment below.

Thanks for reading,
dririan

More over, there haven’t been any commits in the master branch of Cherokee’s source in over six months. The creator of Cherokee posted on the mailing list a week ago that he’s working on a totally new version, because most of the core code is being written to be more compatible with protocols like SPDY, and to fix “a few long standing SSL bugs.” Unfortunately, with no release (or even commits) at all being made in six months and with several fairly large bugs, I cannot continue to run Cherokee. Part of what I loved about Cherokee (aside from the gorgeous web administration interface) was the agility behind it: new versions with new features and bug fixes were released constantly. It felt much like Chrome does, including that serious bugs are very rare, and are usually patched out extremely quickly. The only serious bug I ever encountered with Cherokee was the HTTPS POST bug, which was technically only triggered by a change in Chrome, despite the former rapid releases.

So for these reasons, I have switched all of my web servers back to Apache from Cherokee. Personally, I probably won’t be switching back yet again once the new Cherokee with the rewritten core is released, but I know I won’t be recommending Cherokee for new servers at least until the new version is released, and even then probably not for heavy production use. The complete lack of communication (up until a couple of emails explaining the situation last week) makes me wary to use or recommend Cherokee in production.

Hopefully, if you have an Android phone, you’ve seen permissions in action before. Android uses them to tell you what an app can do (and nothing else). This system is great; it lets you easily tell if a random game you downloaded wants to read your contacts for some reason (hint: it’s probably bad) The Gmail app for Android uses permissions to control which apps can read or write emails through Gmail. This is excellent, as I don’t want some random app reading all my email. However, if I trusted an app with access to my email, apps could access your inbox through the READ_GMAIL permission. (It was shown as “Your messages > read Gmail” in an app’s permission list.)

All was well in the Android world, as apps could freely use Gmail. Then, Google pushed an update to Gmail, which made READ_GMAIL only available to other Google apps. (For developers, the attribute android:protectionLevel="signature" was set in the manifest on the permission, and the ContentProvider requires the permission.) This caused half of the apps that used Gmail to outright crash (force close), and the other half to just fail. Google said that the apps that just failed were “designed properly”, because they do checks to make sure they have clearance to do what they want to do. In my opinion, while I believe that apps should gracefully degrade (some custom ROMs let you enable/disable individual apps, but stock Android makes you either install the app and accept all permissions, or don’t install it and accept none), no one actually does, including Google’s own examples.

As of now, there is no alternative or workaround to the problem. The absolute best an app can do is get notified when there is email, and how many unread messages there are. No more information can be obtained, such as the sender, subject, or body. Since there is no useful information to extract, RDD cannot support Gmail in its present state. There is a seriously hackish workaround for those that are desperate, however. You can pull the account username and password (which requires a few permissions of its own, including a few nasty ones that I wouldn’t give to any app I don’t absolutely trust) and use Gmail’s IMAP servers directly, just like the mail client you use on your computer (if you use one) does and monitor it independently from the Gmail app. Aside from all the extra effort (and permissions) this would require, there are two things that prevent me from doing so in RDD.

First, a big goal of mine is to avoid, at all costs, the INTERNET permission. Part of this is based on my own process for deciding if I’m going to install an app or not. If an app requests the INTERNET permission, the first thing I do is ask “Why does this app need Internet access?” and RingyDingyDingy somewhat fails that test. I’d be willing to give an app that I can trigger remotely INTERNET access, but it’s the next step in my process that RDD would get dropped. I look extra carefully at all of the permissions, and evaluate if I want that exposed to the Internet. RDD has four permissions right now: reading text messages (used to know when to ring or lock), the counterpart for Google Voice, sending text messages (used to respond to text messages giving confirmation or a reason why the command wasn’t completed), and reading contacts (used to look up someone’s name when a remote ring is triggered). An app that has those four permissions as well as INTERNET gets dropped immediately unless I completely trust the author.

Second, this would massively inflate the size of RDD. Because there’s built-in apps for e-mail, there is no IMAP/POP3 library in Android. All of the code to access Gmail’s servers would either need to be written by hand (a huge pain), or to be pulled from a library (most of which are huge). Right now, RDD manages to squeeze by in less than 64k, which it should. Pulling an IMAP library would make it in the megabyte range, so that won’t be happening unless absolutely critical.

Because Google Voice lets apps read incoming text messages (which it should, especially considering Android lets you do the same with plain text messages), there is now a working solution for triggering RDD on devices that aren’t a cellphone. Unless Gmail lets other apps access the mailbox, Gmail integration will not be coming to RDD.

Google’s own support forum is filled with developers having the same problem in this thread [google.com].

That being said, you can grab it from the Android Market here [market.android.com], and the Google Code page is here [code.google.com]. If you don't have access to the Market, you can also grab the APK from the Google Code page.

Finally, I'll be posting more here over the next few days about what I've learned on the way to RDD 0.5.

So in this post, I’ll be explaining how to use mercurial-server to host your repositories, while also having them publicly browsable and pullable with hgweb. I’ll also be demonstrating how to hide repositories from hgweb, while still keeping them working with mercurial-server.

First, I assume you have a working mercurial-server set up. If you do not, the documentation for it is available here [dev.lshift.net].

To have hgweb serve our repositories, we must first make a configuration file for hgweb. The configuration file should look like this:

[collections]
/var/lib/mercurial-server/repos/ = /var/lib/mercurial-server/repos/

[extensions]
hgext.highlight =

[web]
allow_archive = bz2
pygments_style = vs
style = monoblue

You can, of course, tweak this configuration to meet your needs. The [collections] section should stay the same, however, unless your mercurial-server saves the repositories in a non-default folder.

You can also disable the highlight extension by removing the [extensions] section and the hgext.highlight line. You need to do this, for example, if you do not have the Pygments library installed. However, I highly recommend it for browsing the source code. The pygments_style line should also be removed if you disable the highlight extension. I like the vs style (Visual Studio), but there are quite a few different styles that Pygment has out of the box. If you want to see the styles available to you, run the Python interpreter (python) and run:

from pygments.styles import get_all_styles
print list(get_all_styles())

You can choose between different styles for hgweb as well. I prefer monoblue myself, but there are quite a few options that come with Mercurial, and you can download even more online. If you want to see all of the hgweb styles available, in a shell run:

ls /usr/lib/python*/site-packages/mercurial/templates/
# Note: only the directories are styles!
# If ls does not show colors, try adding the "--color" option.

The allow_archive line tells hgweb to allow users to download a .tar.bz2 archive of the repository. You can also add gz and/or zip to allow users to download a .tar.gz or .zip archive. They are comma-separated, so use bz2, gzip, zip to offer all three.

Next, you should add a contact and description for your repositories. If you don’t, Mercurial will just show “unknown” for Description and Contact. To add them, first change into the repository’s folder:

cd /var/lib/mercurial-server/repos/$REPO_NAME

Then, create/edit the file .hg/hgrc and add the following:

[web]
contact = Your Name <your@email.address>
description = My Mercurial repository

Additionally, for any repository you do not want to be shown in hgweb (which will also prevent people from pulling the repository using hgweb), add the following instead:

[web]
deny_read = *

You also need to set the ownership of the hgrc files to the mercurial-server user, hg. To do that, it’s easiest just to set the ownership of the entire repos folder (which is safe, because mercurial-server always owns the entire folder anyway) by running:

chown -R hg: /var/lib/mercurial-server/repos/
# Failing to do this will cause warnings about untrusted files anytime
# someone pushes or pulls using mercurial-server!

Finally, you need to configure your web server to use hgweb. This part is web server dependent. However, before you configure your web server, you need to choose the interface hgweb will use to communicate with your web server.

• CGI
  • Pros: easy to set up, no overhead when not being used, software updates happen immediately
  • Cons: forks a new process for each request so slightly slower page loads for small requests (insignificant for large requests, such as pulling a repository)
• FastCGI
  • Pros: no forking overhead so each request starts being processed immediately
  • Cons: always running so takes up more RAM, more complex to set up, not officially supported by Mercurial (although a FastCGI script is provided), software updates require a restart of the FastCGI script
• WSGI
  • Pros: no forking overhead like FastCGI, software updates happen immediately
  • Cons: more complex to set up, always running so takes up more RAM, requires either a Python interpreter in your web server (Apache) or a separate process (most other web servers)

No matter what you choose, the setup process is documented here [mercurial.selenic.com]. Remember to point hgweb at the configuration file you created!

The end result should look something like this [hg.0x3b.com]. That installation of hgweb does not support pushing; mercurial-server handles all pushes. However, both hgweb and mercurial-server share repositories, so when I push to mercurial-server, it can be seen on hgweb immediately.

Hopefully this HOWTO was helpful! Feel free to leave comments if you have any questions or concerns. If you have any suggestions, please feel free to leave them here!

Thanks for reading,
dririan

Hopefully, I’ll be making lots of posts soon with how-to guides for advanced topics, tutorials for basic ones, and lots of other content about technology!

Talk to you soon,
dririan