Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Clean Licensing: Why You Should Care (If You Don't Already)

I've written before about the importance of clean licensing to an Open Source project, but one of the things I didn't cleanly outline is the case for clean licensing from the point of users. Understanding why clean licensing is valuable to users helps to further cement why it's valuable to projects, and why well-run projects have such a hard job when it comes to building the inclusive, "lets try anything" spirit that it takes to succeed while watching out for the interests of their users down the road.

Put bluntly, it boils down to risk. What are the odds that someone contributing to the project I'm using will decide later that they've changed their mind about giving away their hard work for free, particularly if the project becomes super-successful? And what is the project doing to mitigate that risk?

It's worth remembering that the projects themselves don't often have much to fear when it comes to "unclean" contributions and are entirely unlikely to change their basic terms of distribution (unless all the code is copyright one person or legal entity), which leads many projects to take an approach of "looks good to me..." when it comes to accepting patches. Most OSS projects don't have any money, and suing an OSS project is a political nightmare. All of this means that the risk of choosing poorly is often externalized by projects. That is to say, they make it users' problem; you got the code for free and now you're whining? (but of course you are...you're still "paying" for the code in other ways) Lastly, if the project us under the GPL, there isn't any real risk so long as the project has a public record of where patches came from (i.e., public source control that anyone can inspect).

So already we've got some big warning signs that we can look for to determine if a project is looking out for my best interests as a user:

At this point anyone familiar with even the basics of the licensing of OSS JavaScript toolkits will note with wry amusement that I'm describing a set of criteria that cast Dojo Foundation projects in a favorable light...and of course I am; we set up the Foundation's licensing policies to explicitly avoid the kinds of pitfalls that large users of OSS already know to avoid. This post is simply about helping everyone else understand that logic. That your tools of choice may not compare favorably isn't for a lack of effort on our part. As I've said over and over, we welcome any deserving project under the umbrella of the Dojo Foundation. Enough about that, though. Back to the nuts and bolts.

As a user of Open Source code, my biggest concern is always that the code does what I want it to. There are lots of creative ways to isolate poorly licensed projects when building an app, but I'd much rather not expend the effort if I can avoid it. Some licenses (in some situations) may even impact my business model, so very close behind "is it good?" in my mind is always "how's the license?". When given a set of roughly equivalent options, big OSS users often flip those concerns. For them (and possibly for you), the hassle, risk, and expense of funky licensing absolutely outweighs functionality. Some are so large in-fact that using or backing an OSS solution is simply a market expedient and not a necessity in any way. But you and I aren't that big (probably), and besides, we like our tools just fine.

And this really cuts to the crux of the issue: despite not having paid anything for the software, choosing a particular tool means investing in it. Learning the APIs alone is probably a significant investment, and porting to some other solution will require time and effort. OSS means you're not putting up cash at the get-go, but certainly as time goes on there is a very real investment in the Open Source infrastructure that we build products and projects with. How "solid" is that investment going to be? Obviously, we can't know what's going to happen in the future, but can certainly steer clear of potential problems once you know how to look for them.

Which leads to the last point, and one which I've heard parroted by other OSS project leads who haven't been as careful: are people seriously going to get sued? I mean, is this ever really going to matter?

Admittedly, Open Source licensing lawsuits are rare, and most small organizations never see them. Instead, what they see are opportunists and shake-down artists like SCO knocking on their door years later for "licensing fees" about some IP they may never know they've swallowed. The SCO suit was a weak case in part because SCO had itself distributed Linux and the kernel was GPL'd. Even the lamest and dumbest of trolls must surely have learned something from SCO's public humiliation, no?

My only answer for this is that many of Dojo's users get sued only because they have money and the sun is shining. That's not going to change because they chose Dojo or don't, but there is serious opportunity to for components like Dojo to put them in a bad situation were we not as careful as we have been about the licenses of all the components of the toolkit including images and CSS; not just code. I cringe every time I see an Open Source rich-text editing control which uses icons which could easily be confused with those from a certain (litigious and Open Source fearing) Washington-based software distributor. Those projects may never see so much as a C&D, but their users may be in for hurt. Now imagine if that were an entire UI theme and not just a couple of icons? Oof. If the projects which are saying they aren't hearing concerns from their users reflect on it a bit they may realize it's just as likely as not a question of timing and self-selection. The big OSS-savvy organizations have passed them over. Why deal with the headache?

The pedigree of the inputs into a project determines the legal risks associated with its use down the pike. Since we can't eliminate risk, only mitigate it, it pays for all of us to ask questions about the licenses of the projects our products and projects make use of now — while it's still cheap to do so. Hopefully by doing so, we'll not only push the good code to the top but also build a licensing foundation that we can work from without ambiguity or risk for decades to come.