Sat, 23 Dec 2006

Merry Christmas

To all of our clients, friends, and supporters, a very Merry Christmas and all the best for the coming year!

If you live in one of those post-modern countries where it’s illegal to say such things, then I wish you a happy holiday and a very drunken new year.

AfC

merry-christmas-2006, posted by Andrew Cowie in /andrew/personal at 02:47, 23 Dec 2006.

Wed, 13 Dec 2006

On the politics and economics of dual-licencing

Christof on free-loaders

In a recent thread on developer.db4o.com, several people were whining about how the GPL is too tough for them, and that they wanted db4o for free without neither the obligations of mutual software freedom nor the requirement to have to pay for a commercial licence.

Midway through, Christof Wittig, their CEO, posted a reply that I thought really captured the essence of what they are doing as a company. Here’s my favourite part:

I think most of you know that db4o is a dual-licensed product — with [the same code available in] an open source version and a commercial version. The commercial version is distributed by db4objects, a company that is for-profit and — believe it or not — we are here to make money.

If you are open source/GPL, we are. If you don’t want to comply with the GPL, we’re not open source and not free either — in this case we’re as commercial as you are, though perhaps a little bit more affordable than others. It is as simple as this.

All discussions on this topic are usually by people who want to use the free/open source versions for their commercial/closed source businesses without giving back to the community — either with code or with money. For me that’s just free-riding.

The forbearance of CEOs

It never ceases to amaze me what the CEOs go through. Running any company means endlessly answering the same questions, and I can only imagine what the clamour must be like for the CEO of an open source software company. Under that sort of constant barrage, it’s all the more impressive that someone like Christof continues to keep such an even keel. Well mostly…

Some of you use the value-approach for pricing (which we promote, too: Usually we try to capture 3-5% of your software value). Some claim, though, that a few thousand bucks [that would be db4o’s licence cost] would be 50% of their total cost. If this was right, then the entire business was only 2× a few thousand dollars. But how can this be? Even if you live in Siberia, you cannot make a living on this as a company. So you are either not saying the truth or, more likely, you exclude complementary revenue streams, e.g. from services or add-ons, that you cross-subsidize with low cost or free software. These revenue streams, though, should be included in your value approach, and then you’ll soon find yourself in the low digit ballpark with the db4o license fees.

Or you can release your own software under the GPL. Take your pick.

Why Open Source is not communism

I advise clients about Open Source, and one of the questions that inevitably comes up in the discussion about people who dual-licence their software is, “but it’s GPL! How dare they charge for it! How can they? %#@$^&!” Sadly, the people asking that question in such an arrogant and demanding tone have missed the point. Open Source is not communism! There is no obligation to contribute what you own and no one taking it from you by force, stealing it for their own benefit while justifying their actions in the Holy Name of the People.

“No,” replies the author, “It’s my property. I wrote it. I have the copyright on it, I own it. I can do whatever I like with it. I have chosen to release my code, without patent encumberment, and you can use it, but only under very strict conditions. If you’re willing to agree to those limitations and in so doing contribute to the raising up of the whole world through the apotheosis of software freedom, then you’re welcome to use their code for whatever you’d like. People and organizations who have chosen the dual-licence model to fund their enterprise then say, “Not willing to meet the terms the GPL? Then if you want a licence to use my property in your product, start forking over the cash.”

One way or the other, FOSS is about contribution. Don’t whine about why you can’t have it for nothing.

AfC

free-riding, posted by Andrew Cowie in /andrew/software/db4o at 00:48, 13 Dec 2006.

Sun, 10 Dec 2006

Pushing a bzr branch with rsync

For some reason bzr rspush, a plugin from the “bzrtools” unstable command collection, doesn’t know how to push a branch that’s in a Bazaar repository.

Repository layouts

What’s a Bazaar repository? Good question. It’s not what you get if you do bzr init. You have to do bzr init-repo --trees . in a directory, then within that directory create and copy branches. Apparently this then allows the branches to share revision delta files in common.

Why oh why can’t they just be immutable like Git does and thus hard-linkable?

Anyway, I’ve ended up with a directory structure as follows. There’s a top level Bazaar repository here:

~/src/andrew/java-gnome

The bzr data actually lives in, as you might expect,

~/src/andrew/java-gnome/.bzr

But that repository is not a branch and not a working directory. In the repository directory, I create branches and clone them:

~/src/andrew/java-gnome/codegen
~/src/andrew/java-gnome/equivalence-fixes
~/src/andrew/java-gnome/mainline
~/src/andrew/java-gnome/primary
~/src/andrew/java-gnome/website

And so on. Each one also has a .bzr directory:

~/src/andrew/java-gnome/mainline/.bzr
~/src/andrew/java-gnome/website/.bzr

Apparently the deal is that if the actual revision data isn’t in the proximate branch’s .bzr, it’ll look up one to see if there’s a .bzr there (and finding itself in a repository, there is, and so the data it needs is in ../.bzr/repository).

Since I used the --trees option to bzr init-repository, I get working copies in each of those directories. I can then point a symlink to it from the place where my Eclipse IDE expects my working directory to be,

~/workspace/BindingsPrototype -> ~/src/andrew/java-gnome/primary

and finally I can get to work. [You go to a lot of effort to configure Eclipse to work on a given Java project in a specific place. Switching the basedir of that path from one place to another is a non-starter, except by doing a full refactoring. So, the symlink]

I’m liking bzr well enough, but doesn’t this strike you as a bit complicated? Granted git is a usability disaster zone, but the core concepts of repository storage and branching seem really rock solid. I really miss the create-a-branch-in-place and switch-between-branches-in-place aspects of Git. Those were killer features for me. Bazaar has a evolved in a few too many parallel directions, and they need a bit of good old GNOME 2.0 style refactoring to get out some of the cruft. Still, though, they have unit tests. That’s worth a lot in my book.

Pushing the wall

So now its time to publish your work. My experience trying to bzr push sftp:// to a server half way around the world was that the sftp implementation is brutally slow. Using their “Smart Server” with a bzr push bzr+ssh:// command was not much better.

Obviously this sort of thing is crying out for a little rsync lovin’, but unfortunately the bzr rspush command which supposedly does just that doesn’t know how to push a branch that’s in a Bazaar repository. Oh, great. So I had to do it manually.

I have a script that does a bunch of switching to figure what I want to send (source, website, photos, whatever) to where. For source code, I use it something like this:

upload source <project> <branch>

You get the idea. The trick is to figure out how to tell rsync to include the repository .bzr, the branch directory (and its `.bzr), and exclude everything else. I could have just done two separate SOURCEs, but I like to see all the traffic reported relative to a single root, so I use rsync’s include/exclude syntax instead. That stuff is notoriously voodoo; this time was no exception.

Here’s the magic smoke I used to get rsync to push a Bazaar branch within a Bazaar repository:

    PROJECT="$2"
    BRANCH="$3"

    # note trailing slash
    SOURCE="/home/andrew/src/andrew/$PROJECT/"
    DEST="andrew@centauri.lhr.operationaldynamics.com:/export/web/com/operationaldynamics/research/bzr/$PROJECT"

    # for some reason the escaping necessary eluded me; workaround:
    s='*'

    # now go to the trouble of including each directory in the chain
    # (otherwise exclude * nukes them) and the three things we care
    # about in <project>: /.bzr, /<branch>, and /.bzr

    OPTIONS="--include=/
        --include=/.bzr
        --include=/$BRANCH
        --include=/.bzr/$s$s
        --include=/$BRANCH/$s$s
        --exclude=/$BRANCH/tmp
        --exclude=/$BRANCH/.config
        --exclude=$s"

    shift 3

…

    exec nice rsync \
        --verbose \
        --recursive \
        --update \
        --links \
        --hard-links \
        --perms \
        --times \
        --sparse \
        -e /usr/bin/ssh \
        --partial \
        --progress \
        --compress \
        $OPTIONS \
        $* \
        $SOURCE $DEST

So with a nice simple:

upload source java-gnome mainline

I publish (only) the “mainline” branch in my ~/src/andrew/java-gnome repository.

Hopefully that will be of help to someone; I can’t be the only person who has found themselves wanting to publish a Bazaar branch from within a project repository. What would be great, though, would be a nice and simple bzr push ssh:// that just assumes rsync-over-ssh and does all this for you. Shouldn’t be too hard for someone to hack in.

AfC

bzr-repository-rsync, posted by Andrew Cowie in /andrew/software/version-control at 14:12, 10 Dec 2006.

---

Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile

---