Great article by @pchestek on “belt and suspenders…
Great article by @pchestek on “belt and suspenders…
A revised OSI “Open Source Licenses” page
When someone new to open source does a web search for “open source licenses”, the first page that comes up1 is opensource.org/licenses – making it one of the most important resources for newcomers to open source.2
Despite that, until today, all that a newbie would get when going to that page was two links: one to the list of approved licenses alphabetically, and another by category. This is obviously not ideal – it provides the newcomer with information useful only to an expert, so they lose; and OSI misses an opportunity to educate and inform, so we lose.
Because of this, in the middle of last year I sent an email to license-discuss proposing a revision to the page, and followed up several times in the second half of the year. Yesterday, I took the revision live.
Here is what the revision does, in a nutshell:
And what it doesn’t do:
If you’re interested in helping out with future changes, please join the list.
Licensing confusion is great! (for lawyers)
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
Showrunner and Show Bible? Or Cult?
I don’t currently do much heavily collaborative writing, but I’m still very interested in the process of creating very collaborative works. So one of the many stimulating discussions at Monktoberfest was a presentation by two awesome O’Reilly staffers about the future (and past) of authorship. Needless to say, collaborative authoring was a major theme. What particularly jumped out at me in the talk and the discussion afterwards was a nagging fear that any text authored by multiple people would necessarily lack the coherence and vision of the best single-author writing.
I’ve often been very sympathetic to this concern. Watching groups of people get together and try to collaboratively create work is often painful. Those groups that have done best, in my experience, are often those with some sort of objective standard for the work they’re creating. In software, that’s usually “it compiles,” followed (in the best case) by “it passes all the tests.” Where there aren’t objective standards all team members can work with – as is often the case with UI – the process tends to fall apart. Where there are really detailed objective standards that every contribution can be measured against – HTTP, HTML – open source is often not just competitive, but dominant.
On the flip side, you get no points for thinking of the canonical example of a single designer’s vision guiding the development of software. But Apple is an example that proves the rule – software UIs that are developed without reference to objective standards of good/bad are usually either bad, or run by a not-very-benevolent dictator who has spent decades refining his vision of authorship.
Wikipedia is another very large exception to the “many cooks” argument. It is an exception because most written projects can’t possibly have a rule of thumb so straightforward and yet effective as “neutral point of view,” because most written projects aren’t factual, dry or broken-up-into-small-chunks. In other words, most written projects aren’t encyclopedias and so can’t be written “by rule.”
Or at least that’s what I was thinking during the talk. In response to this, someone commented during the post-talk Q&A1 that essentially all TV shows are collaboratively written, and yet manage to be coherent. In fact, in our new golden age of TV drama they’re often more than coherent- they’re quite good, despite extremely complex plots sprawling over several years of effort. This has stuck in my head ever since because it goes against all my hard-learned instincts.
I really don’t know what the trick is, since I’m not a TV writer. I suspect that in most cases the showrunner does it by (1) having a very clear vision of where the show is going (often not the case in software) and (2) clearly articulating and communicating that vision – i.e. having a good show bible and sticking to it.
If you’re not looking carefully, this looks a lot like what Aaron has rightly called a cult of personality. But I think, after being reminded about showrunners and show bibles, it is important to distinguish the two. It is a fine line, but there is a real different between what Aaron is concerned about and skilled leadership. Maybe a good test is to ask that leader: where is your show bible? What can I read to understand the vision, and help flesh it out like the writer of an episode? If the answer is “follow whatever I’m thinking about this month,” or “I’m too busy leading to write it down”, then you’ve got problems. But if your leadership can explain, don’t throw the baby out with the bathwater- that’s a person who has thought seriously about what they’re doing and how you can help them build something bigger and better than you could each do alone, not a cult leader.
Thanking Contributors by Printing the MPL
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:
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
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 # __
AGPL is usually about free riding, not fragmentation or adoption
When I was at Monktoberfest, our esteemed host reminded me that I’d disagreed with his article “AGPL: Solution In Search of a Problem”, and nudged me to elaborate on the point. Here goes nothing. TL;DR: for most developers, AGPL is really about preventing free riding, not fragmentation – so as long as there is concern about free riding people will use AGPL.
Stephen makes a few key points in his article (mistakes in paraphrasing mine):
Let me take these in order.
Issue #1 is based on a misapprehension: I don’t think it’s correct to think of the purpose of any copyleft (Affero or otherwise) as preventing fragmentation. GPL has never prevented fragmentation – there have been forks of many GPL projects (and complaints about same) for about as long as GPL has been around. (*cough*emacs*cough*)
Critically for many developers, what GPL does attempt to prevent is free riding – taking a benefit without contributing back. GPL means any valuable improvements in forks (whether or not incompatible) are available to integrate back under the same license terms. This means you can’t “cheat” the primary developers by building your business around proprietary forks of “their” work – they can always reincorporate the valuable bits if they want to.
The frequent use of AGPL in commercial dual-licenses also suggests that free riding is the problem being attacked by strong copylefts, not fragmentation. The logic is simple: AGPL means users usually pay some cost (i.e., not free ride) to participate: either by buying a commercial license, or by sharing code. In contrast, if the goal was to limit fragmentation, the license would say something like “your patches have to be accepted back into the core, or else you have to write a check”, or even better “you have to pass a compatibility test, or else you have to write a check.”
It is important to note that “cheat” is in quotes above. In many cases, people have realized that maintaining proprietary forks isn’t actually cheating the primary developers. For example, in many cases, we’ve realized that forking primarily cheats the forkers. For example, many users of the Linux kernel have learned the hard way that running an old fork + a small proprietary module leads to very high maintenance costs. In other cases, the permissive license actually helps fund the primary developers by enabling an open-core model (even if those aren’t trendy at the moment). In yet other cases, the primary author is making their money from other tools or services and so doesn’t care if anyone free-rides on their open source components. 37 Signals and Rails are probably the poster child for this. And of course, much of the industry has simply gotten more mature and less possessive about their software – realizing that whether or not they are “cheated” is usually a silly concern.
This leads to my response to issue #2: in my opinion, the recent increase in permissive licenses is driven as much by the decreasing concern about “cheating” developers (aka free riding) as it is by increased interest in adoption. In that light, the use case for AGPL is straightforward: AGPL makes sense if you’ve got a good reason to be concerned about free riding (say, if your revenue is directly tied to the tool you’re choosing a license for). This is a decreasing number of people, for the reasons described above, but it’s still far from zero. For those folks, increasing adoption may not actually be useful – it’s a case of “we lose money on every sale, but we’ll make it up on volume”.
On Issue #3 (increased FUD risk): this certainly seems like a possibility, but in my practice, I’ve seen only a single instance of confusion caused by AGPL spilling onto other licenses, and it was quick and easy to clear up. There is certainly plenty of worry about AGPL, but the worriers are quite clear that this stems from requirements other licenses don’t share. Maybe there will be more confusion if/when someone drafts another Affero-style license, but it doesn’t appear to me to currently be an issue. (By way of contrast, the confusion about the various patent clauses, and who licenses what to whom when, is a recurring theme of discussion with any company that is both filing patents and doing open source.)
Finally it’s important to note that both my post and Steve’s are about the costs, benefits, and freedoms accorded to developers. As I’ve mentioned before, when thinking about what “problem” is being solved by a license, it’s always important to remember that for some people (particularly the authors of the AGPL) the analysis begins and ends with problems for users. A full analysis of that issue has to wait for another day (it may be reminiscent of bike helmets) but suffice to say that neither of us are attempting it here, and we should always be cognizant of that.
Format(ting?) of Forever
Mark Pilgrim had a great post1 a little while ago where he talked about Docbook as ‘The Format of Forever’, but HTML as the ‘Format of Now.’ He also argued that (since technical books were constantly outdated) generating technical books in the Format of Now instead of the Format of Forever made a lot of sense.
I’m working on a project that I’d like to see as a long-term, Format of (nearly) Forever kind of work. Specifically, it is my grandfather’s autobiography, which I’d like to see as a long-term enough work that I can give it to my own grandkids some day. As a result, I’ve been wrestling on and off with two questions: (1) what is the right ‘Format of Forever’ and (2) once you’ve chosen that source format, what is the best ‘Output Format of Now’? Thoughts welcome in comments; my own mumblings below.
Grandpa, of course, wrote in the ultimate in formats of forever: typewriter. I scanned and OCRed it shortly after he passed away using the excellent gscan2pdf2, and have been slowly collecting other materials to use to supplement what he wrote – mostly pictures and scans of his Apollo memorabilia, but also family photos, like Grandpa’s Grandpa, Lewis Hannum, pictured above.
I’ve converted that to what I think may be the right ‘Format of Forever’: pandoc markdown, plus printed, easily re-scannable hard-copy. I’m thinking that markdown is the right source for a couple of reasons. Primarily: plain, simple ASCII text is hard to beat for future-proofing. Markdown is also easier to edit than HTML3.
The downside with markdown is that, while markdown is terrific for a very simple document (like grandpa’s writing is) I’d like to experiment with some slightly non-traditional media inclusion. For example, it would be nice to include an audio recording of my brother at the 1982 Columbia Shuttle launch, or a scan of Grandpa’s patent. Markdown has some facilities for including other files, but they appear to be non-standard (i.e., each post-processor handles them differently). Even image inclusion and basic formatting often feels wonky. HTML would make me happier in that direction, I suspect. And of course styling the output is a pain, though I think I have various ideas on how to do that.
Speaking at Practicing Law Institute’s Open Source/Free Software 2013
I’m pleased to announce that I’ll be speaking at the Practicing Law Institute’s “Open Source and Free Software 2013: Benefits, Risks and Challenges” continuing education for lawyers in San Francisco in December. I did this last year (on a panel with the excellent Mark Radcliffe) and it was a lot of fun.
Topics will include:
I’ll be on a panel on the last topic (“Hot Topics”) with Larry Rosen and Karen Copenhaver. The rest of the speaker lineup is excellent as well:
I’m afraid it isn’t cheap, but it’s a full day of CLE, and (based on my experience last year) a good way for lawyers not familiar with open source to get up to speed quickly. (It’s also going to be streamed for those who aren’t feeling like pressing the flesh.)
List of Open _______
Because I think it might be alternately amusing and useful, I’ve decided to compile a list of Open things. Additions welcome in comments; or if you can point me to someone else who has already done this, I’d appreciate that too. I think the list is more interesting if it stays focused on organizations claiming to represent Open Something, rather than just individuals saying that X is open, but pointers in that direction welcome too (and maybe will also show up some interesting patterns). Bonus points if they have a standard for defining what “open” means in their context, or if they are just hilariously awful.
I know there are more, but this is all I can think of in a pinch this morning. Help?
A Quick Note on Conspicuous Text, also known as ALL CAPS
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.
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 drafted, 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
“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. :)
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!