Anyone with an RSS reader and a passing interest in languages or browser technology has by now caught a whiff of the strange odor coming from the ES4 vs. ES3(.1) debate. Before I dig in, I should mention by way of disclaimer that I'm an invited "expert" (har!) to the TG1 working group. Take the rest of this post with the appropriately sized dose of granulated sodium.
A lot of dirty laundry is getting aired and I'm afraid I haven't been immune from hyperbole and inaccuracies in the process, so charged and furious is the debate. There's been procedural wrangling, odd missives, emphatic rebuttals, painful comment threads and expositions on theories of how the web should evolve. Even a bit of popcorn sellin...er...press coverage.
We're starting to miss the plot a bit.
Wrapped up in the question of "will Microsoft implement ES4?" is implicitly "what will Microsoft implement? when?". Answers to this question aren't about features so much as they are about trust. Reflected in the comments of these threads seem to me to be two primary voices, roughly paraphrased as:
- "The web is evolving again because of Ajax and libraries. If browsers start changing, it'll be chaos. Stability enabled this round of growth. Don't blow it."
- "We must have browser evolution to fix the huge problems with the existing state of the art. Give us big new stuff ASAP"
We've seen both of these voices before, particularly in regards to W3C activities. Some of my previous comments on that topic made the debate louder without (I'm afraid) providing much perspective about how the community can effectively advocate for fixes. What's good about the ES4 debate (in contrast w/ my CSS ramblings) is that they are scoped to particular implementers. Insofar as advocacy makes a difference, lobbying a working group which is moribund is nearly useless. They have authority but no power. Power in these situations always lies with implementers, aka browser vendors. The CSS discussions are weird and airy because there's no real skin in the game. Swatting at the W3C is just so much shadow boxing. Asking browser vendors to take risks, to show some good old-fashioned technical leadership and put some of their theories about how to evolve into their competing implementations....now that's got legs.
The first perspective, I think, is borne of a fear of loss mixed with a big pinch of "IE4 vs. NN4 sucked" (queue involuntary twitching). The web won. The web is strong. The web's strength is due in large part to the fact that (as never before) it "is" a single thing in the minds of developers. I'm incredibly sympathetic to this viewpoint, and the argument that major changes in HTML and other fundamental web technologies creates opportunity for closed technologies to sell the "but we have a uniform deployment environment" argument does hold some water. But not enough.
Closed-platform vendors have always been selling that advantage, in part because it may be their only sustainable advantage over mass ubiquity and real competition. What advocates of the "go slow" position rightly are pointing out is that when faced with what to do next, the pace of change suggests that the deployed browser population is set in stone. It has always looked this way, though. From the days when Netscape 3.2 kept us from using DHTML in any real form to the years when NN4 just couldn't die fast enough all the way through the new deadpool taking bets around the demise of IE 6, progress on the web has always been gated by deployed systems. Yet somehow we've got most of HTML 4, CSS 2, and ES3 in a semi-portable form. Clearly the web is robust enough to handle moderate doses of divergent implementations. Progress neither asks for permission nor arrives with a press release. It's made one browser upgrade or replacement at a time.
Both of the perspectives on where to go from here are veiled ways of asking the question "who can make it better for me?". It turns out that the Ajax toolkits matter (if they matter at all) because they can give us what we want without waiting for browser vendors to field implementations; for some value of "what we want". That might seem like the future, then. Just ask your friendly Ajax toolkit vendor for something you need and wait for it to be implemented. Would that it were so simple.
Ajax toolkits (like Dojo) represent "cheap" agreement. Instead of the browsers duking it out on features and subsequently unifying APIs at a standards body, toolkits can paper over differences to some extent and provide a unified front, but the cost to doing so is massive. Not only do they need to be shipped down the wire (a constraint that mangles their design every step of the way), they introduce their own bugs, weirdisms, and inefficiencies. In a functioning marketplace, the feature set of ajax toolkits would be changing very quickly. As new versions of all browsers are released, the toolkits would keep code only so long as old versions of browsers for which they bridged functionality were in play. The existing features would be gone in a year or two, replaced by native APIs and tags, and new features would be added to help lessen the blow as the browser makers attempted to figure out who was going to "win" on a particular way of implementing this or that. In any event, it should be obvious with even cursory introspection that the toolkits can only approach so much functionality at once (until they're baked in or preferentially cached by the browsers, that is), and that functionality can really only cover basic capabilities which are ubiquitous or are so close that a bit of script can push it over the edge. We may always have the toolkits, but arguments that somehow they'll dig us out of this hole don't stand up to inspection. We toolkit authors are combing the beach of features from the various browsers, desperately trying to construct a full set of shiny shells of any type. Small irregularities we can polish out, but if one thing is square and the other is round, there's just no way we can make one into the other without spending more time, effort, and money than it's worth.
So now we've got the shape of a solution to the problem: toolkits can act as our canny observers of ubiquity, constantly combing for ways to get us to a robust baseline, iterating faster than the entire ecosystem might otherwise allow. But we've been over this beach a lot already. We're out of shiny shells that look similar, and have been for a long while. At this point we're reduced to selling our own compositions instead of looking for the natural beauty which attracted us to this beach in the first place. We need a good storm. We need new features to mine, and we need to be able to drop all the code which we're monkey-patching old versions of IE with.
To be bleedingly obvious about it, we need the browser vendors to ship. Not once, but over and over again, on a predictable schedule, and with some actual competition and risk taking. Hiding behind W3C (or even ECMA) committees instead of shipping new stuff is a tactic which the web community at large simply won't accept any more.
New browsers (aka, new features) are the only way we get new shells on this beach. Sure, some of them are ugly. They'll get left, and in time, washed back out to sea. So be it. If we get shiny, pretty new ones tomorrow, the ugly ones don't matter. But we have to be able to trust that we will. The idea that the web should be the same tomorrow as it was yesterday is ludicrous. "Don't break the web" simply cannot be code for "if it changes, that means it's broken". It would be laughable on the face of it if it were. It may have been changing imperceptibly of late, but it has always been changing. Likewise, things which make it uninhabitable for large quantities of content can't be passed off as "good" just because they're change.
What that all adds up to is that inciting browser makers to iterative action, spec or not, is the only way we actually get new stuff into the fabric of the web. If we're going to really ride this "open web" thing, we (the development community) need to come to grips with the fact that we're never going to get new features in one fell swoop. We've always gotten them in an N+2 fashion, and that's not going to change, no matter who's got the majority market share today.
What we should not ever settle for, ever again, is for any of the vendors we depend critically on to go radio silent. The web looses not when other platforms are better (they always have been, always will be), but when we lose confidence that the market mechanism of competition is functioning. When we can't count on new features at predictable mile markers, there's no change to treat as opportunity. It doesn't even matter so much how big the changes are. We just need to know that they're coming and will be coming again in the future. When there's no change (aka: opportunity), the web dies a slow, wrenching death as more canny things which can provide the promise of a future that's not the same as the present steal mind share, first for the high end, and then all the way down the spectrum.
So, as I've been saying in my public talks of late, demand a public plan from the browser vendors. All of them. Asking for standards conformance isn't an answer, but combined with asking for a commitment to future versions it is the basis for resuscitating this market. We can start with: "When will your next beta or alpha be available? What about the version after that? Is your organization standardizing the new stuff you added in the last stable release? Where?"
Those questions don't speak to features, the speak to futures. Features without a future don't matter.
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.
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.