On choosing open licenses

I’ve recently written a technical roadmap for one of my shadow projects.  I’ll quote what I have so far about software licensing, at least as it pertains to feedstock:

  • Open source feedstock preferred
    1. Licenses that permit us to keep the source internal, even when we distribute binaries externally (BSD, MIT, Apache) are approved for use without legal review.
    2. Licenses that require the distribution of source when binaries are distributed (GPL, EPL) are allowed when any modification we might need to make to that component can be distributed without harming our position in the market.  In other words, we don’t want any “special sauce” licensed under these terms, but it’s good karma and community to contribute back to these projects.  Legal and finance review required.
    3. Licenses that are “weird” (vim’s Uganda license) or require distribution of source for any modifications (AGPL, non-OSI) are disfavored except for specific, limited uses.  Legal review required.
    4. Proprietary software may be used after a marketplace study and legal review.

The essential idea here is that I want my projects to contribute back, but I want to do so voluntarily. I particularly want to avoid a situation where I need to implement “special sauce” in a component, but then may have to release that code out into the marketplace- there’s no particularly good reason I would want to take on, say, a virally licensed webserver.

In terms of choosing feedstock, it’s often hit or miss, but I always look at the licenses before I start, particularly for “scaffolding code” that will wind up being the core of an app.  I’ve been working more in Clojure lately, and it’s somewhat annoying to track down BSD or MIT licensed starting points.  The community mostly uses EPL, which is fine for dependencies like a database connector.  It’s not so great as a starting point when I want to release my app under a BSD license.

In terms of releasing my own projects: I tend to license as BSD3, and I figure that I can always fork internally if I need to include some “special sauce”.

So why am I writing? Because Mailpile is asking for opinions, and they’re between two very different options:

  • AGPL, the most viral of the viral licenses, which would essentially require anyone running Mailpile to make the source available, and
  • Apache 2.0, which is not nearly so restrictive.

Between these two options, my vote is emphatically for the Apache license.  However, it might make sense to consider a middle-of-the-road approach and look at using the EPL or GPL.

Note: This post is basically about feedstock; that is, dependencies for your production code.  If you’re talking about tooling, particularly when you don’t plan to modify it, then you don’t have to worry so much about “viral” licenses.  For example, most users don’t really need to worry that vim has a weird license, because it’s a tool.  If your project revolves around modifying vim extensively, then you of course will have to live with its license.

If you’re interested in more on this, tweet me up @franksiler.  Please remember: I’m a lawyer, not your lawyer.  This post is for informational purposes only.

Previous Post