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'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.

Firefox 3 Arrays: No, You're Not Insane

I just spent 20 minutes in IRC with Wolfram staring down one of those situations where you keep swearing under your breath "println isn't broken....println isn't broken....println is NOT broken".

Catch this fun gem from FF3b2:

>>> typeof []
>>> var a = [];
>>> var b = new Array();
>>> a.constructor == b.constructor
>>> c = [];
>>> c.constructor == a.constructor
>>> d = new Array();
>>> b.constructor == d.constructor;
>>> b.constructor == a.constructor;


Extending dojo.query()

As you probably know, Dojo is layered, extensible, and our philosophy of "build with, not on" means that we give you all of the same tools and extension points that we use in our code for use by your app.

Dojo's got 2 "sides", namely the bits that make working with the DOM better and the bits that make writing idiomatic JavaScript faster and easier. Where the package and language utilities enable you to extend and modularize your JavaScript work, the widget, behavior, and query systems make working with the DOM similarly extensible. Writing widgets and behaviors is well-understood in the Dojo community, but extending the results of a dojo.query() call haven't seen as much attention. To rectify that, here's the two-minute version of how to write your own dojo.query() extension.

Step 1: grok dojo.NodeList

dojo.NodeList is the Array subclass which all dojo.query() calls return an instance of. Therefore, to extend the results of a dojo.query(), we really want to extend the dojo.NodeList class. Both dojo.query() and dojo.NodeList are available as soon as dojo.js is included in your page.

Step 2: extend NodeList the old-skool way

Instances of dojo.NodeList pick up properties from the prototype object of the dojo.NodeList class. Lets add an inspect() method which logs out the innerHTML of the nodes in the list to the Firebug console:

dojo.NodeList.prototype.inspect = function(){
    return this;

// now we can call it: dojo.query("#container > p").inspect();

// or via a direct instance: var nl = new dojo.NodeList(dojo.byId("container"), document.body); nl.inspect();

A couple of small things to note:

Step 3: modernize and package it up

We want to be able to use dojo.require() to manage this module, so we'll assume that our Acme module lives in the acme/ directly which is a peer of the dojo/ and dijit/ directories from the Dojo distribution.

Lets add a provide() so that we can require() our module and use a bit of Dojo's language tools to extend dojo.NodeList more tersely:

// this file located in:
//    acme/ext-dojo/NodeList.js

dojo.provide("acme.ext-dojo.NodeList"); // require() statements go here

dojo.extend(dojo.NodeList, { inspect: function(){ this.forEach("console.debug(item.innerHTML);"); return this; }, ... });

We can now include this module at runtime via dojo.require("acme.ext-dojo.NodeList") and use it as a part of a build which will significantly improve the performance of the application which needs the file. Dojo's infrastructure makes doing what's easy pay off in the long run for your application.

Note that the file name is acme/ext-dojo/NodeList.js, which might seem a bit odd at first glance, but the intermediate "ext-dojo" directory makes it blindingly obvious to anyone who sees the require() statement what's going on. You can't dot-access a variable named "ext-dojo", so we know that this isn't a "normal" module. Instead, it's an extension, which extends the dojo.NodeList class. Subclassing is often more trouble than it's worth, and discouraging people from extending the Dojo core objects seems lame. Instead, we use this convention to make it easy to understand what's happening when you look at any given Dojo project.

And that's it! Writing powerful extensions for query results is easy, and because your project is using Dojo, you can structure your extension as a module and gain the benefits of optimization for deployment via the Dojo build system and the ease of use that comes from not having to worry about what order you're including your files in. It's good to be using a tool that you can build with, not just on.

Big Questions On IE8's Big Progress

So IE is the first browser out of the gate to do something sane about rendering engine locking to content…and good on them for it.

Now we need to know a couple more details to see if it’s going to have real legs:

These questions need to be answered, and soon. If the IE team has just replaced one scarce resource for another, we’re not much better off over the long haul. It’s great news that the IE team is really implementing the “renderer selection switch” which many of us have dreamed of for so long…but having it continue to be global to the page or in other ways encourage contention on yet another single element in the document wouldn’t be stepping forward enough.

Roxer Goes Live!

So once upon a time, back when I had a "real" job, I used to do security (specifically webappsec) for a living. One of the shining lights in that world for a long time has been Jeremiah Grossman, and as I moved out to the Bay Area, I was lucky enough to meet him in person. We've kept up here and there, and while his company has grown at a furious rate, he's somehow found time to continue to publish important original research, travel more than any human really should, and generally kick ass....oh...and build an awesome Dojo-based product on the side.

Jeremiah and Lex must really not sleep, 'cause their new Roxer app makes me all giddy to play with. Yes, yes, you should separate style from content...oh fuck it all. When it's this easy and fun to build a web page, who cares? I loathe wikis, mostly because traditional wikis try to be "half-pregnant" about how what you write gets displayed. Roxer solves that essential failure in one easy step, and makes it enjoyable to boot.

Think of it as the anti-blogging tool. It's not set up with expectations that you'll be doing this or that with it, it's there for you to do stuff. I literally cannot wait until it's hooked up with some love to access web services and the like. It's not a programming platform, and maybe that's what's great about it. Can't wait to see how it evolves and how they'll open up the (apparently pluggable?) content type system.

Great work guys!

Older Posts

Newer Posts