Infrequently Noted

So you're starting an OSS web project. At some point in the evolution of your project from a couple of files on-disk to something you're maintaining on google code or sourceforge, you're going to be asked what the project is called and what the license is. I can't help with naming, but on the licensing bit there are some things you should know. Unless you've already spent a lot of time thinking about licensing, this can be daunting. How should you pick a license? Will it even matter which one you pick? Why not just pick GPLv3? And what about Open Source Foundations (Apache, Eclipse, Dojo, etc.)? And since this is such a quagmire, why can't I just put it in the public domain?

Lets take a look at each of those in order.

First, the obligatory IANAL disclaimer. That I happen to deal with some of the licensing policy stuff for Dojo does not mean that you should trust your project's licensing doctrine to my (mis)understanding of the law. At Dojo we do retain lawyers to help answer our questions and I strongly recommend you do the same. You might even be able to get some advice that's worth more than you pay for it. Lastly, lots of other stuff is much more important that licensing in the future of your project. Getting these bits right won't matter if your software sucks, so make sure that's your first priority.

How the heck should I pick a license?

My personal take on this is that you should pick a license for your project based on your personal goals with regards to the software you're giving away (or maybe not giving away). If your goal is to get your code into the most people's hands with the least fuss, go BSD/MIT/Apache-ish. If you care about software freedom at the expense of potential users, or if you want to be able to sell your code later without real competition, go (L)GPL-ish. Those are gross oversimplifications of the choices involved, but as we'll see they largely line up on-side because they imply that you sort of have an idea of who you want your users to be. Is your project a success if it is the basis for commercial products that you're not involved in? Or do you personally want people to know that you did that? If Microsoft (or whoever you cast as "evil") starts using your code, would you be upset or happy?

These decisions are inherently social. They lay the groundwork for how others perceive you, your code, and the people you may attract to your project. Much like a university degree, these perceptions may have absolutely no basis in fact other than that you did, indeed, pick a particular license. The things others assume about your project as a result are very likely to be wrong, but like a lot of statements of values, you should pick a license whose social contract implies something that you want your project to be when it grows up. By doing this you're setting a flag which potential contributors to your project and consumers of your software will look to to get a feeling for "what is it?".

At the Dojo Foundation, our licensing goals are explicitly tactical: adoption over control, 100% of the time. We've picked the AFL and BSD licenses because they are "friction free" in conjunction with the rigor of the Foundation (which I'll get to). They set the flags for "commercially friendly", "anyone can play", and "politics unwelcome". Are those things strictly true? Probably not. But they say a lot about the ideals we'd like Dojo Foundation projects to embody. Other organizations have very different sets of goals, and their licenses reflect that. The FSF's licensing policies throw the flags of "your rights matter", "politics acceptable", and "commerce tolerated (on our terms)". In the particulars of any individual project these sets of flags may be indistinguishable from each other, but how others perceive them has an impact upon who will show up to "play" at your project.

So what does all of that mean for how you should pick your license? It implies that you need to figure out why you're giving your work away. Is it just a way to get adoption (BSD-ish) or is it The Right Thing To Do (GPL-ish)? Once you've figured that, the rest is just mechanics. There's no wrong answer, but there are consequences for doing the mechanics wrong.

So does it matter which one I pick?

As you may have gathered from the preceding comments, it may matter which license you chose. Or not. Some very large organizations won't touch code that is of (L)GPL origins if they can help it, but those same organizations will back hugely successful GPL projects when they've already won the market. Other organizations and individuals prefer (L)GPL-ish code.

Reasonable people apparently disagree on which style is right, so maybe we should rephrase the question a bit: "How can I ensure the success of my project through my licensing decision (insofar as it matters)?"

First, you're going to need to consider the cultural impact of licensing. You're more easily going to be able to contribute to a Debian-centric project if you use the GPL since that community "gets" and appreciates the freedoms embodied by that license. You'll have a tough rode to hoe, though, if you want to then take that code to FreeBSD and expect it to be "blessed" without a license change. Ensuring that your code can be mixed with other code that you care about is often down to licensing, so look around and see what others are doing before you pick. If your boat can rise in their tide, it's a good bet you'll want to use their license too.

Secondly, consider commercial use. Big Open Source companies like IBM and Sun have a strong preference for clean BSD-ish code. It's no wonder, then, that enterprise software vendors are beating down the doors of the Eclipse and Apache Foundations to get their projects accepted and released under those licenses. Doing so makes them both presumptive "winners" in those communities for their target feature sets, but it also signifies that the code is palatable for many of the largest corporate consumers.

Next, remember that your project isn't just trying to court new users, it's also trying (hopefully) to find new developers to pitch in and make it even more awesome. If you pick a license that people don't know or aren't familiar with, you raise the bar to acceptance in both groups. Going with a "well known" or "name brand" license can help steer your clear of those shoals, even if the license itself isn't as strong or accurate as the one you'd prefer to use.

Lastly, remember that licensing may be a no-op. Even if you throw all the right flags with your licensing, your code may still suck or your UI may be totally unusable. See Debian vs. Ubuntu for a graphic demonstration of how energy spent on licensing may be utterly wasted. No matter how culturally deft and no matter how clean your code, if your app/toolkit sucks, you're not likely to win.

What do you mean by "clean"?

Cleanliness usually boils down to "what are the odds that someone can sue me down the road for using this code?". No one can know those odds up-front, and success (or distribution, if you define "success" differently) increases the likelihood of legal antics. You, the OSS project lead/maintainer may never be directly affected by these kinds of machinations, but your potential users think long and hard about them. Dojo is still a tiny fish in the Open Source pond and even I field questions from corporate legal counsels on a weekly basis. Each of those messages means someone is paying lawyerbucks to figure out if they feel comfortable using Dojo. That's a lot of money. Clearly it's got to be worth it to them to have peace of mind.

So how do we keep code "clean"? The short answer is "by knowing where it came from and having a license to back it up".

If you pick a GPL-ish license, a lot of that solution is baked into the license itself. Since no one can create derived works that are under less permissible (or more permissible) terms, and since the GPL speaks to patent as well as copyright rights, code under these licenses usually only needs to have some sort of public lineage (anonymous access to project SVN will do) to allay fears of lawsuits coming out of the sky.

Assuming that you have the right to put that code under such a license in the first place, that is.

The biggest weakness not solved by any OSS license (yet) is that things which are assumed to be under a particular license may not be "cleanly" given. For instance, a well-intentioned employee at Big Co. Inc. decides in her spare time to get involved in Dojo. Now, generally, Big Co. has an employment agreement with some really nasty language about "intellectual property", and the take-away is usually that no matter what our mythical employee thinks up while she works there, it belongs to the company. Usually these things are written in such a way as to ever cover what she does on her "own time".

So what happens when our well-meaning (but not a lawyer) employee wants to start working on OSS in her spare time? If she donates code without first getting approval from the company, the odds are pretty high that the project will then be (potentially) screwed, no matter how "share alike" the license may be. This is a Bad Thing for the project. Most OSS projects guard against it by either asking very pointed questions of new contributors or by getting a legal contract in place from the contributor which makes them state in a legally binding way that they are actually giving a license to the code to some other entity (typically a Foundation) and that they have the right to do so. That last bit is important. By having folks attest to the fact that they either own or have the right to donate the code in question, the project has done its best to make sure that the right-to-donate hole is filled. It also prevents "malicious contributors" (think SCO) from claiming later that they didn't actually mean to donate the rights and IP embodied in the code to users of your project.

These contributor contracts, or "Contributor License Agreements" have been made prevalent through the hard work of the Apache Foundation. Notably, though, they require a legal entity on the other end of the line to sign a contract with. Hrmmmm....

What about those Foundations?

Foundations like Eclipse, Mozilla, Apache, and the FSF all provide legal resting places for rights embodied in code. By acting as umbrellas against personal liability amongst contributors and by providing a legal structure in which to execute license agreements and CLAs, Open Source Foundations are a handy (but time consuming) legal structure that successful projects have employed to help promote their adoption. Generally organized as non-profit corporations, Open Source Foundations are time-consuming to set up, but may be essential to ensuring the cleanliness of your project's code, particularly if it's under a BSD-ish license like Apache, Eclipse, or MIT.

So should you set up a Foundation for your new project?

Probably not. Setting up a Foundation is a PITA, and the odds are pretty high that you don't want much out of the Foundation...at least not until the project is successful. Your best bet is to start your new project inside the umbrella of an existing Foundation. If that's not possible, you might be able to re-purpose an existing CLA to be between contributors and yourself (personally) to ensure that you hold all the rights to all the code or simply not allow much in the way out outside contributions. I've used both strategies in the past with success.

Alternately, if you're going to try to get your project accepted at an existing Foundation (recommended!) sometime in the future, you may just want to ask that all new contributors sign a CLA with that foundation before submitting code to your project. Until your project is accepted under that Foundatin's legal umbrella, you'll still be out on a limb, but at least you'll have set the stage for success later and may unblock development in the short term. I don't know the legal ramifications of this approach, and you might want to augment it with assignment of copyright to you personally as well. Regardless, getting your project out from under your own name (and therefore, personal liability) is a Good Thing (TM). Find a good home for your code ASAP, and if that means setting up a new Foundation, so be it. When you're drowning in paperwork, though, remember that you were warned.

Shameless plug: the Dojo Foundation wants to help young projects avoid the licensing fate of many of the currently popular JavaScript toolkits which didn't pay enough attention to licensing up-front. We're easy to work with and provide just enough of an umbrella to help grow your community without suffocating a small project with process. If you're starting a new OSS web project and need a good home for it, send me mail. The Dojo Foundation may not wind up being the right home for your code, but we'll try to help however we can.

Dual licensing: good or bad? And can I change the license later?

Firstly, if you've already released some code and you've taken patches from someone from a mailing list (without a CLA), or if you've borrowed code from someplace and didn't think too hard about it because it was "obvious" or "open source too", you can stop reading here. Unless the patches are blindingly trivial (think less than 5 foreheadslappingly-obvious lines), your project is no longer "clean" and you've probably already shot any hope of being able to dual-license or re-license in the foot. Since the code that you're integrating from other people starts with their copyright, you can't just change the terms of their licensing decisions retroactively any more than they can say that your software is governed by the Windows EULA without your permission. If you haven't taken patches or if you think you can easily track down your contributors and get them to sign CLAs, you're in a very good place. Either way, now's the time to figure our your strategy for accepting contributions.

The CLA that Dojo requires of all contributors provides the Foundation with a broad license to the rights over donated code. Original authors keep their original authority over their copyright and patent interests, but they also "cut us in" on the ground floor. The CLA gives the Foundation the ability to repurpose the donation as it needs to (under the oversight of the Foundation Board) by providing sub-licensable access to both copyright and patent for the code. Practically speaking, this type of arrangement allows an Open Source project to "dual license" without asking every contributor for permission all the time. In the case of the Dojo Foundation, we use that power to offer Foundation projects under BSD-ish licenses which promote adoption, and other licenses on a one-off basis where it will encourage adoption. We wouldn't be able to put the Perl bits of Cometd under the Artistic and AFL licenses if the Foundation didn't have a license to all the rights for that code.

At the Dojo Foundation, we use the rights which we've accumulated through CLAs to do what's necessary to make Foundation projects successful. If that means that the dominant license in the Python community is the General Foo License, we'll probably adopt it alongside the AFL for Python code we release to make sure it's got the maximum chance for success in that community. That doesn't mean that dual-licensing is always a good idea, though. It can create confusion with users, and many people associate "dual license" with something very different.

Other kinds of organizations do dual-licensing for different ends, but use much the same mechanism. By controlling all of the copyright and patent interests in a bit of code, many companies that provide their products under Open Source licenses can also turn around and charge users of that software money under a different license agreement. Projects like MySQL, QT, and EXT can't accept "external" patches for the bits that they sell, and they manage that tension with their community in different ways. In the case of MySQL, you can pay for packaged, tested releases with support and extra features. This allows the community to develop the core as GPL'd software without needing a CLA for every little change. QT and EXT, on the other hand, have pursued strategies which put the entire project development process behind the "rights wall". This means that they can offer the whole thing with particular guarantees to commercial users and even proscribe commercial use without purchase of a license. What affect this has on communities (often negative) and on the quality of the software itself (often positive) is a matter for a different article, but if you're thinking about dual-licensing in order to start a business around your code, just know that you'll need to decide early on to keep control or else you'll be looking at the services/support/add-ons model for making money from the project.

As for changing the license on your project, note that you're going to require all the rights to all the code in order to make a full license change. Think of it as adding a license (dual licensing) and dropping one. Your project will need to have accumulated CLAs or have a "rights wall" in order to pull it off. Alternately, you can ask everyone who ever contributed for permission. Oof.

This is a pain. Can't I just put it in the Public Domain?

It's unclear. At Dojo, we'd put all of our code into the public domain if we thought we reasonably could. We've even asked our laywer (at length) about this. Her reply has left us feeling squeemish enough about the legal underpinnings of the Public Domain to question whether or not we can actually use it. If you're looking to get your new project adopted widely, I'd recommend against trying to go this route. Until the situation is much clearer, a liberal license like BSD, MIT, or Apache + a CLA system seems to be the best way to provide users with the broad rights the public domain would imply and also the assurance that they're not going to get sued over it.

I know i've glossed over a lot of the pertinent legal issues in this post, but hopefully it'll help new project leads help themselves before it's too late. If I had to sum it all up to someone asking my advice, I'd just say "find a Foundation that will take your project when it's still very small". By the time your project is medium-sized, it's probably too late and that's the very time when setting the right flags may matter most. Setting them won't guarantee your project success, but you'll never get hit but the bus of destiny if you don't stand in the middle of the road.