Older blog entries for louie (starting at number 672)

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:

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.

Syndicated 2012-11-13 06:03:27 from Luis Villa » Blog Posts

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):

1. AGPL’s alleged benefit (the “problem that doesn’t exist”) is the prevention of fragmentation.
2. Permissive licenses are on the rise, so using a super-strong copyleft is counter-productive when you’re looking to attract developers.
3. By being so aggressive, it courts FUD about all open source licenses, which could be counter-productive to open source generally.

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.

Syndicated 2012-10-09 15:00:04 from Luis Villa » Blog Posts

Format(ting?) of Forever

Mark Pilgrim had a great post¹ 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 gscan2pdf², 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 HTML³.

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.

Thoughts? Tips?

1. vanished since I originally drafted this, but link kept for reference
2. Which, for the record, was roughly 1,000 times better than Canon’s bundled scanning crapware.
3. which is sort of pathetic; how come we still don’t have a decent simple HTML editor?

Syndicated 2012-09-10 14:30:14 from Luis Villa » Blog Posts

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:

•  Setting the Stage: An Introduction to “FOSS” and Copyright Concepts
•  Open Source Software and its Licenses
• License Enforcement and Avoiding Litigation
• Effective Business Practices in the Open Source Cloud
• Ethics: Conflict and Cooperation in Open Source Projects
• Royalty-Free Patents and Open Standards in Open Source Software
• Hot Topics: Critical Issues and Important Cases in FOSS

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:

• Daniel Berlin – Google
• Adam Cohn – Cisco
• Eileen Evans – HP
• Harrison “Buzz” Frahn – Simpson Thatcher
• Gabe Holloway – Leonard, Street and Deinard
• Mario Madden – Microsoft
• Gervase Markham – Mozilla
• Gwyn Murray – Matau Legal Group
• Marc Visnick – Johnson-Laird

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

Syndicated 2012-09-04 15:00:21 from Luis Villa » Blog Posts

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.

The list:

• Open Source (as far as I know, the first use of Open in this context?)
• Open Standards (originally defined by OSI; now being redefined as of this morning by Open Stand to generously include standards that aren’t what I would call open; i.e., that can require patent royalty payments)
• Open Hardware
• Open Knowledge
• Open Street Map
• Open Government
• Open Data (a variety of options for this, though no self-proclaimed standard-setting body that I can find)

I know there are more, but this is all I can think of in a pinch this morning. Help?

Syndicated 2012-08-29 16:02:08 from Luis Villa » Blog Posts

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 warranty¹ 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.² 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

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.

Syndicated 2012-08-19 16:42:38 from Luis Villa » Blog Posts

Open Source Initiative Board Meeting in Chicago

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

Syndicated 2012-05-19 21:36:01 from Luis Villa » Blog Posts

Joining the Open Source Initiative board of directors

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.¹ 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,² 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 :)

Syndicated 2012-03-19 23:09:55 from Luis Villa » Blog Posts

On the Importance of Per-File License Information

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.

Syndicated 2012-03-17 18:43:00 from Luis Villa » Blog Posts

The license term smorgasbord: copyleft, share-alike, reciprocal, viral, or hereditary?

I microblogged (diaspora, identica, twitter) the following statement a few weeks ago:

First new year’s resolution, 10 days late: I will use ‘hereditary license’ any time I am tempted to say ‘viral license.’

Surprisingly, this generated quite a few responses (on identica and elsewhere)- some people liked it, but many people had their own alternative to propose. So here are some longer-form thoughts.

There are four primary options that I am aware of when trying to find a one-word term for open source licenses that in some way compel distributors to also distribute code- i.e., the licenses called “copyleft” by those of us who have spent too much time with this stuff. The terms:

• Copyleft: This is the common name when speaking to other people experienced in open source, so it’s obviously the first choice when you know your audience has at least some experience in open source. But to an audience not already involved in open source (the only time I’m ever even vaguely “tempted to say viral”), the phrase is completely non-obvious. It has zero evident meaning. In fact, it can actively confuse: it could mean the reverse of copyright, which to most people probably means “no license” or anti-copyright altogether. So it’s really not a good word to use for audiences who aren’t familiar with open source- which is to say, most audiences.
• Viral: This is another old standby. Traditionally, the objection to this term has been that it is perjorative: no one likes viruses, so ‘viral’ is often seen as (and sometimes is) a deliberate attempt to frame copyleft licenses as inherently bad. That objection is certainly accurate, but I think there is another problem with this word: it implies that, like a virus, copyleft can spread to someone without their active involvement; you can “catch” it from the digital equivalent of being in the same room with someone, or not washing your hands. This isn’t the case – there must be a strong relationship between the copylefted code and the other code that might be required to be shared. This, to me, is where “viral” really fails to communicate. It makes people think that a copyleft is something that might “happen to them” instead of it being something that they have to be actively involved with.
• Share-alike (or the related word “reciprocal”): Oddly, neither of these is used much outside of the Creative Commons world. Neither of these are bad terms: they are reasonably value-neutral, and they both imply that there must be an actively chosen relationship between the parties, which I think is important. But to me they don’t capture the why of the relationship; it makes it sound like there might be a choice in the matter, or something you do because you’re a nice guy.
• Hereditary: Richard Fontana traced this back to at least 2004, so it isn’t new, but without doubt this is the least used of the various terms I’m discussing here. At least for the moment, though, and for general audiences, I’m leaning towards thinking it is the best option. First, it implies that there has to be a real, derivative relationship between the two codebases; it can’t just happen at random (like viral implies). Second, it also implies that once the relationship exists, further licensing isn’t a choice- you must pass it on to the next folks who “inherit” from you. (Share-alike/reciprocal might imply that you do this because you’re a nice guy, which isn’t the case, or that you do it back to the original sharer- which also isn’t necessarily the case.) The analogy obviously isn’t perfect, most notably because a mere redistributor who hasn’t created a derivative work that “inherits” from the parent work is still bound by the license. But I think on balance that it has the fewest tradeoffs.

So there you go, for the dozen people who asked, and the hundreds, nay billions more who don’t care :)

Syndicated 2012-02-03 02:14:21 from Luis Villa » Blog Posts