Category: mozilla

Forking and Standards: Why The Right to Fork Can Be Pro-Social

Luis Villa12 Comments

[I originally sent a version of this to the W3C’s Patents and Standards Interest Group, where a fellow member asked me to post it more publicly. Since then, others have also blogged in related veins.]

Blue Plastic Fork, by David Benbennick, used under CC-BY-SA 3.0.

It is often said that open source and open standards are different, because in open source, a diversity of forks is accepted/encouraged, while “forked” standards are confusing/inefficient since they don’t provide “stable reference points” for the people who have to implement the spec.

Here is the nutshell version of a critical way in which open source and open standards are in fact similar, and why licensing that allows forking therefore matters.

Open source and open standards are similar because both are generally created by communities of collaborators who must trust each other across organizational boundaries. This is relevant to the right to fork, because the “right to fork” is an important mechanism to help those communities trust each other. This is surprising – the right to fork is often viewed as an anti-social right, which allows someone to stomp their feet and walk away. However, it is also pro-social: because it makes it impossible for any one person or organization to become a single point of failure. This is particularly important where the community is in large part a volunteer one, and where a single point of failure is widely perceived to have actually failed in the past.

Not coincidentally, “largely volunteer” and “failed single point of failure” describes the HTML working group (HTML WG) pretty closely. W3C was a single point of failure for HTML, and most HTML WG participants believe W3C’s failures stalled the development of HTML from 1999 to 2006. For some of the history, see David Baron’s recent post; for a more detailed
history by the author of HTML5, you can look in the spec itself.

Because of this history, the HTML WG participants voted for permissive licenses for their specification. They voted for permissive licenses, even though many of them have the most to gain from “stable reference points”, since they are often the ones who (when not writing the standards) are the one paid to implement the standards!

An alternate way to think about this is to think of the forkable license as a commitment mechanism for W3C: by committing to open licensing for the specification, W3C is saying to the HTML WG community “we will be good stewards – because we know otherwise you’ll leave”. (Alternate commitment mechanisms are of course a possibility, and I believe some have been discussed – but they’d need careful institutional design, and would all result in some variety of instabililty.)

So, yes: standards should be stable. But the options for HTML may not be “stable specification” or “unstable specification”. The options, based on the community’s vote and discussions, may well be “unstable specification” or “no (W3C) specification at all”, because many of the key engineers involved don’t appear to trust W3C much further than they can throw it. The forkable license is a popular potential mechanism to reduce that trust gap and allow everyone to move forward, knowing that their investments are not squandered should the W3C screw up again in the future.

Information diet weekend

Luis Villa13 Comments

As a slight sequel to my “feed reading is an open web problem” post, so far this weekend I have taken the following information diet steps:

RSS feeds: 610→339 (and counting).

Based on Google’s stats, I’d probably read about a million feed items in Reader. This is just too much. The complaints about attention span in this piece and in The Information Diet1 rang very true. Reader is a huge part of that problem for me. (Close friends will also note that I’ve been mostly off gchat and twitter during the work day since I started the new job, and that’s been great.) So I’ve spent time, and will spend more time soon, pruning this list.

National news feeds: lots→~0; weekly paper news magazines: 0→2; local news feeds: small #? →large #?

My friend Ed put in my head a long time ago that national news is not very useful. It riles the passions, but otherwise isn’t helpful: you’re not making the world a better place as a result of knowing more, and you’re not making yourself happier either.2  So you’re better off reading much less national political news, and much less frequently: hence the two new on-paper subscriptions to weekly news magazines.

Besides allowing you to get off the computer(!), the time saved can also be used to focus on things that either make your life better (e.g., happier) or that give you actionable information to resolve problems. To tackle both of those needs, I’d like to curate a set of local news feeds. I’ll be blogging more about this later (including what I’m already reading), but suggestions are welcome. I suspect that will make me much happier (or at least less angry), and present opportunities to actually do things, in ways that the national news obviously never can.

Moved from reader→feedly.

The impending shutdown of Reader was obviously the catalyst for all this change; feedly seems not perfect but pretty solid. I continue to keep an eye on newsblur (still a variety of issues) and feedbin.me (no mature Android client yet), since feedly is still (1) closed source and (2) has no visible business model – leaving it susceptible to the same Reader shutdown problem.

“Two young children picket for the ILGWU carrying placards including ‘I Need a Healthy Diet!’ outside the Kolodney and Myers Employment Office” by the Kheel Center at Cornell University, used under CC-BY 2.0.

Steps still to come:

Separate the necessary from the entertaining

Joe pointed out to me that all news sources aren’t equal. There are feeds you must read in a timely manner (e.g., for me right now, changes in work-critical Wikipedia talk pages), and feeds that can be sampled instead. The traditional solution to this is folders or categories within the same app. But we’re starting to see apps that are optimized for the not-mission-critical entertainment feed stream (Joe specifically recommended Currents). I’d like to play with those apps, and use one of them to further prune my “serious feeds” list.  Recommendations happily accepted.

Improve publication

I do want to participate, in some small way, in the news stream, by creating a stream of outbound articles and commentary on them. I never used Reader’s features for this, because of the walled garden aspect. Many of our tools now make it easy to share out to places like Twitter and Facebook, but that means I’m contributing to the problem for my friends, not helping solve it. I’d like my outbound info to be less McDonalds and more Chez Panisse :) The tools for that aren’t quite there, but this morning I stumbled across readlists, which looks like it is about 90% something I’ve been looking for forever. I’ll keep keeping an eye out, so again: good suggestions for outbound curation tools happily accepted.

What else?

I hate the weasely “ask your audience” blog post ending as much as anyone, but here, I have a genuine curiosity: what else are friends doing for their info diets? I want to eventually get towards the “digital sabbath” but I’m not there yet; other tips/suggestions?

  1. capsule book review: great diagnosis of the problem, pretty poor recommendations for solutions [↩]
  2. It’s pretty much a myth that reading the news makes you a better voter: research shows even supposedly high-information voters have already decided well before they read any news, and if for some reason you’re genuinely undecided, you’re better off reading something like ballotpedia than a streaming bunch of horse-race coverage. [↩]

Why feed reading is an open web problem, and what browsers could do about it

Luis Villa43 Comments

I’ve long privately thought that Firefox should treat feed reading as a first-class citizen of the open web, and integrate feed subscribing and reading more deeply into the browser (rather than the lame, useless live bookmarks.) The impending demise of Reader has finally forced me to spit out my thoughts on the issue. They’re less polished than I like when I blog these days, but here you go – may they inspire someone to resuscitate this important part of the open web.

What? Why is this an open web problem?

When I mentioned this on twitter, an ex-mozillian asked me why I think this is the browser’s responsibility, and particularly Mozilla’s. In other words – why is RSS an open web problem? why is it different from, say, email? It’s a fair question, with two main parts.

First, despite what some perceive as the “failure” of RSS, there is obviously  a demand by readers to consume web content as an automatically updated stream, rather than as traditional pages.1 Google Reader users are extreme examples of this, but Facebook users are examples too: they’re no longer just following friends, but companies, celebrities, etc. In other words, once people have identified a news source they are interested in, we know many of them like doing something to “follow” that source, and get updated in some sort of stream of updates. And we know they’re doing this en masse! They’re just not doing it in RSS – they’re doing it in Twitter and Facebook. The fact that people like the reading model pioneered by RSS – of following a company/news source, rather than repeatedly visiting their web site – suggests to me that the widely perceived failure of RSS is not really a failure of RSS, but rather a failure of the user experience of discovering and subscribing to RSS.

Of course, lots of things are broadly felt desires, and aren’t integrated into browsers – take email for example. So why are feeds different? Why should browsers treat RSS as a first-class web citizen in a way they don’t treat other things? I think that the difference is that if closed platforms (not just web sites, but platforms) begins to the only (or even best) way to experience “reading streams of web content”, that is a problem for the web. If my browser doesn’t tightly integrate email, the open web doesn’t suffer. If my browser doesn’t tightly integrate feed discovery and subscription, well, we get exactly what is happening: a mass migration away from consuming (and publishing!) news through the open web, and instead it being channeled into closed, integrated publishing and subscribing stacks like FB and Twitter that give users a good subscribing and reading experience.

To put it another way: Tantek’s definition of the open web (if I may grotesquely simplify it) is a web where publishing content, implementing software that consumes that content, and accessing the content is all open/decentralized. RSS2 is the only existing way to do stream-based reading that meets these requirements. So if you believe (as I do) that reading content delivered in a stream is a central part of the modern web experience, then defending RSS is an important part of defending the open web.

So that’s, roughly, my why. Here’s a bunch of random thoughts on what the how might look like:

Discovery

When you go to CNN on Facebook, “like” – in plain english, with a nice icon – is right up there, front and center. RSS? Not so much. You have to know what the orange icon means (good luck with that!) and find it (either in the website or, back in the day, in the browser toolbar). No wonder no one uses it, when there is no good way to figure out what it means. Again, the failure is not the idea of feeds- the failure is in the way it was presented to users. A browser could do this the brute-force way (is there an RSS feed? do a notice bar to subscribe) but that would probably get irritating fast. It would be better to be smart about it. Have I visited nytimes.com five times today? Or five days in a row? Then give me a notice bar: “hey, we’ve noticed you visit this site an awful lot. Would you like to get updates from it automatically?” (As a bonus, implementing this makes your browser the browser that encourages efficiency. ;)

Subscription

Once you’ve figured out you can subscribe, then what? As it currently stands, someone tells you to click on the orange icon, and you do, and you’re presented with the NASCAR problem, made worse because once you click, you have to create an account. Again, more fail; again, not a problem inherent in RSS, but a problem caused by the browser’s failure to provide an opinionated, useful default.

This is not an easy problem to solve, obviously. My hunch is that the right thing to do is provide a minimum viable product for light web users – possibly by supplementing the current “here are your favorite sites” links with a clean, light reader focused on only the current top headlines. Even without a syncing service behind it, that would still be helpful for those users, and would also encourage publishers to continue treating their feeds as first-class publishing formats (an important goal!).

Obviously solving the NASCAR problem is still hard (as is building a more serious built-in app), but perhaps the rise of browser “app stores” and web intents/web activities might ease it this time around.

Other aspects

There are other aspects to this – reading, social, and provision of reading as a service. I’m not going to get into them here, because, well, I’ve got a day job, and this post is a month late as-is ;) And because the point is primarily (1) improving the RSS experience in the browser needs to be done and (2) some minimum-viable products would go a long way towards making that happen. Less-than-MVPs can be for another day :)

  1. By “RSS” and “feeds” in this post, I really mean the subscribing+reading experience; whether the underlying tech is RSS, Atom, Activity Streams, or whatever is really an implementation detail, as long as anyone can publish to, and read from them, in distributed fashion. [↩]
  2. again, in the very broad sense of the word, including more modern open specifications that do basically the same thing [↩]

Licensing confusion is great! (for lawyers)

Luis Villa55 Comments

I want to heartily unendorse Simon Phipps’ Infoworld article about Github and licensing. Simon’s article makes it sound like no one benefits from sloppy licensing practices, and that is simply not true. Specifically, lawyers benefit! I regularly get calls from clients saying “I have no idea if I’m allowed to use <project X>, because it is on github but doesn’t have a license.” When that happens, instead of money going to developers where it could actually build something productive, instead, I get to spend my time and the client’s money fixing a problem that the original author could have easily avoided by slapping an Apache license on the thing in the first place – or that github could have avoided by adding default terms.

So, support your local open source lawyer today – publish source code without a license!1

  1. Tongue firmly in cheek, in case that isn’t obvious. Seriously, lawyers are the only ones who benefit from this situation, except for that handful of seconds it took you to “git add LICENSE”. Always license your code, kids! [↩]

Thanking Contributors by Printing the MPL

Luis Villa5 Comments

As part of a general drive to get rid of stuff, I’ve recently become increasingly willing to part with my old books. This has been a painful process – books have many happy memories for me – but I think also a good and focusing one. As part of my emotional reaction to this, I’ve become increasingly interested in making beautiful, printed texts – things that stand up better to the test of time than the paperbacks I’ve been thinning out.

In 2010, as part of this process, I bought Typography for Lawyers, and incorporated some of what I learned from that into the HTML version of MPL 2.0. In 2011, as I was putting the finishing touches on the final draft of the MPL,  I attended the holiday fair at the San Francisco Center for the Book (neat Flickr stream), and ran across some work from Painted Tongue Press– beautiful broadside printings of poetry and wedding vows.

This gave me the idea to thank the most involved contributors to the MPL with a hand-made, printed copy of the text of the license.

The wonderful Kim Vanderheiden, of Painted Tongue, worked with me over the course of several months to plan this process, and then she and her team put them together. First, we designed the layout, not just of the text, but of the relatively unusual accordion-fold binding, which allowed the final product to be displayed like an A-Frame or by hanging the entire (very long!) thing from a wall. Then we picked paper for the text, and cloth and ribbon for the bindings (the ribbon symbolising both the fact that these are gifts and traditional bindings for legal documents). Kim’s team then hand printed them on their presses, and Kim used watercolors to paint the colored highlights (including the yellow highlighting that replaces the ALL CAPS text). Finally, they were bound.

The end result has been fifteen copies of beautiful, tangible, printed words, which I am now in the slow process of distributing to various contributors. I hope that this token of the maintainers’ appreciation for their assistance (in a variety of ways) is appreciated.

The thanks and colophon is as follows:

Thank You!

This revision of the MPL would not have happened without your  help. Please accept this hand-crafted printing of the license as a token of our appreciation, and a reflection of the effort and care you put into your contributions to the license.

The MPL Module Owners

Mitchell Baker
Harvey Anderson
Gervase Markham
Heather Meeker
Luis Villa

-o-

Colophon

The type was set in Equity by Matthew Butterick (typo.la/equity – used with permission of the typographer) and Droid Sans Mono by Google (droidfonts.com – used under the Apache 2.0 license). The book is printed on Somerset Velvet Radiant White and covered in Duo Cloth Birch.

Design, printing, binding, and painting were done with care by the excellent team at Painted Tongue Press, Oakland, California (paintedtonguepress.com).

This edition of MPL 2.0 was printed in August 2012 to celebrate the publication of, and thank contributors to, MPL 2.0. You are holding copy # __
of 15.

A Quick Note on Conspicuous Text, also known as ALL CAPS

Luis Villa32 Comments

[Quick followup: (1) Matthew Butterick, of Typography for Lawyers fame, has added a thoughtful comment that anyone reading the post should read; and (2) to be clear, nothing here is my original work or thought – it’s all a convenient, collect-in-one-place paraphrase of ideas from the excellent Manual of Style for Contract Drafting and Typography for Lawyers, both of which should be on the desk of every corporate lawyer.]

Anil Dash asked about ALL CAPS Friday, and then someone in my (very fun) letterpress class at the San Francisco Center for the Book asked me a related question. So here is a quick post on the lovely subject of ALL CAPS.

A copy of the MPL with yellow text instead of ALL CAPS.

The basic question: Why do lawyers use so much ALL CAPS and what can a normal human being do about it?

Some laws require that text in a form or contract be “conspicuous” – i.e., that they be made harder to miss. The most common example of this, in the US, are requirements that disclaimers of warranty1 be conspicuous, so that consumers don’t miss them. You’ve all seen these blocks, and most of you have skipped over them. In the US, the law that requires conspicuous text for warranty disclaimers is typically a descendant of the Uniform Commercial Code (“UCC”) § 2-316.2 Practically speaking, this kind of requirement makes sense – it highlights areas that legislators have decided are particularly important and so can’t be hidden in the nooks and crannies of a document.

Unfortunately, historically, the only easy way for lawyers to make text “conspicuous” on a typewriter was ALL CAPS. Unfortunately, at some point along the way, many lawyers confused the technology (typewriters) for what was actually legally required. And so this is where we stand now – many lawyers will insist that ALL CAPS are required, when they really aren’t.

So if not ALL CAPS, what actuallyisrequired? This varies from rule to rule, unfortunately. But in the UCC, conspicuous is defined as text a reasonable person “ought to have noticed”, which includes:

“(A) a heading in capitals equal to or greater in size than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same or lesser size; and

(B) language in the body of a record or display in larger type than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same size, or set off from surrounding text of the same size by symbols or other marks that call attention to the language.”

(From UCC 1-201(b)(10); same text also appears in UCC 2-103(1)(b)(i).)

The Mozilla Public License, which I recently led the revision of, uses two different approaches, both supported by the UCC’s definition of conspicuous text. In our HTML version, we use text “in contrasting … color to the surrounding text of the same size” – i.e., we color it yellow. (When printed, this comes out as a box around the text.) In our plain text version, we use text “set off … by symbols .. that call attention to the language.” In other words, we use hyphens and vertical bars (|) to draw a box around the text.

So that’s the bottom line answer: in many cases (and certainly in the most common use case by American commercial lawyers), ALL CAPS isn’t required; instead, something “conspicuous” is – which could mean using symbols, colors, font size, or any number of other typographical tricks to make things both visible and easier to read.

Is This Always The Case?

Unfortunately, while most American statutes in this area appear to follow the UCC and require “conspicuous” text, defined quite broadly, this isn’t always true. An interesting list of such exceptions is in the comments to this blog post. These are exceptions; not the rule, but lawyers should be aware of them. Many of the exceptions, interestingly, are where writers of rules have included text that must be included precisely in a form or contract, and the rule-writers have INCLUDED TEXT THAT IS ALL CAPS in their draft text. That is often bad form – but it’s important to follow the rules in such cases.

Citations That Are More Authoritative Than This Blog Post

You’re saying “this is all very interesting, Luis, but I can’t give your random blog post to my lawyer next time he tells me that my Terms of Use need ALL CAPS.” Well, here are what lawyers consider the best kind of citation – a citation to printed books with page numbers, one of them even a publication of the American Bar Association.

“A Manual of Style for Contract Drafting,” Ken Adams, at 15.32-15.41.

“Typography for Lawyers,” Matthew Butterick, at 86-89.

Each of these say (often with more style and detail than I’ve said here) basically the same thing – use ALL CAPS sparingly, if at all. To get a flavor for each of them without buying the books (though I think every commercial lawyer should have both of these books on their desks) the authors have each blogged on these subjects: Adams’ blog post is here and Butterick’s is here.

So Why Do Lawyers Still Use ALL CAPS?

Because we’re risk-averse. Until judges, legislators or our clients demand that we change, we will stick with what works (or perhaps more accurately in this case, we will stick with that hasn’t yet failed).

There are the occasional signs that judges are starting to wake up to the issue: In re Bassett, 285 F.3d 882 (9th Cir. 2002) says “Lawyers who think their caps lock keys are instant “make conspicuous” buttons are deluded”; Stevenson v. TRW, Inc., 987 F.2d 288 (5th Cir. 1993) endorses use of bold or larger type rather than ALL CAPS; and  California courts have even held that ALL CAPS text in an inconspicuous location in the document may not be conspicuous even though it is in ALL CAPS. Broberg v. Guardian Life Ins. Co. of America, 171 Cal. App. 4th 912, 922 (2009).

The judicial situation is helpful, but realistically, until more clients demand it, it’s not going to change. So here you go. :)

 

  1. i.e., the part where the contract says “this product I’m selling you could well be broken or unusable, and that isn’t my problem” [↩]
  2. The UCC is a ‘model code’ – basically, states copy the UCC, edit it as they see fit, and then use that for their own commercial code. e.g., UCC 2-316, in California, becomes California Commercial Code 2316, with similar but not necessarily identical text. [↩]

Open Source Initiative Board Meeting in Chicago

Luis Villa4 Comments

I’m celebrating the end of my portion of my trial by … spending all weekend in meetings, specifically the OSI’s annual face-to-face board meeting, which we’re holding this year in Chicago1. It’s been a very productive meeting so far, with lots of good discussion about both our vision and our plan for attacking the future. The organization still has a long way to go but there is a lot of potential here.

  1. Yes, during the NATO Summit. Perhaps not our best move ever. [↩]

Joining the Open Source Initiative board of directors

Luis Villa11 Comments

In the past, I’ve been known to say that skeptical things about the Open Source Initiative’s role in the open source world – usually arguing that OSI was doing the basics (license approval, open source definition) respectably, but also had a lot of potential that wasn’t being taken advantage of. I’m excited to announce that I’m now putting my money where my mouth is, and joining the OSI board of directors.

“Hello, My Name is Open Source” by opensourceway, used under CC-BY-SA license

I’ll write more about my goals for OSI (and for my participation in it) in the coming months, once I’ve gotten a chance to actually meet with the rest of the board and better understand the projects that are already underway. But right now I think it’s very important to note how I became a member of the board, because I think it says something important about where OSI is going, and about why I agreed to invest my time and energy.

Specifically, at FOSDEM, OSI announced that it was beginning to shift in part to an affiliate model, where open source organizations like Mozilla, KDE, and others would have input into OSI’s processes and decisionmaking.1 One of the first tangible outcomes of that process was to ask affiliate orgs to nominate board members. The result: Mozilla nominated me, and Eclipse nominated fellow new board member Mike Milinkovich. Because of this, our election is less about us,2 and more about taking very concrete steps towards an OSI with deeper ties to the broader open source community. And that, I think, reflects what OSI has not always been, but could be – a place where the best of open source can talk and work together to move common interests forward.

  1. Ask me how your organization can join! [↩]
  2. Though obviously I expect we’ll be great :) [↩]

On the Importance of Per-File License Information

Luis Villa20 Comments

After the release of MPL 2, the first request for MPL 2.1 came from someone who didn’t want to put copyright headers in individual files. The issue has recently reared its head in Apache as well, and I recently was asked related questions by a GPL user as well.

The main reasons given for not using per-file headers are two-fold:

  1. They’re awkward in short files. Many programming frameworks these days (most notably rails) are encouraging creation of many short files, so this is becoming a bigger problem than it was when per-file headers were first created.
  2. They’re not considered very relevant in languages or frameworks that are library-centric, especially those with package managers that are heavily used (like ruby’s gems). Again, many modern language frameworks include tooling that encourages this approach, so some developers are thinking “why can’t I just express the license once per library?”

The case for per-file copyright headers is put well, and succinctly, by Larry Rosen:

“[O]ur goal is to pass on any important IP information that might be useful … in the place(s) [downstream licensees] are most likely to find it.”

Larry’s comment makes two assumptions that I want to flesh out and support.

First, Larry assumes that the place where people are “most likely to find” licensing information is in per-file headers. It is true that in the best case scenario in many modern languages/frameworks, library-level is a great place to put licenses – in normal use, they’ll get seen and understood. But lots of coding in the wild is not “normal use.” I review a lot of different codebases these days, and files get separated from their parent projects and directories all the time. And then you have to use fairly complex (and often expensive) tools to do what should be a simple task- figure out what the license is. So, yes, modern frameworks should in theory reduce the need for per-file licensing information – but in practice, that is often not the case.

Second, Larry assumes that you actually want people to use your code. Lots of publishers of open source code seem surprisingly unconcerned by this, unfortunately. The functional, practical benefits of open source all start with someone else reusing your code, so if you’re publishing open source code at all, you should be concerned about making it easy for people to use the code you publish. Again, putting licensing information in each file can help make this easier, by making it easier for people to figure out their rights and responsibilities. (This is particularly true if you want commercial uptake, since so many commercial users of open source are getting more conservative about using source code that is not properly labeled and licensed.)((Larry also perhaps assumes you want people to respect your license when using your code; that is a surprisingly complex topic that I will try to address some other day.))

So, yes: if you want people to find your licensing information, and  to use your code, per-file headers are the way to go. They may not be ideal but they really are worth the effort.

Nominated for OpenSource.com People’s Choice Award

Luis Villa3 Comments

Based on my series of MPL posts for opensource.com, I’ve been nominated for a “people’s choice award” as a top contributor to opensource.com. It’s a nice little honor. That said, there are lots of folks on the list of nominees who have written and thought far more than I have this year- so you should go check out the list and vote for one of them instead :)