lu.is

"What ride?": where libre software could go after LLMs

Sat, 07 Nov 2026 00:00:00 GMT

Blog post collecting in one place some thoughts from social media (original post).

Armin Ronacher ran the same poll on Twitter, Bluesky, and Mastodon: “Do you still write more than 20% of code by hand?” The answers: 8.4% yes on Twitter, 26.3% on Bluesky, 65.1% on Mastodon. Obviously some caveats here, but still: same question, three very different worlds.

My reaction, roughly: sob. A lot of very, very good FOSS people — people whose hearts and pre-LLM skills are in exactly the right places — are on Mastodon, and on the 65% side of that poll.

In quoting Armin, I said I want to bring those folks “along for this ride”. Sumana asked the right question in reply: what ride, specifically? This post is an answer: what has me excited about user freedom, post-LLMs? where do I think we’re going? where do I want the hardest-core of hard-core FOSS zealots (complimentary) to come along?

Here are some of the highlights:

#1. Freedom 1, for real this time

Most important: I think we can get to a world where most users are actually empowered to take advantage of Freedom 1 — the freedom to study how a program works and change it to do what you want.

For forty years that freedom has been real in law but mostly theoretical in practice. You had it if you could also build the thing, navigate the codebase, and maintain a patch. Even with a CS degree, for anything but the most trivial changes, I basically never had that. Now my daily-driver desktop is a heavily customized GNOME, I read social through an aggressively forked phanpy, and probably others I’m forgetting. That’s the promise we always wanted and I’m living it right now.

#2. Higher quality, because best practices can become actual practices

A lot of FOSS best practices were always good in theory, but proved too expensive for volunteers (or really anyone) to implement comprehensively. Among those: test-driven development, accessibility testing, and especially formal methods. These kinds of things have stopped being impractical and have started becoming real.

#3. Collaboration can better include non-coders?

The nature of collaboration is going to change. Lots of that may be for the worse in a variety of ways (about which some other day). But on the plus side, on a front I care a lot about: we now have a loooot of ways of bringing in the opinions (and skills and efforts!) of people who don’t code. Designers, writers, domain experts, the people who file the bug reports.

One thing I worry a lot about here: there was a golden era where open source got better, quickly, because we were much better about listening to our users though public issue trackers. That window closed. Now I fear it will go the other way: proprietary vendors are frantically building tools to help them synthesize user feedback and turn that into shipping code at lightning fast speed. If we don’t get there first, with open processes, we lose one of the few structural advantages open collaboration has left.

#4. A Big Bad Guy again

Half-joking, but: FOSS benefits a lot from having a clear antagonist, like Bill Gates in the old days. We have Bad Guys again, and they’re worse than the old ones: more concentrated, more capital-intensive, and more willing to take what’s open without giving back. That’s a reason to engage, not to opt out.

And yes, that means I’m advising using the tools the bad guys are giving us. We’ve done that before to advance our goals (emacs and gcc were written on proprietary kernels; Firefox on Windows was how we beat IE) and we are going to have to do it again. That’s not great — but that should motivate us to fight and win, not to quit.

#5. Finally retiring unsafe-by-design C and C++

Rewriting our decades of legacy, unsafe-by-design C and C++ in modern, safer languages is now a tractable task. That once seemed so impossible that Vernor Vinge, a computer science professor, made Unix-era buffer overflows still lurking in the year 8000 a plot point in A Deepness in the Sky. Vinge’s joke was that nobody would ever pay down that debt, even given 1,000 years. Now we can, making all our users more secure — and, if we’re serious about it, giving us a new generation of programmers who can work in our codebases.

#So — how do we bring folks along?

None of these rides is guaranteed to happen, let alone to turn out well. They’re all possibilities — and that’s exactly why I want a big tent of people coming along to steer them, and to keep us honest.

What a Harness Can Promise That a Prompt Can't

Fri, 25 Sep 2026 00:00:00 GMT

Specialized work calls for specialized tools. “Early Surgical Tools” by Double—M, CC BY 2.0.

A short follow-up to What Is a Harness?, prompted by a question on Bluesky.

On Bluesky, my friend N Sims asked a good question about AI agents: how much can you trust the logs? If an agent says “I read the source and it supports the claim,” is that true, or is it just more generated text?

My short answer: it depends almost entirely on the harness. Explaining why this is true is a good practical example of how different harnesses can lead to different results. If you are “just” prompting a standard chat tool, you get very few hard guarantees. The model’s account of what it did is written by the same model that did it. But a harness can move some of those promises out of the model and into ordinary, boring, deterministic code. Here is what that looks like for one task I have been experimenting with: checking whether a Wikipedia citation supports the sentence it is attached to.

#The naive version

The naive approach to citation checking is a prompt to a chat tool:

Read the source at this URL. Does it support the claim “X”?

You will get an answer. It will usually sound confident. But because a chat tool is by nature a general purpose harness, it doesn’t create any of the guarantees you would want for citation checking, like:

that the model fetched the URL at all;
that the fetch worked, instead of returning a 404 page, a paywall, or a cookie banner;
that the answer came from the page, rather than from what the model remembers about the topic;
that the “I read the source” in its reply describes something that happened.

Most modern chat harnesses will attempt to fetch pages, and often they’ll get it right. The problem is that you can’t tell, from the outside, which answers are right. The instruction “read this source” is a request, not a guarantee.

#Harness step one: fetch before the model

Someone building a harness optimized for cite-checking, in contrast, could ensure that the fetching is guaranteed. The harness, using traditional deterministic software, would:

Fetch the URL.
If the fetch fails (the page doesn’t exist, returns a 404, or is empty), stop. Record “source unavailable.” The model never sees this citation.
If the fetch succeeds, extract the text and hand that text to the model, along with the claim.

This is dull code. That’s the point. Now “the source was fetched, accessed, and handed to the model” is a fact the harness can log, because the harness did all that, in a loggable and trustworthy way. The log entry is written by the program, not narrated by the model. And the most embarrassing failure—a confident “yes, supported” about a page that doesn’t exist—can’t happen, because a page that doesn’t exist never reaches the model.

In the first post’s terms, fetching is integration, handing the model only the fetched text is context management, and stopping on a 404 is error recovery.

#Harness step two: make the model show its work, then check it

On the output side, don’t make the naive ask to the LLM of “does source X support claim Y?” Ask instead, to the combination of deterministic code and non-deterministic LLM:

Does source X support claim Y? If yes, give the exact passage from X that supports it.

Then, again in ordinary code, search the fetched text for that passage. If the passage isn’t there, the harness doesn’t report “supported.” It reports a failure, or asks the model to try again, depending on how you want to structure the work. In the first post’s terms, this is ground-truth validation, with error recovery when the check fails.

A model can still misjudge whether a real passage supports a claim. But it can no longer invent a supporting quote and have that quote shown to a human reviewer as if it were real. The human reviewer also gets something useful: a highlighted passage to check, rather than a verdict to take on faith.

#This is a lot more work

Building a harness that does all this subtle, persistent, deterministic checking is a lot more work than the naive approach, unfortunately. Some examples from trying it:

Models paraphrase their own “exact” quotes. They fix typos, change curly quotes to straight ones, and drop words in the middle. So the “search for the string” step has to tolerate formatting noise (whitespace, dashes, capitalization, ”…”) without tolerating actual rewording. Drawing that line is careful, fiddly work.
Fetching is its own hard problem. A page that loads fine in your browser can come back empty to a script, or come back without the table that holds the key fact.

None of this is visible if you only type into a chat box. That is also the point: the naive approach looks cheaper because it hides these failures instead of catching them.

#Back to the question

So: can you trust an agent’s logs—in other words, can you get what the first post called observability? For the parts the harness does in code—fetching, checking that a quote exists, recording what happened—yes, about as much as you trust any traditional software’s logs. For the parts the model does—judging whether a passage really supports a claim—no more than you trust the model. A good harness is honest about which is which.

That split is what I meant in the first post when I said permissions and guardrails should “live in deterministic code (and outside the inner loop).” It’s also why I think the most important question about LLMs and Wikipedia is not “can a chatbot check citations?” but “which parts of citation-checking can we take away from the chatbot entirely?”

friendsof.wiki: a quick changelog

Thu, 20 Aug 2026 00:00:00 GMT

I’ve updated friendsof.wiki. Quick changelog since my last blog post:

The 1903 Wright Flyer on display at the National Air and Space Museum, CC0. One of 19 openly licensed images on the museum’s own digital record of the aircraft.

Added an FAQ. Might (or might not!) be a little more clear what I’m trying to do here. TLDR: mostly experiment and learn about how open data works (and doesn’t) in the wild in 2026.
Single objects, held at a single museum, merge the museum data into infoboxes. As a different approach from the round of experiments, which hoovered up as much data from as many different places as possible, I wanted to see what it would look like if we trust and prioritize the institution that holds a specific object. For The Night Watch, the Spinola Hours, or the Hours of Jeanne d’Evreux, the page now leads with the museum’s own catalog record and every other partner sits the page out. I don’t think that is a good long-term position (many other partners have information about Rembrandt, for example!) but it’s been a good thought experiment for me, and I learned a lot about how infoboxes can/can’t interact with Wikidata that I hope to be able to put into practice soon.
Fixed how I show copyright information. Getting copyright correct is important to Wikipedians, for good reason; I tried to make it easier to see what we know from “pure” metadata, including where the upstream source and Wikidata conflict. I already knew this was going to be a point of conflict, so not necessarily much learning from this.
I added glTF support. Wikidata doesn’t have a ton of glTF data points, basically all from the Smithsonian. I added support for species articles, like the common seadragon. Learning: there is some nifty stuff out there! would be nice to get this onto the main Wikipedia.
I added DigitalNZ as a data source. Based on a discussion with Stuart Yeates, I added DigitalNZ as a source. It helps some New Zealand articles, but is high noise on others (like Apollo 11). Shows that if we want to go this route at scale, curation looks different — but is still very important.
I probed IIIF more. IIIF is still pretty limited, because many of the IIIF partner institutions have challenges—eg one had a broken SSL cert; another had broken licensing data (in an otherwise exemplary data set). But where it is present, it can be rich. This is a shame; it’d be great to support this better on-wiki, but it may be hard to justify.
Closed approximately 200 SonarSource issues, including 24 complexity issues. I genuinely enjoy using SonarSource (disclaimer: my employer) with LLM-generated code. It’s clear these tools can over”think” code. So when Sonar spots a complexity issue and the bot fixes it, I feel a lot better about the long-term maintainability of the codebase.

I’m probably going to let this sit for a bit; I think most of the next steps are to do with learnings of how to start bringing this back into Wikidata — and from there onto the real wiki — in an impactful way.

Wikipedia and friends: learning through code

Thu, 06 Aug 2026 00:00:00 GMT

As part of my thinking on the CC board about open, the state of the web, and the state of Wikipedia, I’ve become increasingly interested in how Wikipedia relates to the rest of open knowledge. Is it connected? Is it possible to connect it?

Inspired by that question, and some conversations I had at Wikimania, I have built friendsof.wiki. Friendsof tries to transform linked data into surfaced content from “friends of open”, using a Wikipedia article as the framework to showcase the entire world of open.

The Night Watch (detail) by Rembrandt van Rijn, 1642, Rijksmuseum, public domain. Fetched via the museum’s Linked Art API — one of the friends this post is about.

This is still an experiment, a learning tool, and a WIP. For performance reasons, I don’t think it can become a “real” way of browsing the wiki, and there is so much linked data that usable automated curation and layout is a hard problem! But that’s OK: like I said, a lot of my goal was understanding the state of the open knowledge graph; if this specific implementation is not productizable that’s fine. (That said, if you like it and want to contribute in some way, or have questions, it’s on my github.

So here, some lessons I learned while building it.

#The good news

My post on the conflicting graphs of open told an interesting story: Wikipedia’s web traffic is falling off a cliff, but by many other metrics open knowledge (like arXiv) and open creation (like GitHub) is thriving. There are many partners from both new forms of knowledge (like iNaturalist and GBIF) and traditional institutions (like the Met and the Rijksmuseum). In many ways, open knowledge has never been healthier.

Toying around with this has confirmed the underlying story for me: there’s so much great stuff out there, reliably and algorithmically reachable from open’s flagship. My favorite finds from this, so far: 3d models of the Apollo spacecraft from the Smithsonian; this 1970s remix of American Gothic in support of the Equal Rights Amendment; and the excellent presentation of the Night Watch at the Rijksmuseum.

This does require that Wikipedia embrace that role of open flagship, though. At least in theory, we’re already there; in 2017 we said that:

By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge, and anyone who shares our vision will be able to join us.

A lot has changed since we wrote that, but I still find that vision quite inspiring. So… how are we doing?

#Our opportunities

I think there’s a lot we can do that would help us build towards the vision laid out in the movement strategy.

#We need to break down some barriers to partnership

Bluntly, our current rules about third-party content and links mean that at best we are going to be a bad partner, because we deliberately force almost all partners to either dissolve into Commons (because we prohibit third-party images in articles) or become a mere line of text. As long as that’s our default position, “join us” really means “abandon your own identity” — it isn’t partnership, it’s absorption.

To be fair, this is not an easy problem to solve. Other sites really do have quality challenges — we don’t want to have bad (or worse, spammy) content. Picking winners and losers would not be fun — if 37 museums have Rodin sculptures, how do we know who to link to? Third-party javascript on the site has both technical and legal challenges — we want our privacy guarantees to really stick. Etc etc. But all of them seem navigable — if we have the will to do it.

#We’re missing opportunities to promote free knowledge in user-friendly ways

By refusing to make any choices at all, and instead presenting an unprioritized scroll of (currently) 572 options, our ISBN page has long been a lesson in user-hostility. José Rizal’s page, as one example, has one ISBN-linked book he wrote. The citation gives you two options: the Google Books link, or the ISBN, styled exactly the same, landing on that 572-link scroll. His bibliography in the same article has a similar user-hostility problem—not linking helpfully to the books themselves. By pulling from Open Library, we can do better, on both counts.

Wikipedia’s bibliography for Rizal (top) names both novels and shows neither cover. friendsof.wiki asks Wikidata for his Open Library author ID instead — getting links directly to his most important books.

This experiment also led me to learn about {{Taxonbar}}. It lists 23 different places to get information about taxons, including GBIF and iNaturalist. This would be fine except those are two of the fastest growing members of the “ecosystem of free knowledge” we said we were going to promote in 2017 — this template really should highlight them, perhaps paralleling what we do with some open-access links.

The same two identifiers, before and after.

Putting together this screenshot made me see several important data and usability regressions between the usual infobox and my demo “infobox” replacement. That’s OK; when I fix them in my demo, they’ll be fixed for every article about a species, not just “Monarch”.

This would have been a lot harder 10-15 years ago: we would have been doing our users a disservice by linking to bad sources just because they were free. But these two projects are now huge, as is Internet Archive’s giant set of old public domain book scans, among others. So the choice is now different, and we should think about how to serve our readers while also supporting our strongest possible allies — especially in this challenging moment for all knowledge.

#Wikidata matching needs love

Magnus and others in the GLAM community have done some great work, but there is much more to do. As just one example, right now from my data spelunking it seems that for small catalogs, sometimes someone falls in love and grinds through it. (If your catalog is under 1k links, 58% are likely to be matched.) Large catalogs — the most impactful, across the widest swathe of knowledge — don’t get finished. (If your catalog is over 1M, 6% are matched.) There are ~145M entries unmatched in mix’n’match, and more databases that have simply never made it in.

This is not a critique of mix’n’match or the people who use it. I think it’s just a natural outcome of this sort of data matching being both hard and sort of boring to do literally millions of. So how do we apply tools, gamification, etc., to fix that?

#Treating live-data-checking as a first-class source

It appears we have challenges about keeping matched data up-to-date. Two examples I hit while building Friendsof: Wikidata’s iNaturalist ids are in some ways a success story, with ~626k matches through Mix’n’match catalogue #238. Our import is still working from a snapshot from 2021, but since then iNaturalist has reorganised fungal taxonomy, and as far as I can tell none of that has been synced back to Wikidata. Similarly, GBIF re-keyed its taxonomy this year. The original property, P846, is now labelled “GBIF-species-ID (before 2026 update)” and has three million uses. Its replacement P14607 has less than a thousand uses in Wikidata, so Taxonbar now supports both.

Neither of these are the end of the world, but they do suggest we need systematic and ongoing automated review of links to partner orgs. One-time imports are not going to be enough if we want to be a good peer node to our partners in open knowledge.

#Tools are our friends

We live in a golden age of text processing, and so filling the gaps left by Mix’n’Match is exactly the sort of boring-at-scale work machines could be doing. But that runs square into Wikidata’s trust issues with bots. Part of this is inevitable and unavoidable, and can only be solved by careful work on the part of bot authors. But it seems to me like we’re leaving low-hanging fruit on the floor by not implementing mandatory property constraints. (We know such checking can improve quality: YAGO imposed schema.org typing on Wikidata, and found 132M type-inconsistent statements. Surely some were false positives, or fixable, but it still suggests a huge opportunity for us to improve our quality.)

#We must grapple with licensing ambiguity

Some of our best partners should be archives and libraries — who rely heavily on fair use and similar exceptions. And some of our most exciting partners are big data repositories, where licensing is an inherently complex and ambiguous endeavor. Linking out to them will point us to things (like the 1970s ERA poster above, and complex taxonomic data) whose license status is obviously educational in nature, but not vetted in the same way Commons is. This is going to be uncomfortable for us; we like to pretend that licensing is a clear binary and that’s… not how things are, or ever could be, for many of our closest ideological allies.

I do not have a good proposal for what that would look like — but it is clear we will need to be flexible in ways we have not been in the past. (And this is one area where our partners really could perhaps come towards us, cleaning up their metadata to help make us more comfortable.)

#What can we do, at the highest level?

The previous points are somewhat nitpicky, operational stuff. Here are some of my bigger takeaways on what we should aspire to change to help us meet the challenges of the current moment.

#We need partner-level equivalents of Assume Good Faith and Be Bold

The primary curation model we offer to our partners is slow manual addition: prove a partner belongs, one template/one link at a time, forever. That’s not unreasonable: we need to have high standards. But we have the opportunity to partner with some of the most esteemed institutions on earth, and some of the fastest-growing free knowledge projects. They deserve our patience — the same patience we show human editors. And they need to see results, not eternal grinding of gears.

In short, I suspect we need partner-level versions of both AGF and BOLD: find good-faith partners, boldly include their content, with linking, by default, then curate actively. That would of course have to include helping them improve their data and licensing quality — but would also have to include us committing to being a good partner when they do that work. The evidence suggests that second part is still a work in progress.

#The best thing we can do for Wikidata is surface it

I didn’t start this experiment to learn about Wikidata’s quality—my focus was going to be on how to build bridges from it to the rest of open. But the act of transforming invisible links into visible content uncovered so much that I can work on.

Mostly, this is great: stuff to do! Improvements to make! But it also made it very clear to me that, like most platforms, the best way to improve the quality of the platform is to build something that really pushes the platform hard—something that is not just visible to the builders, but visible to many users. Wikidata has not historically done that very well (often for perfectly good reasons).

Historically, enwiki’s interpretation of this mixed quality is “therefore we can’t rely on it”, which becomes circular: our biggest human surface, with the most editors, can’t use it; therefore it gets few editors; therefore it doesn’t get improved; therefore our biggest human surface doesn’t use it.

I would take the opposite view: the only way we can improve the quality of enwiki and wikidata, together, is by using the data. The first step to fixing problems is to bring them into the light.

There’s a lot of hard detail here, of course — I’ve got the outlines of a whole post on the many small things I’ve already found. I suspect a team of editors working together to do this embedding could do a lot of good quickly. If you know of such a group, let me know! I’d love to join!

#Recommit ourselves to partnership

It’d be great if we can transition from an island of open to being part of an archipelago — a connected network. I hope this little experiment gives other folks some ideas on how to make that happen. I know it has for me!

#LLM usage

I built friendsof.wiki with Claude Code.

What Is a Harness?

Mon, 22 Jun 2026 00:00:00 GMT

Harnesses are a very old technology. Here, a Viking Age harness fitting (selbågskrön), Historiska museet/SHM. Photo: Christer Åhlin & Gunnar Andersson. CC BY 4.0.

First in (hopefully?) a series on harnesses for the open knowledge commons. Today: what is a harness anyway?

#The future (and present) of LLMs isn’t chat

Hundreds of millions of people use “AI” as chat (like ChatGPT) or search (like they used the box on google.com for two decades). In other words, for most people “AI” looks like “put a question in a box, and get back an answer.” That’s not wrong—but it is importantly incomplete.

This post will try to define and think through the LLM usage model many software developers are beginning to default to, and explore as a design space: “harnesses”.

#The engine (LLMs) and the car (a harness)

Software developers who have used the leading tools for AI-assisted coding, like Claude Code, know that the large language model itself is only part of what makes the experience work. In the core of these tools, a model writes code—but there is an increasingly complex infrastructure around that model. This infrastructure decides which files to read and load, writes and run tests, keeps records, checks permissions, and generally keeps track of what is going on. In these posts, I’ll call that infrastructure a harness.

To put it another way: the LLM is an engine. The harness is everything else that turns a raw engine into a useful vehicle—the wheels, the brakes and seatbelts (very important!), the dashboard, the GPS, etc.

The distinction between LLM and harness matters because most public conversation about “AI” collapses the two. Debates about what AI can and can’t do, whether it’s trustworthy, whether it is overhyped: these are often really debates about specific harnesses wrapped around specific models. A 2024 model in a well-designed harness can match or outperform a 2026 model. A brilliant model in a lazy harness can easily produce sloppy work—and in fact you can think of early “chat” models as very lazy harnesses, sort of like attaching a rocket engine to a surfboard.

#Why does this matter to open knowledge?

The question “can LLMs improve the quality of Wikipedia?” is hard to answer in the abstract, and usually pointless to argue about. A much better question, I think, is: “what would a harness for contributing to Wikipedia look like, could it provably improve Wikipedia’s content, and how could it support the community’s values?” That’s a question that is tractable, testable, and worth arguing about.

This (hopefully!) series will try to work through that question. To do it constructively, we first need shared vocabulary for what a harness is and what it contains.

#A rough anatomy of harnesses

Harnesses vary, and are in early days. There are some common themes, though. In particular, I find a helpful way of thinking about it is to look at three levels:

inner loop: the tight cycle where direct creation actually happens
outer scaffolding (or sometimes outer loop): the persistent infrastructure that makes the inner loop safe, auditable, and improvable over time. An assumption in software, which may or may not be true in open knowledge, is that the inner loop runs many times for each run of the outer loop.
the ecosystem: arguably, a special case of the outer scaffolding is the outside “world” in which the harness operates (such as GitHub in code or Google Book Search or Internet Archive in knowledge) which provides additional constraints or opportunities.

Not all harnesses include all of these components; it’s still such early days that when I first started this draft there wasn’t even a good definition I could find for it in coding, much less other forms of knowledge work. (If you’re interested in coding, part of why I picked this back up is because of this good summary.)

#The inner loop

In a harness’s inner loop, work happens in a cycle, roughly: plan → act → validate → replan. The components that implement this cycle:

Planning translates user intent into actionable units. A user typing “improve this article” becomes a list of specific checks to run and edits to propose.
Coordination dispatches work to sub-agents, tools, and sometimes different models. When the harness uses more than one model — say, an open-weight model for bulk work and a stronger proprietary model for hard cases — coordination includes routing: deciding which model handles which subtask.
Integration is the domain-specific knowledge of how to interact with the world. For a code harness, this is the Unix command line, git, language toolchains. For an office harness, it’s the guts of docx and xlsx. For a commons harness, it could be wrappers around MediaWiki’s APIs, Wikidata’s data model, Flickr, and bibliographic identifier systems like DOI.
Context management decides what goes into the model’s window for this specific task. It’s distinct from memory: context is ephemeral and task-scoped. For code, codebase indexing, retrieval, file selection all live here. In practice this is often the component that most determines whether the harness feels smart or stupid.
Validation checks whether the work actually succeeded. More on this below — it’s the component with the most interesting design space, and is most important for building trust.
Error recovery and escalation handle failure. Retry, reroute, degrade, or stop and ask a human. Getting this wrong produces the “agent spins in circles until it runs out of budget” failure mode.

#The outer scaffolding

Around the inner loop sits infrastructure that persists across tasks and sessions:

User interface. This is most often chat, but not necessarily. Different domains call for different kinds of integrations, review queues, dashboards, custom visualizations. The UI shapes what kinds of work are easy to ask for and easy to trust.
Memory. Persistent state across sessions: what the harness has learned about this codebase, this contributor, this project’s conventions. Distinct from context management — memory is what the harness remembers, context is what the model sees right now.
Permissions and guardrails. What the agent can do unattended versus what requires human approval. Sandboxing, read-only modes, approval gates for destructive actions. This must, as much as possible, live in deterministic code (and outside the inner loop), because the LLM cannot ultimately be trusted.
Observability. Logs, traces, diffs, audit trails. What the agent did and why, inspectable after the fact. Essential for trust, essential for debugging, essential for community review.
Evaluation of the harness itself. Test sets and benchmarks for the harness. How do you know version N+1 is an improvement over N?

#The outside world

A special case of the outer scaffolding is the literal outside world. A harness can act to the extent that the outside world—the environment into which the harness is deployed—allows it. For developers, think of Debian’s unstable/testing/stable progression. A code harness might operate against a scratch branch before a main branch. A commons harness might write to a staging mirror before production Wikipedia. This substrate question turns guardrails from “can we trust this edit” into the more tractable “what’s the promotion pathway from experimental to canonical.”

#Validation is a design space, not a checkbox

One component deserves more attention, because it’s where harnesses for the commons will earn or lose credibility: validation.

In software development, validation often has a ground truth to check against — the tests either pass or they don’t. For claims in a knowledge commons, ground truth is rarer. “Is this sentence well-sourced?” has no unit test. And yet a harness can still bring a meaningful range of approaches to bear:

Ground-truth validation where available — does the ISBN checksum, does the DOI resolve, does the claim survive a Wikidata schema check.
Adversarial validation — a second agent, possibly a different model, tries to break or critique the output. (This can be complex, or can be as simple as “comment on this like the most critical jerk you can be”.)
Multi-model voting or ensembling — have several models independently evaluate. If they have consensus, that is useful signal; if they disagree, that’s a flag for human review.
Human-in-the-loop — the escalation case, expensive but sometimes necessary.

The interesting argument for harnesses isn’t that any single strategy is sufficient. It’s that all of them together, orchestrated, can reach a level of rigor that no individual reviewer could apply at scale. Choosing which strategy to use when is a design decision, not a one-time commitment. (Future posts will return to this.)

#Open incrementalism

It’s worth noting that a well-designed harness makes “moving toward open components” a tractable, incremental goal rather than an all-or-nothing switch. Because a harness is, by design, modular, open components can be swapped in as they mature. This will be particularly important for open models, which can already be used quite reliably for citation checking but probably not for other drafting tactics yet.

This ability to incrementally become open is, I think, one of the strongest arguments for taking the harness framing seriously in commons work. It transitions the question from “is this chatbot open” (rare, especially with high quality) to “is this a system that we can push steadily towards open, component by component”. That’s a question I feel comfortable we can move forward on.

#Why the harness framing matters for the commons

Commons communities have good reasons for skepticism about LLMs. Wikipedia’s editors have seen hallucinated citations, fabricated articles, promotional drift, and genuine damage to existing content. Many have concluded that LLMs are categorically incompatible with the community’s values around verifiability, neutrality, and human-scale deliberation.

The harness framing doesn’t dismiss any of that—it reframes the question. The issue with an LLM-generated Wikipedia article isn’t that a model wrote it; it’s that the model wrote it with no planning, no validation, no provenance, no memory, no observability, no guardrails, no evaluation — in other words, with no harness. It’s not surprising the result is unacceptable. An unharnessed engine running at full throttle in a neighborhood is always going to do damage.

The productive question for open, then, is whether it’s possible to build harnesses rigorous enough to meet community standards — and whether doing so is worth the effort. That’s an empirical question, and one I hope to answer with more experiments.

The next post turns to what such a harness would need to satisfy. Before we can evaluate any candidate MVP, we need to be clear about the standards it’s being asked to meet.

Next: design criteria for a commons harness.

Collaboration: a Confused Story in Five Graphs

Wed, 29 Apr 2026 00:00:00 GMT

My last two posts had graphs about Wikipedia. I tried to avoid drawing conclusions from the data for many reasons, but particularly because the data suffers from a bad streetlight effect.

Here are a few other graphs that do not make the story any clearer.

#Wikipedia web readership

From my previous post.

#US newspaper circulation

Source: Pew Research Center, Newspapers fact sheet.

#GitHub commits, PRs, and new repos

Source: The GitHub Blog.

#arXiv downloads

Source: arXiv monthly downloads.

#Reddit users

Source: Backlinko, Reddit user and growth stats (compiled from Reddit’s quarterly earnings).

The newspaper graph should be horrifying; things that were once thought to be inevitable never are. I considered adding a “you are here” to the graph, to be honest.

But also there’s still very clearly human itches to learn, to engage, and to create.

Where ~~Wikipedia~~ open knowledge fits into all of those… I don’t know. But there are many stories we can tell and futures we can try to craft.

Wikipedia's traffic drop: more on languages and freshness

Wed, 22 Apr 2026 00:00:00 GMT

Second quick post on Wikipedia’s pageview decline. The first post looked at ~4,000 career articles on English Wikipedia. This one widens the lens to 5,000 articles across eight major-language Wikipedias and asks a sharper question: which topics are dropping, and is the pattern the same everywhere?

#Disclaimer the first

Page views are not the only metric for Wikipedia’s impact. So take this with a grain of salt, and think about other ways we have impact (including through serving as a knowledge base for LLMs). Still, it is one important channel by which we fulfill our mission and live our values so I think it’s worth exploring even as we know it isn’t the end-all and be-all.

#Disclaimer the second

I’m trying very hard not to draw conclusions. It’s obvious that part of the story is LLMs, and probably the biggest part. But it is also very much a story about social media, and apps, and Google SEO, and and and. If you have questions, find me on social; I’ll try to answer or dig more into the data if I can.

#TL;DR

Since 2016–2019, aggregate monthly pageviews of Wikipedia’s “Vital Articles” are down −26% across eight major languages I sampled (en, es, fr, de, it, pt, ja, ar). The Vital Articles are an imperfect set, but they cover a much broader set of topics than my last sample set, and are widely replicated across wikis. (All of these wikis have at least 80% of the articles, making it more apples-to-apples.)

The decline isn’t even across topics. Mathematics, physical sciences, and technology are down 43% to 85%; biographical articles and geography are down less than 10% in half the languages I looked at. The per-topic ordering (which have declined the most or the least) is nearly identical in every one of the eight languages.

Freshness of article content matters, but not as strongly as topic.

#What I did (briefly)

With help from Claude Code, pulled Wikipedia’s on-wiki Level-5 Vital Articles list — 39,707 articles editorially curated into 11 topic buckets (Arts, Biology, Everyday life, Geography, History, Mathematics, People, Philosophy and religion, Physical sciences, Society, Technology). Sampled 5,000 of them with stratification across buckets. For each article, fetched monthly pageviews 2016-01 through 2026-03 in every major language where a sitelink existed. In the twelve languages where at least 80% of the articles existed, I compared a 2016–2019 pre-LLM baseline window against a 2025-04..2026-03 recent window. I fetched 12 languages, but four of them have major confounders (combinations of network access, embargo, and war, in zh, ru, fa, and uk) so for now I’ve left them out of the analysis.

Full code and pipeline in the open-source repo under analysis/vital-articles/.

#Confirming: decline is widespread

The obvious question after my last post was “what about languages outside English?” Here are monthly pageview trajectories for the 8 non-embargo languages, all pegged so that each language’s January 2021 pageview level = 100.

January 2021 is a reasonable anchor because it’s past the immediate COVID spike of 2020 but before any plausible LLM effect—ChatGPT launched in November 2022. So this chart is asking “compared to where each Wikipedia was in early 2021, where is it now?”

English is losing the least, which is probably the opposite of what a naive “more LLM exposure → more decline” story would predict. English has huge ChatGPT+Claude adoption, and the best models are tested and developed in English. But en.wikipedia holds up better than any other language in my sample. I can see any number of hypotheses for why this is, but not sure how to test any of them. Spanish and Portuguese are losing the most, both in the 50%+ range.

#Decline is topic-specific

So what about by topic? This is view-weighted % change from the 2016–19 baseline to the most recent 12 months, one number per (language × topic) cell.

Rows are sorted by each language’s overall decline (English at top, Spanish at bottom). Columns are sorted by the topic’s mean decline across all eight languages (worst on the left, best on the right).

Read it column by column, and note that every column is basically uniform: Mathematics and Physical sciences are declining heavily in all languages. At the other end, People is holding up pretty well everywhere, same for Geography and History.

If topic behavior varied by language, you’d see scattered speckle across the grid — some languages losing their Biology articles, others their Arts articles, others their People articles. Instead you see clean vertical bands. So an important takeaway, though I don’t know why: the per-topic ordering of decline is essentially the same in every language.

#Details: what is collapsing; what is holding up

Worst-declining topics (top-3 in every single language):

Mathematics: between −48% (en) and −83% (es). Mean across the eight languages: −67%.
Physical sciences: between −43% (en) and −85% (de). Mean: −66%.
Technology: between −43% (en) and −77% (es). Mean: −59%.

Best-holding topics (bottom-3 in every language):

People: between −0.1% (en) and −25.8% (ar). Mean: −13%. In English, German, and French, this bucket is essentially flat. In Italian it’s −5.6%.
Geography: between −2% (en) and −42% (es). Mean: −22%.
History: between +5.5% (en, actually grew) and −58% (es). Mean: −28%.

The middle tier — Biology, Society and social sciences, Arts, Philosophy and religion, Everyday life — falls between those two groups.

#Does article maintenance matter?

I was asked by an interested Wikipedian to look harder at article recency. He told me that one theory in the Spanish wiki community is that their articles are not well-updated, and therefore penalized in Google and falling faster than English, and asked me to see what I could puzzle out from that.

So: looking at each language’s articles by how recently each one was substantively edited (excluding bot edits, minor edits, and reverted vandalism — just real human content edits), do the fresh articles hold up while the stale ones fall harder? Put differently: does active editing predict traffic retention?

TLDR: this is messy to tease out. At least for the best and worst articles, the answer is “for some languages, yes. For others, barely.”

The chart shows the decline between each language’s freshest-10% of articles and its stalest-10%. Some key observations:

English has the strongest effect by a wide margin. The freshest-10% of English Vital Articles declined only about 7%; the stalest-10% declined 34%. In other words, the least-fresh articles do 24% worse than the freshest. Italian (−19 pp), and French (−14%) show more moderate gaps.

Japanese is an outlier: a 1-percentage-point spread. In Japanese, the freshly-edited articles lost traffic at essentially the same rate as articles that hadn’t been substantively touched in years. I don’t have a good explanation for this, and I’d be curious whether anyone closer to Japanese Wikipedia’s editorial culture has one. (Portuguese and Spanish also eyeball on the graph as flatter, but that’s in large part because all their traffic is so far down.)

This is important but not the biggest factor. Probably more detail on this later, but: a pooled multi-variate regression across all languages — controlling for topic, article length, editor count, quality, and article age — confirms that article staleness predicts decline in a real but modest way: staleness explains a slice of within-language variance, not a majority of it. The bigger variance-explainers are still topic and language.

Freshness slows the bleeding but doesn’t stop it. Even the freshest articles in every language lost traffic between 2016–19 and now. Active maintenance bends the curve — it doesn’t reverse it. English editors keeping articles fresh have protected some traffic; English Wikipedia still lost 15% overall.

#Open questions for further investigation

Preliminary multi-variate analysis was not very helpful. In other words, looking at all the data I could easily pull, no factors beyond these three (topic, language, freshness) had a ton of impact. But my stats are very rusty and I’d like to polish that more, and perhaps add in more data sources, before I publish that. If you have suggestions, let me know.

Career articles on Wikipedia: some scary numbers

Sat, 18 Apr 2026 00:00:00 GMT

Edited to add on 2026-04-22: see the followup post with more languages and freshness data.

TLDR: career articles have lost a median of 28% of their monthly pageviews since pre-COVID (more for the most-read articles), and the decline sharply accelerated in late 2025/early 2026.

Because I wanted to put this out for others, I will not write here what I think “this means”. But I think you can fairly read this in conversation with Cristophe Henner’s “what now” essay.

#Why this data set?

About a decade ago I worked for a while to improve the diversity of images in “career” articles on Wikipedia—lawyer, judge, chef, etc.—because I thought, having just had a child, it was a good thing for children reading about “being a lawyer” to see a much more representative set of images than were in that article at the time. (When I talk about this, I usually point out that every picture in Prime Minister featured Churchill. It is better now.)

Unfortunately the original wikidata query I used for that work is lost, but I reconstructed it recently. In short, the list contains any English Wikipedia article that is listed as an “occupation” in Wikidata, with lots of noise filtered out by ensuring that the occupation is actually applied to at least some people items in Wikidata. That yields about 4,000 entries, ranging from the obvious (Lawyer, Software developer) through edge cases (Pope, Comfort women).

When I looked again in 2025 after not looking for nearly a decade, the numbers looked weird, but I did not dig into them much.

But Friday I saw Martin Monperrus’s quick “decline of Wikipedia” analysis and so decided to run a similar analysis on this “pet” data set of mine.

Strong disclaimer here: this data set is not particularly representative of English Wikipedia as a whole. Nor is it a particularly perfect data set, because Wikidata’s usage of some of these categories is… weird at best. But nevertheless it is a data set that is near and dear to me because of that past work—I’m proud that a million people have seen a more representative vision of “Judge” since I improved the lead picture there in 2018, for example.

As a quick and dirty categorization, I did most analyses on the whole set and a “top” set—those that had ranked in the top-50 by pageviews in any year from 2016–2025, which netted out to 106.

#The bottom line

In the “top articles” data set, the median article is down 34% relative to a pre-COVID 2016-2019 baseline. Much of that has happened in the past year: from April 2025-March 2026, the loss was 20.9% in readership compared to the previous year. In just one year.

The larger data set’s numbers aren’t quite as bad (28% overall loss, instead of 34%), but the aggregate monthly traffic trend is basically the same for both top articles and the overall data set: a COVID-era bump, a slow drift lower through 2022–2024, then a sharp step-down starting in 2025.

In the graph, the two shaded bands mark the windows being compared: grey is 2016–2019 (48 months), red is the most recent rolling year (2025-04 through 2026-03, 12 months).

#What happened to the top articles

Of the 10 career articles that had the highest monthly traffic pre-COVID, almost every one is down 20–65%. The only outlier up is Pope, driven entirely by 2025 news (and likely back to pre-news trendline). Philosophy is another exception that held up better than most, possibly because the underlying questions (“what is Stoicism?”) are more open-ended and harder for an LLM to definitively answer than “what does a software developer do?”

#What collapsed

The biggest decliners are mostly “how do I do this job” reference articles in exactly the domains where a chatbot is the natural substitute. That said, many were clearly facing declines before GPT. Unclear if that makes LLMs an extension of the Google infobox problem, or something truly different.

In the table below, Pre-COVID /mo is the average monthly pageviews over the 2016–2019 baseline window; Recent /mo is the average over the 2025-04..2026-03 rolling year; % is the change in per-month averages between those two windows.

Article	Pre-COVID /mo	Recent /mo	%
Software_developer	43,692	2,110	−95%
System_administrator	61,712	4,923	−92%
Whistleblower	48,602	8,541	−82%
Nursing	45,817	10,523	−77%
Logistics	67,154	15,549	−77%
Civil_engineering	82,893	20,119	−76%
Scientist	35,720	10,211	−71%
Paralegal	41,183	11,985	−71%

(One real caveat: Software_developer’s traffic appears to have partly migrated to the Programmer article, which shows up in the robust list below — so some of that −95% is page-consolidation, not pure demand collapse. The aggregate still declines either way.)

#What held up the best?

About 9% of articles (323 of 3,509) had significant readership growth from pre-COVID to the last year. However, 80% of those were extremely small articles, with pre-COVID baselines under 1,000 views/month.

Only 10 articles with meaningful pre-COVID traffic (10,000+/mo) more than doubled, and nearly all of those are news-cycle events (Pope, Ayatollah, Antipope, Russian oligarchs, Monsignor) or cultural-moment shifts (Hacker, Sex worker, YouTuber). The one arguable exception is Programmer (+112%), and even there a chunk is probably redirect churn from Software developer.

In other words, organic, non-news-cycle growth in career-article reading is somewhere between rare and absent.

#Caveats

Correlation isn’t causation. The 2025 cliff coincides with broad LLM adoption, but it also coincides with referrer-mix changes (more social, less organic search), a likely shift in search-engine answer panels that reduce click-through to Wikipedia, and possibly other factors.
Redirect churn is real. The Software_developer → Programmer shift above is one visible instance; there are probably more subtle ones. I made very little effort to correct these.
These are only career articles. Again, this doesn’t say anything about Wikipedia overall, nor about the much larger set of informational topics Wikipedia covers. But does point to the sort of analysis we could be doing to spot larger trends.

#How this was built

~4,000 career article titles pulled from Wikidata (property P106 / “occupation”), filtered to items whose instance of matched profession-related classes.
Monthly pageviews fetched from the Wikimedia Pageviews REST API with agent=user (bot-filtered), 2016-01 through 2026-03.
Ranked top-50 per year by within-set pageviews; the 108 articles that hit the top 50 in any year form the “ever-top” set.
Filtered to 106 articles with complete coverage in both windows (48 baseline months = 4 full years, 12 recent months = 1 full year); compared per-month averages. Window endpoints are aligned so each calendar month appears the same integer number of times in each window, eliminating residual seasonal bias.
Monthly-series charts show raw data in grey with a LOESS smoothed trend overlaid in blue (span 0.15 for the aggregate chart, 0.25 for small multiples).

Source code and fetch scripts live at tieguy/career-images analysis/career-cliff/. Per-article CSV output at output/decline_summary.csv in the same directory.

Lawyers, Humility, and LLMs

Wed, 04 Mar 2026 00:00:00 GMT

Apparently I’ve been raving about The Three and a Half Minute Transaction: Boilerplate and the Limits of Contract Design by Mitu Gulati and Robert E. Scott for 12+ years now without blogging about it.

And now it might be more relevant than ever. So here’s a brief review.

“CONTRACT” by Steve Snodgrass is licensed under CC BY 2.0

#The basic premise

In programmer-speak, the book is about a vulnerability in a contract that was discovered, left unpatched, and exploited again. For programmers, this is a story as old as time: we have bugs, and we know it; so the question is not “why did we have a vulnerability”, the question is “why did we not fix it”.

For lawyers, the story is subtly and importantly different. So let me try to explain it again, in detailed English this time.

Contracts for “sovereign bonds” (bonds sold by countries) are fairly standardized and fairly old. They’re also quite high-stakes: billions of dollars rest on their interpretation. For many reasons, the language in these contracts often stays the same. In particular, the sentence the book is concerned with has been reused, with only slight variations, since the late 1800s.

But: in the late 1990s, “leading practitioners … suggested that no one knew what the clause actually meant”. In 2000, a court said “this sentence means X”, which created an uproar since when pressed most specialists in the area thought it meant not-X. The lawyers who regularly wrote these contracts thought this court’s interpretation was awful, and… continued using exactly the same language. They took no steps to fix (“patch”) the text.

That resulted in a multi-billion dollar litigation—which, in 2016, led law firms to finally start “fixing” the language in new bond contracts.

In other words, the book tells a story of world-class lawyers who were nevertheless resistant to doing the sort of fixes that programmers take to be somewhere between “routine” and “mandatory good practice”.

#Who cares?

I’ve long been interested in this story for many reasons, including what it tells us (or not) about open source licenses, which often copy language and concepts from each other and are notoriously hard to update in response to judicial changes.

I also find the book a good read for a bunch of reasons, including that is a great example of mixed methods: it does deep interviews of the lawyers involved, but also does deep historical research to detail the historical evolution of the clause—and show how the history and the stories told about that history don’t quite match up. The lawyers in question are smart and curious! But also they are humans embedded in a workplace culture, and economically rational actors. So who wants to be the one who spends time and effort saying the emperor has no clothes?

These are admittedly niche interests, so I tend to press this book only on the nerdiest of law nerds.

#Why now?

However, increasingly, the book feels relevant to me because it should be a tale of humility.

If some of the world’s highest-paid lawyers, at the world’s highest-status firms, do deals worth tens of billions of dollars with language they don’t understand, what does that say about the law’s pretensions to high standards?

#In other words, yes, LLMs

Yes, like everything else in 2026 this is actually a post about LLMs.

I do not particularly think that lawyers can be replaced by LLMs, at least not most good lawyers. (See, eg, Gergely.)

But many, many lawyers tend to think that the problem with LLMs in law is that Lawyers Have Incredibly High Standards, and LLMs… do not. Cannot. And that is supposed to settle the discussion.

So I think about this book a lot lately, because this story we tell about our profession’s irreplaceable skill and diligence is, at least in this one case, very demonstrably not true. The story is false for some very good reasons of human nature and economic rationality. But it is nevertheless false.

I don’t know what that means, exactly, for the future of LLMs and law. But I do recommend every lawyer who defends our profession to read this book, and ponder what it might mean to look at new tools with more humility about our own skills—and shortcomings.

Of Monsters, Men, and Lawyers

Mon, 02 Mar 2026 00:00:00 GMT

There’s been a very high-volume thread this weekend on Bluesky about whether an LLM can do basic lawyering. I’ve mostly avoided it (because it was my birthday and I had more joyful things to do) but I came across an after-effect of it this morning.

“I was trying to get it to work on her terms, which required not telling it the relevant distinction explicitly and relying on the robot to infer it” link

I haven’t read the thread, so I don’t want to make it about these specific Bluesky sparring partners or the specifics of this one particular test. In particular, I don’t know if David is misrepresenting the challenge as laid out. But I have seen other smart law-folks make similar mistakes to the one David reports here, so I want to write down my thoughts.

#Generalists, not specialists

Here’s the thing: LLMs are not Brilliant Lawyers. No one should be claiming that. Law is a specialty, and LLMs are generalist tools. (There are some important caveats, but I’ll get to those later.)

Think less “first-year attorney” and more “English-major undergrad with a philosophy minor, who has read a lot of true-crime novels”. So they have heard our magic words, and can fake it when they go as a character from Suits for Halloween, but they don’t quite know what the magic words mean.

In other words, relying on the untrained, generalist LLM to infer unprovided specialized information is a bit of a fool’s errand—like asking an undergrad who has watched courtroom TV, it tells you very little about the capability of LLMs to be useful in a legal practice.

#Very teachable generalists

But like an undergrad, they are also pretty easy to instruct. And unlike an undergrad, they are pretty reliable (and infinitely patient) once instructed.

In other words, asking an LLM to “do X” is often going to fail, or only work superficially.

Instructing the LLM that “X consists of (verbose, detailed definitions and instructions), now do X” is often going to work very well.

#Implications

So what does this mean? Some time-bounded thoughts and takeaways:

Do not waste anyone’s time having an online argument about “can a general-purpose LLM do X” and then ask for the analysis to be done with one virtual arm tied behind its back. The discussion must start with “how often is this task done, so how much time does it take to codify the relevant knowledge and practice”.
For many legal tasks, the answer to the question in (1) is going to be “it does not make sense to do this with an LLM, because this work is rarely done and so codifying it will take longer than doing it myself”. (Part of why I avoided the thread that prompted this blog post is because it is a task I’ve never once been asked to do in my 15+ year legal career, so it’s impossible for me to answer this question.)
Programmers can be very bad about (1) because we tend to underestimate how much LLM-based coding tools have had massive investment in what are coming to be called “harnesses”: complex combinations of tooling+prompting+context that wrap the generalist LLM in a tight cocoon of specific knowledge about coding and codebases. So programmers tend to say “LLMs are great at coding” when what they really mean is “LLMs plus extremely extensive harnesses are great at coding”. This is an extremely important difference, and one that misleads non-programmers (and again, many programmers) into thinking that “LLMs” will be great at other fields without the big investment in harnesses.
Programmers are also bad about (1) because the biggest pot of money in the long history “sell pickaxes to miners” is at stake, so when I say “big investment” I mean literally hundreds of billions of dollars. Not yet so much in lawyer harnesses. Both developers and lawyers having this discussion need to remember that.
Lawyers cannot rest on our laurels. Our pot of money is still pretty big, so there will be broad and deep legal harnesses, most likely sooner rather than later. Those harnesses will have carefully crafted instructions and context, and will absolutely crush general-purpose tools + naive lawyer-drafted instructions. We’re not there yet, and I’m pretty skeptical that the existing duopoly will be the ones to produce those harnesses. (Harvey and Clio are of course both frantically trying to do this, but I haven’t been able to test them much yet.) But it absolutely will come, and thanks to aggregation theory, it is going to come for your niche no matter how niche you think it is.
(5) is going to be rude to a lot of lawyers, because we tend to think our way of doing things is the One True Way when in fact there are a lot of ways to do law. The process of writing down previously unwritten things is going to cause a lot of discomfort.
Related to the previous point, the most adamant lawyer I’ve seen on this point (not Kathryn) is a 99th-percentile expert in their field. (Some of the most critical programmers too!) If your standard for LLM evaluation is “it has to be as good as a 99th percentile expert, or it doesn’t count”, you’re going to be shocked when 50th percentile experts love it and 95th percentile experts begrudgingly start using it.
There’s probably a lot more to be said here, but like I said at the beginning: time-bound. I have a day job! A family! I like them both!

#Conclusion

It really, really pains me to see debates about “is LLM good at X” that rest on “raw” LLM usage, because that is not how anyone in any profitable field is going to use LLMs.

If we’re going to come to real terms with what these mean for our industries (all of them, not just programming and law) we must stop asking questions of naive chatbots, and start thinking about what sophisticated, carefully-crafted tools—that use LLMs as part of their pipeline, but are also carefully trained and contextualized—will do.

two questions on software "sovereignty"

Thu, 22 Jan 2026 00:00:00 GMT

The EU looks to be getting more serious about software independence, often under the branding of “sovereignty”. India has been taking this path for a while. (A Wikipedia article on that needs a lot of love.) I don’t have coherent thoughts on this yet, but prompted by some recent discussions, two big questions:

First: does software sovereignty for a geopolitical entity mean:

we wrote the software from the bottom up
we can change the software as necessary (not just hypothetically, but concretely: the technical skills and organizational capacity exist and are experienced)
we sysadmin it (again, concretely: real skills, not just the legal license to download it)
we can download it

My understanding is that India increasingly demands one for important software systems, though apparently both their national desktop and mobile OSes are based on Ubuntu and Android, respectively, which would be more level 2. (FOSS only guarantees #4; it legally permits 2 and 3 but as I’ve said before, being legally permitted to do a thing is not the same as having the real capability to do the thing.)

As the EU tries to set open source policy it will be interesting to see whether they can coherently ask this question, much less answer it.

Second, and related: what would a Manhattan Project to make the EU reasonably independent in core operating system technologies (mobile, desktop, cloud) look like?

It feels like, if well-managed, such a project could have incredible spillovers for the EU. Besides no longer being held hostage when a US administration goes rogue, tudents would upskill; project management chops would be honed; new businesses would form. And (in the current moment) it could provide a real rationale and focus for being for the various EU AI Champions, which often currently feel like their purpose is to “be ChatGPT but not American”.

But it would be a near-impossible project to manage well: it risks becoming, as Mary Branscombe likes to say, “three SAPs in a trenchcoat”. (Perhaps a more reasonable goal is to be Airbus?)

Three LLM-assisted projects

Sun, 09 Nov 2025 00:00:00 GMT

Some notes on my first serious coding projects in something like 20 years, possibly longer. If you’re curious what these projects mean, more thoughts over on the OpenML.fyi newsletter.

#TLDR

A GitHub contribution graph, showing a lot of activity in the past three weeks after virtually none the rest of the year.

#News, Fixed

The “Fix The News” newsletter is a pillar of my mental health these days, bringing me news that the world is not *entirely *going to hell in a handbasket. And my 9yo has repeatedly noted that our family news diet is “broken” in exactly the way Fix The News is supposed to fix—hugely negative, hugely US-centric. So I asked Claude to create a “newspaper” version of FTN — a two page pdf of some highlights. It was a hit.

So I’ve now been working with Claude Code to create and gradually improve a four-days-a-week “News, Fixed” newspaper. This has been super-fun for the whole family—my wife has made various suggestions over my shoulder, my son devours it every morning, and it’s the first serious coding project I’ve tackled in ages. It is almost entirely strictly personal (it still has hard-coded Duke Basketball schedules) but nevertheless is public and FOSS. (It is even my first usage of reuse.software—and also of SonarQube Server!)

Example newspaper here.

No matter how far removed you are from practical coding experience, I cannot recommend enough finding a simple, fun project like this that scratches a human itch in your life, and using the project to experiment with the new code tools.

#Getting Things Done assistant

While working on News, Fixed a friend pointed out Steve Yegge’s “beads”, which reimagines software issue tracking as an LLM-centric activity — json-centric, tracked in git, etc. At around the same time, I was also pointed at Superpowers—essentially, canned “skills” like “teach the LLM, temporarily, how to brainstorm”.

The two of these together in my mind screamed “do this for your overwhelmed todo list”. I’ve long practiced various bastardized versions of Getting Things Done, but one of the hangups has been that I’m inconsistent about doing the daily/weekly/nth-ly reviews that good GTD really relies on. I might skip a step, or not look through all my huge “someday-maybe” list, or… any of many reasons one can be tired and human when faced with a wall of text. Also, while there are many tools out there to do GTD, in my experience they either make some of the hardest parts (like the reviews) your problem, or they don’t *quite *fit with how I want to do GTD, or both. Hacking on my own prompts to manage the reviews seems to fit these needs to a T.

I currently use Amazing Marvin as my main GTD tool. It is funky and weird and I’ve stuck with it much longer than any other task tracker I’ve ever used. So what I’ve done so far:

wrapped the Marvin API to extract json
discovered the Marvin API is very flaky, so done some caching and validation
written a lot of prompts for the various phases/tasks in GTD. These work to varying degrees and I really want to figure out how to collaborate with others on them, because I suspect that as more tools offer LLM-ish APIs (whoa, todoist!) these prompts are where the real fun and action will be.

This is all read-only right now because of limitations in the Marvin API but for various reasons I’m not yet ready to embark on building my own entire UI. So this will do for now. But this code, therefore, is very limited to me. The prompts on the other hand…

Note that my emphasis is not on “do tasks”, it is on helping me stay on priority. Less “chief of staff”, more “executive assistant”—both incredibly valuable when done well, but different roles. This is different from some of the use examples for Yegge’s Beads, which really are around agents.

Also note: the results have been outstanding. I’m getting more easily into my doing zone, I think largely because I have less anxiety about staring at the Giant Wall of Tasks that defines the life of any high-level IC. And my projects are better organized and todos feel more accurate than they have been in a long time, possibly ever.

#a note on LLMs and issue/TODO tracking

It is worth noting that while LLMs are probabilistic/lossy, so they can’t find the “perfect” next TODO to work on, that’s OK. Personal TODO and software issue tracking are inherently subjective, probabilistic activities—there is no objectively perfect “next best thing to work on”, “most important thing to work on”, etc. So the fact that an LLM is only probabilistic in identifying the next task to work on is fine—no human can do substantially better. In fact I’m pretty sure that once an issue list is past a certain point, the LLM is likely to be able to do better— if (and like many things LLM, this is a big if) you can provide it with documented standards explaining how you want to do prioritization. (Literally one of the first things I did at my first job was write standards on how to prioritize bugs—the forerunner of this doc—so I have strong opinions, and experience, here.)

#Skills for license “concluded”

While at a recent Linux Foundation event, I was shocked to realize how many very smart people haven’t internalized the skills/prompts/context stuff. It’s either “you chat with it” or “you train a model”. This is not their fault; it is hard to keep up!

Of course this came up most keenly in the context of the age-old problem of “how do I tell what license an open source project is under”. In other words, what is the difference between “I have scanned this” and “I have reached the zen state of SPDX’s ‘concluded’ field”.

So … yes, I’ve started playing with scripts and prompts on this. It’s much less further along than the other two projects above, but I think it could be very fruitful if structured correctly. Some potentially big benefits above and beyond the traditional scanning and/or throw a lawyer at it approaches:

reporting: my very strong intuition, admittedly not yet tested, is that plain-English reports on factors below, plus links into repos, will be much easier for lawyers to use as a starting point than the UIs of traditional license-scanner tools. And I suspect ultimately more powerful as well, since they’ll be able to draw on some of the things below.
context sensitivity: unlike a regexp, an LLM can likely fairly reliably understand from context some of the big failures of traditional pattern matching like “this code mentions license X but doesn’t actually include it”.
issue analysis and change analysis: unlike traditional approaches, LLMs can look at the change history of key files like README and LICENSE and draw useful context from them. “oh hey README mentioned a license change on Nov. 9, 2025, here’s what the change was and let’s see if there are any corresponding issues and commit logs that explain this change” is something that an LLM really can do. (Also it can do that with much more patience than any human.)

ClearlyDefined offers test data on this, by the way — I’m really looking forward to seeing if this can be made actually reliable or not. (And then we can hook up reuse.software on the backend to actually improve the upstream metadata…)

But even then, I may not ever release this. There’s a lot of real risks here and I still haven’t thought them through enough to be comfortable with them. That’s true even though I think the industry has persistently overstated its ability to reach useful conclusions about licensing, since it so persistently insists on doing licensing analysis without ever talking to maintainers.

#More to come?

I’m sure there will be more of these. That said, one of the interesting temptations of this is that it is very hard to say “something is done” because it is so easy to add more. (eg, once my personal homebrew News Fixed is done… why not turn it into a webapp? once my GTD scripts are done… why not port the backend? etc. etc.) So we’ll see how that goes.

book reports, mid-2025

Fri, 06 Jun 2025 00:00:00 GMT

Some brief notes on books, at the start of a summer that hopefully will allow for more reading.

#Monk and Robot (Becky Chambers); Mossa and Pleiti (Malka Older)

Summer reading rec, and ask for more recs: “cozy sci-fi” is now a thing and I love it. Characters going through life, drinking hot beverages, trying to be comfortable despite (waves hands) everything. Mostly coincidentally, doing all those things in post-dystopian far-away planets (one fictional, one Jupiter).

Novellas, perfect for summer reads. Find a sunny nook (or better yet, a rainy summer day nook) and enjoy. (New Mossa and Pleiti comes out Tuesday, yay!)

A complex socio-technical system, bounding boldly, perhaps foolishly, into the future. (Original via NASA)

#Underground Empire (Henry Farrell and Abraham Newman)

This book is about things I know a fair bit about, like international trade sanctions, money transfers, and technology (particularly the intersection of spying and data pipes). So in some sense I learned very little.

But the book efficiently crystallizes all that knowledge into a very dense, smart, important observation: that some aspects of American so-called “soft” (i.e., non-military) power are in increasingly very “hard”. To paraphrase, the book’s core claim is that the US has, since 2001, amassed what amounts to several, fragmentary “Departments of Economic War”. These mechanisms use control over financial and IP transfers to allow whoever is in power in DC to fight whoever it wants. This is primarily China, Russia, and Iran, but also to some extent entities as big as the EU and as small as individual cargo ship captains.

The results are many. Among other things, the authors conclude that because this change is not widely-noticed, it is undertheorized, and so many of the players lack the intellectual toolkit to reason about it. Relatedly, they argue that the entire international system is currently more fragile and unstable than it has been in a long time exactly because of this dynamic: the US’s long-standing military power is now matched by globe-spanning economic control that previous US governments have mostly lacked, which in turn is causing the EU and China to try to build their own countervailing mechanisms. But everyone involved is feeling their way through it—which can easily lead to spirals. (Threaded throughout the book, but only rarely explicitly discussed, is the role of democracy in all of this—suffice to say that as told here, it is rarely a constraining factor.)

Tech as we normally think of it is not a big player here, but nevertheless plays several illustrative parts. Microsoft’s historical turn from government fighter to Ukraine supporter, Meta’s failed cryptocurrency, and various wiretapping comes up for discussion—but mostly in contexts that are very reactive to, or provocative irritants to, the 800lb gorillas of IRL governments.

Unusually for my past book reports on governance and power, where I’ve been known to stretch almost anything into an allegory for open, I’m not sure that this has many parallels. Rather, the relevance to open is that these are a series of fights that open may increasingly be drawn into—and/or destabilize. Ultimately, one way of thinking about this modern form of power dynamics is that it is a governmental search for “chokepoints” that can be used to force others to bend the knee, and a corresponding distaste for sources of independent power that have no obvious chokepoints. That’s a legitimately complicated problem—the authors have some interesting discussion with Vitalik Buterin about it—and open, like everyone else, is going to have to adapt.

#Dying Every Day: Seneca at the Court of Nero (James Romm)

Good news: this book documents that being a thoughtful person, seeking good in the world, in the time of a mad king, is not a new problem.

Bad news: this book mostly documents that the ancients didn’t have better answers to this problem than we moderns do.

#The Challenger Launch Decision (Diane Vaughan)

The research and history in this book are amazing, but the terminology does not quite capture what it is trying to share out as learnings. (It’s also very dry.)

The key takeaway: good people, doing hard work, in systems that slowly learn to handle variation, can be completely unprepared for—and incapable of handling—things outside the scope of that variation.

It’s definitely the best book about the political analysis of the New York Times in the age of the modern GOP. Also probably good for a lot of technical organizations handling the radical-but-seemingly-small changes detailed in Underground Empire.

#Spacesuit: Fashioning Apollo (Nicholas De Monchaux)

A book about how interfaces between humans and technology is hard. (I mean clothes, but also everything else.) Delightful and wide-ranging; maybe won’t really learn any deep lessons here but it’d be a great way to force undergrads to grapple with Hard Human Problems That Engineers Thought Would Be Simple.

freedoms-for-who, revisited briefly

Mon, 03 Feb 2025 00:00:00 GMT

In talking with someone about “preferred form for modification” over the weekend at FOSDEM, the FSF (now sort-of-OSI?) four freedoms came up. They’re not bad, but they’re extremely developer-focused in their “use case”. This is not a new observation, of course, but the changed technical and social context of AI seems to be bringing it to the fore that different users have different variations on the values and why open is so important to them.

Here’s a very quick, rough cut of what I proposed instead as key freedoms, and who those matter for. These are not exclusive (eg in many cases developers also care about replication; businesses obviously frequently care about modification, etc.) but compared to the original four freedoms, convey that different stakeholders have different needs—all of which have been served, but not explicitly called out as metrics, by the FOSS movement over the years.

modification (foremost, for developers): We like to play with things, and often can make them better in the process. Enough said.
replication (foremost, for scientists): It’s not really science if you can’t replicate it, and you can’t replicate it if it isn’t really yours. High overlap with modification and transparency, but something other constituencies can often live without.
transparency (foremost, for governments): you can’t effectively regulate what you can’t understand, and it’s never OK for something that needs to be regulated to be opaque. (Obviously we allow this all the time but as we’re all reminded this week that leads to all kinds of malignancies.)
cost of re-use (foremost, for business): This is perhaps the least unique, but it’s important to remember that statistically businesses very rarely modify open source. They pick and choose what they use, and compose them in almost entirely unique ways, but that’s a property of architectural design and cost, not of ability to modify.

These of course get you to mostly the same place as the traditional four freedoms. But importantly for the discussion of “open in AI”, replication and transparency require a focus on data, while for many businesses (and certainly for most developers) weights are sufficient and may well be preferred in many/most cases.

One could imagine other use cases and priorities, of course. But I wanted to bang this out quick and there was a nice symmetry to having four. Leave more on the various socials :)

non-profit social networks: benchmarking responsibilities and costs

Wed, 15 Jan 2025 00:00:00 GMT

I’m trying to blog quicker this year. I’m also sick with the flu. Forgive any mistakes caused by speed, brevity, or fever.

Monday brought two big announcements in the non-traditional (open? open-ish?) social network space, with Mastodon moving towards non-profit governance (asking for $5M in donations this year), and Free Our Feeds launching to do things around ATProto/Bluesky (asking for $30+M in donations).

It’s a little too early to fully understand what either group will do, and this post is not an endorsement of specifics of either group—people, strategies, etc.

Instead, I just want to say: they should be asking for millions.

There’s a lot of commentary like this one floating around:

I don’t mean this post as a critique of Jan or others. (I deliberately haven’t linked to the source, please don’t pile on Jan!) Their implicit question is very well-intentioned. People are used to very scrappy open source projects, so millions of dollars just feels wrong. But yes, millions is what this will take.

#What could they do?

I saw a lot of comments this morning that boiled down to “well, people run Mastodon servers for free, what does anyone need millions for”? Putting aside that this ignores that any decently-sized Mastodon server has actual server costs (and great servers like botsin.space shut down regularly in part because of those), and treats the time and emotional trauma of moderation as free… what else could these orgs be doing?

Just off the top of my head:

Moderation, moderation, moderation, including:
- moderation tools, which by all accounts are brutally badly needed in Masto and would need to be rebuilt from scratch by FoF. (Donate to IFTAS!)
- multi-lingual and multi-cultural, so you avoid the Meta trap of having 80% of users outside the US/EU but 80% of moderation in the US/EU.
Jurisdictionally-distributed servers and staff
- so that when US VP Musk comes after you, there’s still infrastructure and staff elsewhere
- and lawyers for this scenario
Good governance
- which, yes, again, lawyers, but also management, coordination, etc.
- (the ongoing Wordpress meltdown should be a great reminder that good governance is both important and not free)
Privacy compliance
- Mention “GDPR compliance” and “Mastodon” in the same paragraph and lots of lawyers go pale; doing this well would be a fun project for a creative lawyer and motivated engineers, but a very time-consuming one.
- Bluesky has similar challenges, which get even harder as soon as meaningfully mirrored.

And all that’s just to have the same level of service as currently.

If you actually want to improve the software in any way, well, congratulations: that’s hard for any open source software, and it’s really hard when you are doing open source software with millions of users. You need product managers, UX designers, etc. And those aren’t free. You can get some people at a slight discount if you’re selling them on a vision (especially a pro-democracy, anti-harassment one), but in the long run you either need to pay near-market or you get hammered badly by turnover, lack of relevant experience, etc.

#What could that cost, $10?

So with all that in mind, some benchmarks to help frame the discussion. Again, this is not to say that an ATProto- or ActivityPub-based service aimed at achieving Twitter or Instagram-levels of users should necessarily cost exactly this much, but it’s helpful to have some numbers for comparison.

Wikipedia: (source)
- legal: $10.8M in 2023-2024 (and Wikipedia plays legal on easy mode in many respects relative to a social network—no DMs, deliberately factual content, sterling global brand)
- hosting: $3.4M in 2023-2024 (that’s just hardware/bandwidth, doesn’t include operations personnel)
Python Package Index
- $20M/year in bandwidth from Fastly in 2021 (source) (packages are big, but so is social media video, which is table stakes for a wide-reaching modern social network)
Twitter
- operating expenses, not including staff, of around $2B/year in 2022 (source)
Signal
- $50M/year (source)
Content moderation
- Hard to get useful information on this on a per company basis without a lot more work than I want to do right now, but the overall market is in the billions (source).
- Worth noting that lots of the people leaving Meta properties right now are doing so in part because tens of thousands of content moderators, paid unconscionably low wages, are not enough.

You can handwave all you want about how you don’t like a given non-profit CEO’s salary, or you think you could reduce hosting costs by self-hosting, or what have you. Or you can pushing the high costs onto “volunteers”.

But the bottom line is that if you want there to be a large-scale social network, even “do it as cheap as humanly possible” is millions of costs borne by someone.

#What this isn’t

This doesn’t mean “give the proposed new organizations a blank check”. As with any non-profit, there’s danger of over-paying execs, boards being too cozy with execs and not moving them on fast enough, etc. (Ask me about founder syndrome sometime!) Good governance is important.

This also doesn’t mean I endorse Bluesky’s VC funding; I understand why they feel they need money, but taking that money before the techno-social safeguards they say they want are in place is begging for problems. (And in fact it’s exactly because of that money that I think Free Our Feeds is intriguing—it potentially provides a non-VC source of money to build those safeguards.)

But we have to start with a realistic appraisal of the problem space. That is going to mean some high salaries to bring in talented people to devote themselves to tackling hard, long-term, often thankless problems, and lots of data storage and bandwidth.

And that means, yes, millions of dollars.

Reading in 2024—tools

Thu, 02 Jan 2025 00:00:00 GMT

I was going to do a single post on my reading in 2024, but realized it probably makes more sense as a two-parter: the things I used to read (this post), and the things I actually read (at least one post on books, maybe a second on news and feeds).

#Feeds

I still read a lot of feeds (and newsletters). Mid-way through the year, I switched to Reader by Readwise for RSS and newsletters, after a decade or so with Feedbin. It’s everything I have always wanted from an RSS tool—high polish, multi-platform, and separates inbound stuff to skim from stuff to be gone into at more depth. Expensive, but totally worth it if you’re an addict of my sort.

Surprise bonuses: has massively reduced my pile of open tabs, and is a nice ebook reader—have read several DRM-free books from Verso and Standard Ebooks in it.

One minor gripe (that I’ve also had with just about every other feed reader/read later tool): I wish it were more possible to get content out with tools. Currently I use Buffer to get things out of Reader to social, but I’d love to do that in a more sophisticated and automated way (eg by pulling everything in a tag saved in the previous week, and massaging it to stuff into a draft blog post).

#E-ink reading

I wrote early in the year about my Boox Page, and then promptly put a knee through the screen. I had liked it, but ultimately didn’t love it. In particular, the level of hackery in their mods to Android really bothered me—the thing did not Just Work, which was the last thing I wanted in a distraction-free reading device.

So I got a Daylight DC1. What can I say, I’m a sucker for new e-ink and e-ink like devices. I love it but it has a lot of warning signs so I’m not sure I can recommend it to anyone yet.

Parts I love:

Screen is delightfully warm. Doesn’t quite try to be paper (can’t) but is very easy on the eye, both in broad daylight and at night. (Their marketing material, for the screen, is really quite accurate.)
Screen texture is great under the finger when reading; feels less like a screen and more like paper. (Can’t speak to the pen; really am using this as a consumption device, with my iPad more for creation. Might change that in the new year, not sure yet.)
Battery life is great.
Android is Just Android (with a very tasteful launcher as the only significant modification), so you really can run things you want (especially if their output is mostly text). I’ve got mine loaded with pretty much just readers: Kindle, Libby, Kobo, Readwise Reader; all work great.
I find myself weirdly in love with the almost pillow-like “case”. It’s silly and inefficient and maybe that’s OK?

Parts I worry about:

Physical build quality is a little spotty—most notably the gap between screen and case is very uneven. Hasn’t affected my day to day use, but makes me wonder about how long it’ll last.
The OS is… shifty? Reported itself to the Android app store as a Pixel 5(?), and the launcher is unpaid-for freeware (got a nice little “please give us $5!” note from it, which screams corner-cutting.) Again, works fine, just red flag in terms of attention to detail and corner-cutting.
I found out after I bought that the CEO is a not-so-reformed cryptobro, an organizational red flag.
They’re talking a lot about AI for their next OS “release”. That implies a variety of possible dooms: either a small team gets overwhelmed by the hard work of AI, or a large team has lots of VC demands. Neither is good.

#Audio

Switched from Audible (I know) to Apple Books (I know, again) because it works so much more reliably on my Apple Watch, and running with the Watch is where I consume most of my audiobooks. Banged through a lot of history audiobooks this year as a result.

#Paper

I still love paper too. 2025 goal: build a better bookshelf. We’ll see how that goes…

Hello World

Fri, 15 Mar 2024 00:00:00 GMT

This is a test post to verify the content collection works.

Boox Page: A Review

Wed, 14 Feb 2024 00:00:00 GMT

I love words, and have as far back as I can remember. Mom says I started reading the newspaper religiously in kindergarten, I proudly show off a small percentage of my books in my videoconferencing background, and of course the web is (still) junk straight into my veins.

So I’ve long wanted an e-ink device that could do multi-vendor ebooks, pdfs, and a feed reader. (I still consume a lot of RSS, mostly via the excellent feedbin.) But my 8yo Kindle kept not dying, and my last shot at this (a Sony) was expensive and frustrating.

Printery, by Dennis Jarvis; used under CC BY-2.0.

Late last year, though, I found out about the Boox Page. It is… pretty great? Some notes and tips:

My use case: I don’t write or take notes on this, so I can’t advise on whether it is a good Remarkable (or similar) competitor. Also don’t use the music player or audiobooks.
Price: Pretty reasonable for something I use this much. Open question how long they do Android support, unfortunately—Reddit users report five years for older models, which isn’t great but (unlike a phone) not as hugely active a security risk.
Screen and body: screen, lighting, size, and weight are easily on par with my old Kindle, which is to say “comfortable on eyes and hands for a lot of long-term reading”.
Battery life: This is not an OG Kindle, but I have gone multiple plane flights without recharging, and it is USB-C, so (unlike my micro-USB Kindle) easy to charge while traveling.
Other hardware: Meh.
- The hardware volume buttons are… fine? But small. I would not miss them if I had to rely on the screen.
- The cover is a fine cover, but it is not an effective stand - something I miss from my Kindle.
- I suspect repairability is terrible. Sorry, iFixit :(
Core operating system
- UX: Android modded to use e-ink is… surprisingly fine? I use the Android layer essentially to (1) install apps and (2) launch them. And those work well, though the default launcher screen has some clutter that can’t be removed. Some of the alternate Android launchers apparently work, but I haven’t tried any of them yet.
- performance: Boot time is very long, and for unknown reasons it seems to default to a full shutdown when you close the cover, which really destroys the “open up the book and immediately start reading” experience. Strongly recommend Power → Power-off Timeout → “never” to avoid this problem.
- Security: There is no thumbprint or face scan here, and the e-ink keyboard is as good as possible but still slow to enter a high-strength password. So I’ve chosen to put as little private information on this as possible. Has motivated me to update some passwords to “xkcd-style” four-word, lower-case, strings in order to make them easier to read from my phone and type in on the Boox.
- Openness: it looks like Onyx violates the GPL. Folks have successfully rooted older Boox devices, but I have not seen any evidence of anyone doing that with the Page yet.
UX “improvements”: There are so many; most aren’t great but the worst ones can all be turned off.
- “Naviball”: a weird dot-as-UI thing that I turned off nearly immediately.
- Gestures: To save screen real-estate, standard Android back and home buttons are by default replaced with gestures (documentation). I found the gestures a bit unreliable and so turned the bottom toolbar back on. Not great but fine.
- E-ink settings: There are a lot of different settings for e-ink refresh strategies (eg do you want it faster but lossy, slower but clearer, etc.), which are adjustable both overall and on a per-app basis. The default settings seem to work pretty well for me, but I suspect at least some apps would benefit from tweaking. Docs here for more details.
App stores:
- Google Play: pre-installed, and can be used to install Kindle, Libby, and Hoopla. It works fine, with two caveats: I don’t love giving this device my Google password; and it is clear that the best iOS apps have noticeably better UX than the best Android apps.
- F-Droid: Works great! Used it to install the Wikipedia app, KOReader, and Tusky, among others.
Getting books:
- Kindle app works great. You will not lose access to your existing e-book library by moving away from a Kindle.
- Libby and Hoopla: Both of the apps used by my library (San Francisco Public) to make e-books available install fine from the Google Play App Store and work great. Have happily read long books in both of them.
- Standard Ebooks: Their website and “advanced epub” work great on the Boox, so I’ve been plowing through a bunch of old public domain stuff. This has been maybe the single most satisfying part of the device, to be honest—it’s been great to refocus my reading that way instead of being guided by Amazon’s recommendations.
- Onyx: the folks behind Boox have a book store, which can be turned off but not removed from the home-screen UX. I have not used it.
Reading books:
- All of the apps above have worked fine, with the minor detail that in some of them (notably Kindle) you have to find a setting to enable “use volume control as page up/down” in order to use the page turning buttons.
- KOReader, from F-Droid, was recommended to me. Its default text presentations are, IMHO, not ideal. But once I spent some time experimenting to get proper margins and line spacing, it became very pleasant. I use it to read the “advanced” formatted epubs from Standard Ebooks, and it handles those very well.
Managing books:
- KO Reader and the built-in book reader mostly default to “just expose the file system” as a book management view, which is… not great.
- KO Reader does not sync reading positions, so if you’re used to going back and forth between your e-ink device and your phone, you may need to do more work, either to just remember your positions, or to set up something like calibre-web.
- I’m using Story Graph as my main “what did I read lately” repository and it works great as a progressive web app.
The web
- The basics: the Page has a reasonably modern Chrome (called “Neobrowser”). Mostly just works, none of the “experimental” web browser stuff from Kindle.
- Scrolling: can be painful; e-ink and scrolling don’t mix too well. Much depends on the nature of the web page (fine) or web app (grimace) you’re using - some are fine, others are not so much.
- Progressive Web Apps: The browser often prompts you to install web sites as app icons on the main launcher page and they generally work great. Really nice alternative to app stores, just like we always hoped they’d be. Maybe just a few years too late :(
Other sources of text
- Feeds: Feedbin.com in the browser is… fine. Refresh is sort of wonky, though. I’ve tried both Android apps listed on the feedbin site, but don’t love either. (I like the experience enough that I have resurrected my dream of a more newspaper-like app to read on this in the morning.)
- Fediverse: Tusky is the most-recommended open Android Mastodon app, and it is fine, but I have found that I prefer Phanpy in-browser (despite some performance challenges) to the better performance but rough UX edges of Tusky. There are quite a few other options; I have not explored them deeply.
- PDFs. The couple of PDFs I’ve tried to read have been fine, but I have not pushed it and I suspect they won’t be great given the smaller-screen; either a larger Boox or a Remarkable seem more the right thing if that is your primary use case. I really need to set up some sort of syncing and prioritizing system; many of them are reputed to work (again, basically stock-ish Android).
- Wikipedia: App works great. Haven’t tried editing yet though ;)
Things I’d like to explore more:
- Security: can I move entirely to F-Droid-sourced apps so I don’t need this to have my Google password? Can I replace most Onyx-provided apps next?
- “Find my”: Is there a “find this device” (and/or “remote wipe this”) service that would help me track it down in case of loss, but that doesn’t require trusting the device very much (see Google password above)? No idea but given that I’ve already nearly lost it once, I need to look into it.
- Sharing out: I like sharing out links, quotes, snippets, etc. but typing on this is a bit of a mess. I’d like to figure out some sort of central output flow, where I can use the Android share feature to dump into a stream that I can then surf and resurface from other devices. Not sure what the right service is to host that, though.
Bottom line: I am really enjoying this, and it is enough under my control that I suspect I can make it even better. It certainly isn’t a dream device from a freedom and privacy perspective, but for my limited use case that’s fine.

Added, Feb. 15: An old friend reading this said it surprised him, because my software aesthetics at this point are very much “it had better work out of the box, I have no time or patience for DIY”, and this sounded… pretty DIY.

It’s a great observation. For lots of other devices, I have no patience for something that doesn’t Just Work. But apparently (surprising me as much as anyone!) I have a lot of patience for getting my e-reading experience just so. So this did (still does) take patience, but also so far has rewarded that patience. We’ll see if it sticks.

Leaving Twitter for New Frontiers

Tue, 23 Jan 2024 00:00:00 GMT

Revised and updated: September 2024, to make more positive, include my own links, and mention how to improve LinkedIn.

Work as if you live in the early days of a better nation.

Dennis Leigh via Alasdair Gray

And then THEY bring friends and the friends bring friends … and then you realize, oh shit, this is a Nazi bar now.

Michael Tager

You can think about leaving Twitter in one of a few ways:

Do you want to not hang out at a neo-nazi bar?
Do you want to be part of building a better world?

The negative take on this is accurate. Twitter is literally a nazi bar now: the owner, and his friends, follow, share, and RT literal nazis and fascists. I won’t dwell on that here, but it is real.

The optimistic take is that we canbuild a better, more decentralized social world. This is ultimately not a “they” problem—yes, someone has to build the protocol and the tools, but also we, the early “immigrants” to the new social frontier, have to labor too. We have to “work as if you live in the early days” and seek out people to follow, filter more manually, etc. That’s not necessarily easy—it means rough edges, more noise, etc. But we’ve done it before (most notably on Twitter c. 2008!) and we can do it again. This can be a moment of optimism and construction—a barn-raising for the 21st century social networks we want to see.

In that spirit of building a better thing together, and dealing with the rough edges in the meantime, here are some tips that have helped me move off Twitter.

#Picking a new place

Here’s my current read on where to go first after you’ve decided to start out for new frontiers.

The most old-Twitter vibe these days seems to be on Bluesky—it has a loooot of politics and news, a decent sense of humor (dril is there, sometimes!), and some growing international traction (with big surges each time Elon endorses fascists in (so far) the US, UK, and Brazil). It’s also got very good discoverability features (about which more below). On Bluesky I’m @lu.is.
If you’re into the more nerdy side, the Fediverse (aka Mastodon) has you covered. I recommend creating an account on a server that’s specific to your place (like sfba.social or cosocial.ca) or your interests (like fosstodon or hci.social). The server functionality in Mastodon isn’t great (it is telling that the default UX calls it a server and not a community) but it can help you get your footing. On the Fediverse I’m @luis_in_brief@social.coop.
Threads has a huge number of users, including a lot of “official” accounts for things like news orgs, celebs, and presidential candidates. It also lets you start with your Instagram follows. My sense (from a distance) is that this gives it a somewhat sterile, but positive, feel. Optionally, you can also use Threads to interact with Fediverse—which may be a good way to support decentralized social media even while not relying on it.
If you use social media heavily for work, consider leaning into LinkedIn. Switch to their “most recent” (sometimes called “top”?) posts to get a much better feed of your follows rather than random people.

#Settling in to the new place

Follow some topics: Once you’ve got an account set up, go old-school and follow some topics.
- On Bluesky, you can do this by using search to find lists like Housing or Ukraine OSINT. Note that lists on Bluesky are waaaaaay more powerful than Twitter lists—they can pick sorting algorithms, use regexp to include only on-topic posts from members of the list, etc.
- On Mastodon, the name of the game is hashtags. I particularly follow and enjoy #Bloomscrolling, #SolarPunk, #LawFedi, #BikeTooter, and #Bookstodon.
Find some follows! Besides the obvious—follow me! bluesky, mastodon—a few tips:
- On Bluesky search works pretty well (because it isn’t actually a decentralized platform 😬) but you can also try these instructions that scan your Twitter follow list for exact matches on Bluesky. The default client also has a good trending feature (or at least it did when I started; the client’s defaults have changed somewhat since then.) You can also search for “starter packs”—groups of up to 50 people, usually organized around a theme, that you can follow en-masse.
- On Mastodon, try Mammoth as your first client. It is from a variety of ex-Moz folks, and focuses on making sure you don’t start with an empty timeline, so it’s a great client to use on day one. (Once you’re settled in, I highly recommend using Phanpy.social—a genuinely excellent, full stop, social media client.)

#Handling the transition

Small town, not big city: Don’t treat other networks like 2020s twitter, when you were picky about who you followed and humble about who you interacted with. Treat it like 2010s twitter, when we all followed quite a few randos, and said things like “hi” and “thanks for sharing that!” It’s the sociality of a small frontier town, not the big city—and so far I find that mostly endearing.
Post on Twitter… sometimes. While I was transitioning, I followed the “Xlast” strategy: continue to post on Twitter when that’s important, but do it after you have posted elsewhere, and respond less. However, I rarely bother these days—I don’t know if I’m “shadowbanned” or it’s just that most of my friends have left, but I pretty much always get more interaction (often orders of magnitude more) for the same content on Mastodon than on Twitter.
- Note that, if you do content professionally, Buffer can now post out to Bluesky and Mastodon—probably worth looking into.
Read Twitter via lists, not algorithms: California neo-urbanists are professionally important to me (because of my work with the California Housing Defense Fund) but have stayed mostly on Twitter. To follow them, I use a Twitter list. This helps me get what I actually want and avoid the elonified algorithm. (That said, more and more urbanists are making the Bluesky switch, so I’m hopeful I’ll be able to dump this soon.)
Filter aggressively: Mastodon has great filtering capabilities, which makes following a lot of people easier. Bluesky’s filtering is still a little experimental, but shows great promise. Both make my 2020 advice on social media in an election year very relevant.

#Things I wish were better

This section used to be fairly long, but I’ve cut it because so many problems have been solved. As of August 2024, I primarily miss two things:

The AI community is still aggressively on Twitter. What that says about the morality of the AI community (genuinely, not all bad!) is left as a judgment for the reader. I fill the gap mostly with the AI News newsletter.
By and large, the international and Black American communities are still on Twitter (or at least, aren’t actively on the alternative platforms). This is a deep and genuine loss. Some of the best of the (not so) new generation of Black American political writers, like Jamelle Bouie and Adam Serwer, are on Bluesky, but the platform (like Twitter before it) struggles with brigading and racism.

#The “warrior position” of optimism

Optimism is a hard choice to make. It requires what Nick Cave calls “a warrior position” to discard old habits and forcefully build new ones.

That’s particularly true here, where the alternative options are far from perfect—we really are walking away from not just a company, but from humans; and we’re walking towards well-known problems of underfunded feature development, and harder, towards deeply unknown problems of community-centered moderation (or lack thereof). (Or, in the case of Threads, we’re walking towards a different company whose owner also counts an unapologetic fascist as a friend and former board member.)

But if not now, when? if not us, who? Come, raise the barn with me. We can build something that may be rickety and imperfect, but will be ours in a way that won’t—can’t—be true of Twitter.

The brief guide to MSCD 5

Wed, 31 May 2023 00:00:00 GMT

My primary goal when trying to improve a contract’s drafting is not “plain english”. The goal is simplicity, clarity, and consistency, because complexity is a source of errors. As a pleasant side-effect, contracts drafted with rigorous attention to consistency and clarity are generally shorter, and almost always much easier to read.

Ken Adam’s Manual of Style for Contract Drafting has helped me immeasurably in reaching that primary goal, both by teaching me habits of mind and by being a reference for better linguistic structures.

But it’s also hefty.

So I prepared this mini-guide to MSCD for an outside counsel: it’s what I recommend first-timers read, skim, and skip. I share it here in hopes it may be useful for others.

All section references are to the Fifth Edition, but at least at the chapter level most should apply to earlier versions as well.

#MSCD core concepts

These are the most impactful sections of MSCD.

#Introduction

If you are confused about why I recommend the book, read “About this manual”, “Traditional Contract Language is Dysfunctional”, and “Excuses for Sticking With Traditional Contract Language”. Skip or skim the rest.

#Ch. 1: Characteristics of Optimal Contract Language; Ch. 17: Drafting as Writing

These can be skimmed, since in some sense most of it will be obvious to anyone who has given any thought to better contract language. But both are good, and brief, and explain (in part) why traditional drafting is so bad. So if you find yourself confused by something in other chapters, come back to these two—they may help explain things.

While reading, I particularly recommend these sections, which have had the biggest impact on my personal drafting style and are, in my experience, the biggest red flags for errors that stem from bad “traditional” drafting:

“Contract Language Shouldn’t Be Legalistic” (1.7-1.28)
“Contract Language Should Express Ideas without Redundancy” (1.35-1.56)
“Contract Language Should Be Consistent” (1.57-1.60)

#Ch. 2: Front of the Contract; Ch. 5: Back of the Contract

In my practice area, the front and back matter are not usually the source of critical errors, so I do not religiously follow these sections. However, I find that attention to detail on these topics is both a good introduction to MSCD’s style of thinking, and (when I do them in a contract) help put me in a rigorous frame of mind for the rest of the document. So these chapters are worth skimming and then consistently using as a reference.

If you are pressed for time, 95% of chapter 2’s value can be obtained by:

reading 2.129-2.150, Recitals. Once you get used to improving the drafting of the recitals, it sets a good tone for the rest of the document.
reading 2.159-2.164, Wording of the lead-in. Understanding, and sticking with, Ken’s recommended use of “agree” here sets up Ch. 3’s critical “categories of contract language”.
skimming Samples 1 and 2, and Appendix A’s front matter, to get the flavor of the kinds of improvements that can be made to most contracts.

Ch. 5 is similar—just skim the back matter of Appendix A, then refer to the samples in the chapter for models.

#Ch. 3: Categories of Contract Language

If you only read one chapter, read this one.

This chapter is the core of MSCD’s style of thought: the core of clear and correct drafting is that different parts of contracts do different things, and you should rigorous using specific language to implement each of those things.

You can do a lot to improve a contract simply by looking at each table in this section, reading the relevant section to understand the tables, and cleaning up every reference in a contract from the table’s disfavored language to the favored language. Doing this consistently across the entire contract will force rewrites that leave the resulting language much clearer, more precise, and more accurate.

Two words discussed in this chapter are particular warning signs for me when I see them misused in a contract: “shall” (particularly 3.115-3.132 and Table 2) and “agrees” (3.27-3.30). Again, simply cleaning these up is a great way to do a “first pass” edit of a document—doing this helps you think about what each clause of a contract is actually trying to do, and often leads to more correct, more readable drafting.

#Ch. 13: Selected Usages

This is a reference section, not something to read end-to-end. But it’s invaluable. When you find something that “feels wrong” in a contract, you’ll often be able to come to this section and find a much better, clearer way to state it. You may have to rewrite things substantially, but you’ll have a more logically consistent, consistent, correct, clearly-readable document when you’re done.

I suggest skimming the table of contents, and then reading a few examples to give you the flavor of it. A couple of my favorites:

For the Avoidance of Doubt: 13.312-319
“Including”—long, but a great analysis of the complexity and nuances of a single word: 13.359-407

#Ch. 14: Numbers

Read the brief part on “Words or Digits” to learn why there should be zero(o) instances of number(numeral). Skip or skim the rest.

#Advanced Drafting to Reduce Ambiguity

These chapters are useful primarily for the most complex drafting problems. I tend to do a “first pass” edit based on the “core concepts” chapters I identified previously.

If that first edit pass identifies a particularly complex/problematic section, then the concepts in these chapters can be quite helpful in making the challenging contract sections more correct.

Ch. 7: Sources of Uncertain Meaning: 95% of the value of this chapter is one concept: the distinction between ambiguity (bad, unintentional, should be eliminated) and vagueness (intentional, may be strategic, must be deployed carefully).
Ch. 11: Ambiguity of the Part v. The Whole: most useful in commercial contracts where it’s important to be precise about what is being sold (or not).
Ch. 12: Syntactic Ambiguity: a collection of techniques that are frequently useful in deconstructing, and then reconstructing, extremely long or complex sentences.

#Interesting but not useful (to me/my practice)

These chapters are intellectually interesting but I have not found them to be particularly high-impact on my practice. Might be different for your practice!

#Ch. 6: Defined Terms

I do not find definitions to be a significant source of problems, as a practical matter, so don’t find this chapter hugely valuable.

However, there are a few sections that cover errors that I find frequently, so are more useful than the rest:

“Be Consistent” (6.8-6.13)
“stuffed definitions” (6.49-58)
Mistakes: 6.110-6.122

I don’t usually follow the advice of “where to put the definition section” (6.96-6.98), but I think it’s at least worth trying in many documents.

#Other interesting-but-less-useful-to-me chapters

These chapters are all interesting for drafting nerds, and may be relevant to some practices, but not frequently an issue for me.

Ch. 8: Reasonable Efforts
Ch. 9: Materiality
Ch. 18: Amendments; Ch. 19 Letter Agreements

#Neither interesting nor useful (to me/my practice)

I mostly ignore these—they’re not wrong but the bang-for-buck of rewriting with them in mind is pretty low, in my experience.

#Ch. 4: Layout; Ch. 16 Typography

I tend to rely on Butterick’s Typography for Lawyers for these topics.

#Ch. 10: Time

Suspect most relevant for certain types of commercial contracts where extreme specificity about time (delivery, etc.) are common sources of disputes.

#Ch. 15: Internal rules of interpretation

Have never seen one of these in the wild that I can recall.

Announcing the Upstream podcast

Tue, 16 May 2023 00:00:00 GMT

Open is 1️⃣ all over and 2️⃣ really interesting and yet 3️⃣ there’s not enough media that takes it seriously as a cultural phenomenon, growing out of software but now going well beyond that.

And so, announcement: I’m trying to fill that hole a little bit myself. Tidelift’s new Upstream podcast, which I’m hosting, will:

Pull from across open, not just from software. That’s not because software is bad or uninteresting, but because it’s the best-covered and best-networked of the many opens. So I hope to help create some bridges with the podcast. Tech will definitely come up—but it’ll be in service to the people and communities building things.
Bring interesting people together. I like interview-style podcasts with guests who have related but distinct interests—and the magic is their interaction. So that’s what we’ll be aiming for here. Personal goal: two guests who find each other so interesting that they schedule coffee after the recording. Happened once so far!
Be, ultimately, optimistic. It’s very easy, especially for experienced open folks, to get cynical or burnt out. I hope that this podcast can talk frankly about those challenges—but also be a recharge for those who’ve forgotten why open can be so full of hope and joy for the future.

So far I’ve recorded on:

The near past (crypto?) and near future (machine learning?) of open, with Molly White of Web 3 Is Going Great and Stefano Maffuli of the Open Source Initiative. Get it here! (Transcripts coming soon…)
The joy of open. At Tidelift, we often focus on the frustrating parts of open, like maintainer burnout, so I wanted to refresh with a talk about how open can be fun. Guests are Annie Rauwerda of the amazing Depths of Wikipedia, and Sumana Harihareswara—who among many other things, has performed plays and done standup about open software. Will release this tomorrow!
The impact of open on engineering culture, particularly at the intersection of our massively complex technology stacks, our tools, and our people. But we are often so focused on how culture impacts tech (the other way around) that we overlook this. I brought on Kellan Elliot-McCrea of Flickr, Etsy, and Adobe, and Adam Jacob of Chef and the forthcoming System Initiative to talk about those challenges—and opportunities.
The relationship of open to climate and disasters. To talk about how open intersects with some of the most pressing challenges of our time, I talked with Monica Granados, who works on climate at Creative Commons, and Heather Leson, who does digital innovation — including open — at the IFRC’s Solferino Academy. I learned a ton from this one—so excited to share it out in a few weeks.

Future episodes are still in the works, but some topics I’m hoping to cover include:

open and regulation: what is happening in Brussels and DC, anyway? Think of this as a follow-up to Tidelift’s posts on the Cyber Resilience Act.
open and water: how does open’s thinking on the commons help us think about water, and vice-versa?
open and ethics: if we’re not technolibertarians, what are we anyway?

I’m very open to suggestions! Let me know if there’s anyone interesting I should be talking to, or topics you want to learn more about.

We’ll be announcing future episodes through the normal Places Where You Get Your Podcasts and the Tidelift website.

Notes on using Freedom to block digital distractions

Mon, 24 Apr 2023 00:00:00 GMT

“Escape” by Metaphox is licensed under CC BY 2.0, via openverse.

I’ve been using freedom.to more or less since it launched. I was recently asked by someone how I use it, and since it didn’t fit in the text box on that platform, here’s a mid-ish-long set of notes on how I use it.

Everywhere: It’s on all my devices, no exceptions—iPad, phone, desktop work computer.
Scheduled sessions: I use what Freedom calls “sessions” to schedule blocks of time that block out distracting sites. My current blocked sessions are:
- Working hours: Mostly self-explanatory, starts an hour after school drop-off so I can do some messing around or necessary social stuff before work. Also includes a lunch break every day (actually implemented as two sessions), though unfortunately that isn’t synced to my calendar so sometimes I am unblocked while working and then blocked during my actual lunch.
- Morning self-care block: There’s an hour in the morning (before family breakfast) that blocks social plus work stuff. Ideal (not always respected) is that I should be using this time mostly for fitness or meditation, not the device. Am sorely tempted to replace this with just keeping the device well away (probably upstairs) and using an Apple TV device for fitness/meditation.
- Evening family block: From roughly when my son gets home to his bedtime, blocks primarily social. Can still do some work if sorely needed but try to avoid social during that time.
Add sites freely: If I’m at all tempted by a site, I add it to the Blocklist. Better to overblock than underblock. (I understand why it probably can’t, but it’d be neat if Freedom monitored web usage, said “I notice that you’ve visited this more than X times today, would you like to block it?” Bonus for: “and add its RSS feed to your feed reader?”) In particular, I mass block sports, social, and news sites—you simply don’t need those things most of the time.

Because of my recent participation in the Mind Over Tech Accelerator trainings (which I cannot endorse enough if you struggle with digital focus!), I’ve made some recent experimental changes to my freedom use. I’m not sure yet if these will stick long-term:

Breakfast-time session: I’m experimenting with blocking more things during my family breakfast (6:50-7:50) and just relying on voice control or a shared family kitchen iPad for the few things I need to do during that block. In other words, using Freedom to force me not to touch my own devices during this block of family time.
Pomodoro: I’ve been experimenting with Forest for pomodoro timing, but I do wonder if I can do Freedom instead.
Apps: Freedom just added the ability to block apps, so I don’t use this yet. Not sure if I will, because most of the things that suck my time can be dealt with by blocking their network connections.

My challenges with Freedom (suggestions welcome!):

Reliability: Because Freedom is inherently doing something that the operating system doesn’t love (interfering with your use of the device!) it sometimes stops working, and you have to re-engage it. Which is fine, unless… I’m doing something that it wants to block. For example, during a recent trip, it disengaged and it was more convenient for various reasons not to turn it back on. Which was fine except now I’m back home, I should turn it back on, and I’m… not. (I’ll do it right after I post this! Probably!)
Social: My work does sometimes genuinely require use of social, which is hard if you’ve… blocked all social with Freedom. I don’t have a great solution to this, but people are mostly reasonable if you say “actually, I have social blocked on this machine, is it OK if [I do it later, you screenshot it, etc.]”
Location: This is a very First World Problem, but when I travel to another timezone, Freedom assumes I’m trying to cheat (not unreasonable!) and stays on my home timezone. I wish it would check my actual location (GPS?) and update automatically to match where I actually am.
Slack: My most distracting friend groupchat is on slack, and there is no good way (as far as I know) to only block my friend slack while not blocking work slack. I solve that on my primary work computer by simply not logging into friend-slack on that machine, but on other devices I use during the work day (most painfully my iPad) it can be a distraction.

Overall this is an amazing product, and if you struggle with digital distractions I highly recommend it.

Writing elsewhere; the pain of moving platforms

Sun, 19 Mar 2023 00:00:00 GMT

I’ve been doing a lot of writing elsewhere of late. Some links:

I’ve written a fair amount in the past year for the Tidelift blog, most recently on the EU’s Cyber Resiliency Act and what it might mean for open source.
I wrote last week at opensource.com; the latest in a now multi-year series on board candidates in elections for the Open Source Initiative.
I have a newsletter on the intersection of open and machine learning at openml.fyi. It is fun!
I’ve moved to the fediverse for most of my social media—I’m social.coop/@luis_in_brief (and you can subscribe to this blog via the fediverse at @lu.is/@admin).

I don’t love (mostly) leaving Twitter; as I’ve said a few times, the exposure to different people there helped make me a better person. But one of my primary political concerns is the rise of fascism in the US, and that absolutely includes Elon and the people who enable him. I can’t quit cold-turkey; unfortunately, too many things I care about (or need to follow for work) haven’t left. But I can at least sleep well.

7 questions for the OSI board candidates

Mon, 13 Mar 2023 00:00:00 GMT

Originally published at opensource.com.

The Open Source Initiative (OSI) is a non-profit organization that promotes open source that maintains and evaluates compliance with the Open Source Definition. Every year the OSI holds elections for its board of directors. It has become somewhat of a tradition for me to write questions for OSI board candidates.

In past years, I’ve asked questions about the focus of the organization and how the board should work with staff. The board has since acted decisively by hiring its first executive director, Stefano Maffuli. It has also expanded staffing in other ways, like [hiring a policy director](https://blog.opensource.org/rising-to-answer-the-call-sound-public-policy-for-open source-questions/). To me, this is a huge success, and so I didn’t pose those questions again this year.

#Repeated questions

Other prior questions are worth repeating. In particular:

Your time: “You have 24 hours in the day and could do many different things. Why do you want to give some of those hours to OSI? What do you expect your focus to be during those hours?”

This question is a good one to ask of applicants to any non-profit board. Board work is often boring, thankless, and high-stakes. Anyone going into it needs to have not just a reason why but also a clear, specific idea of what they’re going to do. “Help out” is not enough—what do you conceive of as the role of the board? How will you help execute the board’s fiduciary duties around finances and executive oversight etc.?

OSI has had trouble retaining board members in the past, including one current candidate who resigned mid-term during a previous term. So getting this right is important.

Broader knowledge: What should OSI do about the tens of millions of people who regularly collaborate to build software online (often calling that activity, colloquially, open source) but don’t know what OSI is or what it does?

I have no firm answers to this question—there’s a lot of room for creativity here. I do think, though, that the organization has in recent years done a lot of good work in this direction, starting in the best way—by doing work to make the organization relevant to a broader number of folks. I hope new board members have more good ideas to continue this streak.

#New at OSI

Two of my questions this year focus on changes that are happening inside OSI.

Licensing process: The organization has proposed improvements to the license-review process. What do you think of them?

Licensing is central to the organization’s mission, and it is seeking comments on a plan to improve its process. Board members shouldn’t need to be licensing experts, but since they will be asked to finalize and approve this process, they must have some theory of how the board should approach this problem.

OSI initiative on AI: What did you think of the recent OSI initiative on AI? If you liked it, what topics would you suggest for similar treatment in the future? If you didn’t like it, what would you improve, or do instead?

The OSI’s Deep Dive on AI represents one of the most interesting things the organization has done in a long time. In it, the organization deliberately went outside its comfort zone, trying to identify and bridge gaps between the mature community of open software and the new community of open machine learning. But it was also a big use of time and resources. Many different answers are legitimate here (including “that shouldn’t be a board-level decision”) but board members should probably have an opinion of some sort.

Skip to bottom of list

Our favorite resources about open source

#New outside forces

Finally, it’s important for OSI to carefully respond to what’s happening in the broader world of open. I offer three questions to get at this:

Regulation: New industry regulation in both the EU and US suggests that governments will be more involved in open source in the future. What role do you think OSI should play in these discussions? How would you, as a board member, impact that?

The OSI has done a lot of work on the upcoming EU Cyber Resilience Act, joining many other (but not all) open organizations. This will [not be the last](https://blog.tidelift.com/tidelift-advisory-impact-of-new-u.s.-national-cybersecurity-strategy-on-organizations-building-apps-with-open source-software) government regulation that might directly affect open software. How OSI should prioritize and address this is, I think, a critical challenge in the future.

Solo maintainers: The median number of developers on open source projects is one, and regulation and industry standards are increasing their burden. How (if at all) should OSI address that? Is there tension between that and industry needs?

Many of the candidates work at large organizations—which is completely understandable since those organizations have the luxury of giving their employees time for side projects like OSI. But the median open software project is small. I would love to hear more about how the candidates think about bridging this gap, especially when [unfunded mandates](https://opensource.com/article/21/8/open source-maintainers) (both from governments and industry standards) seem to be continually increasing.

Responsible licensing: There are now multiple initiatives around “responsible” or “ethical” licensing, particularly (but not limited to) around machine learning. What should OSI’s relationship to these movements and organizations be?

A new generation of developers is taking the ethical implications of software seriously. This often includes explicitly rejecting the position that unfettered source-code access is a sine qua non of software that empowers human beings. OSI does not need to accept that position, but it must have some theory of how to react: silence? firm but clear rejection? constructive alliance? educational and marketing opportunity?

#The Bottom Line

The OSI has come a long way in the past few years and recent board members have a lot to be proud of. But it’s still a small organization, in tumultuous times for this industry. (And we’ve unfortunately had recent reminders that board composition matters for organizations in our space.) Every OSI member should take this vote seriously, so I hope these questions (and the candidate’s answers on the OSI blog) help make for good choices.

Book Notes: Summer 2022 (burnout and the good life)

Mon, 25 Jul 2022 00:00:00 GMT

I promised in my post on water to blog more this summer. So far, so fail, but in part it’s because I’ve been reading a lot. Some miscellaneous notes on those books follow.

“An interesting bookshelf photorealistic”, as rendered by Midjourney’s image-creation AI, another summer hobby.

Those of you who have emailed my work address lately will have noticed I’m also on sabbatical this summer, because after five years of focus on Tidelift I’m feeling pretty burnt out. This is not a criticism of Tidelift: it’s a great team; I’m very proud of what we are doing; and I will be going back shortly. But a big theme of the summer has been to think about what I want to do, and how that intersects with Tidelift—so that when I come back I’ll be both a strong contributor, and a happy and healthy contributor.

#Work—burnout and better futures

The End of Burnout, by Jonathan Malesic: Malesic puts the blame for burnout squarely on our culture rather than us as individuals, which means the book has very few prescriptions for how we as individuals can deal with burnout. But it has interesting meditations on how we can create a culture that mitigates against burnout.

I hope to do a fuller review soon, because I find it difficult to summarize quickly, and much of it applies to open collaborative communities, where the line between self-affirming creation and self-destructive labor can be very fluid. In the meantime, I’ve put some of my favorite quotes up on Goodreads and annotated many of them.

Imaginable, by Jane McGonigal: I found this equal parts fascinating and frustrating.

Good: it helped me ask “what the hell am I doing” in much better ways. Two key tricks to this: asking it in a ten year timeframe, and using a bunch of neat futurist-y brainstorming techniques to help think genuinely outside of the box. For this reason I think it might end up being, in ten years, the most influential “self-help” book I ever read.

Bad: it’s a classic “this book should have been an article”, and it is the first time I’ve thought “this book should have been an app”—the structured brainstorming exercises could have been much more impactful if guided with even minimal software. There actually is a companion(?) pay-to-enter community, which so far I’ve really enjoyed—if I stick with it, and find value, I suspect in the future I’ll recommend joining that community rather than reading the book.

Other big failure(?): it focuses a lot on What Is Going On In The World and How You Can Change It, when one of my takeaways from Malesic’s burnout book was to focus less on The World and more on the concrete people and places around me. The book’s techniques are still helpful for this, which is why I think it’ll be impactful for me, but I think it’d be a better book if its examples and analysis also drilled down on the personal.

#Place

I’ve had the luxury of spending the summer in Bozeman, visiting my sister and nieces/nephew. So a few books on Montana:

History of Montana in 101 Objects: Terrific. Great selection of objects; thoughtful but concise essays. I wish someone would write the same about SF. Highly recommended for anyone who spends time in the state.

Ties, Rails, and Telegraph Wires, by Dale Martin: A thing that is hard to wrap one’s head around when it comes to Montana is the vastness of the place; fourth biggest state, and 7.5 people per square mile. (CA: 254/mi2; SF: 6,200/mi2, The Mission: 30K/mi2.) This book does a lovely job capturing the vast spaces of Montana at the beginning and end of two massive technological changes: the coming of the train and the coming of cars. Bonus: lavishly photographed (largely via the work of Ron Nixon).

#Water, Climate, and Climate Action

A disconnect I’ve been struggling with is between my digitally-focused work and my increasing concerns for/interest in the Real World. Related reads:

Introduction to Water in California, by David Carle: Recommend strongly if you’re a Californian wanting to geek out, but for most the Wikipedia article is probably sufficient.

How To Blow Up A Pipeline, by Andreas Malm: I recommend every citizen of the developed, carbon-dependent world read this. It might not motivate you to commit violence against carbon-generating property, but it will at least put you in the right place to react appropriately when you see reports of such violence against property. There’s a lot to unpack, and again, I recommend reading it, but at the end of the day much boils down to an image from the end of the book: when the author and other allies took down a fence around a brown-coal power plant, even Green party politicians condemned that as “violence”. The emissions of the power plant themselves? Not condemned; not considered violence in our discourse or politics.

#Asceticism I didn’t read

In the past, I’ve on occasion turned to a certain sort of philosophical asceticism when in a frustrated place. So I packed these:

Zen and the Art of Motorcycle Maintenance: I liked this book a lot in my teens and 20s, and much of the focus on Quality still resonates with me. I thought it’d be fun to re-read it in Bozeman (where much of the book takes place). But ultimately I haven’t even cracked the cover, because right now I don’t want to retreat to craft, no matter how well done. Instead, an outgoing, community-centric approach to life feels more appropriate.

Meditations of Marcus Aurelius, translated and annotated by Robin Waterfield: Unlike Zen and…, I have started this one, and would highly recommend it—the translation is very accessible and the annotations are terrific. But again, the detached life feels like the wrong route right now—even if it is one that in the past I’ve fallen into very easily.

#Fiction

Read a fair bit of fiction over the summer, much of it light, trite, and not worth recommending or even thinking much about. If you want every detail, it’s in my Goodreads feed; the best of it will get added at some point to my mega-thread of diverse science-fiction/fantasy recs over on Twitter.

Water on the brain; joining OpenET board

Thu, 09 Jun 2022 00:00:00 GMT

I’m becoming a Westerner (in an age of aridification) because I have water permanently on the brain.

vacation reading: Introduction to Water in California
vacation activity: teaching A about center pivot and drip irrigation
recent Wikipedia editing: evapotranspiration

Sprinkler irrigation, gone awry.

Center-pivot irrigation. Enjoyed showing to A how this looked in satellite.

Drip irrigation, with Mt. Shasta.

View from vacation dinner. In almost the center (but you’ll have to squint) was a pump that was filling trucks, moving the water to other (nearby?) farms.

Four forms of water usage, one farm.

Quite related, I’ve joined the board of OpenET to help bring open data on evapotranspiration (a key part of the water cycle) to Colorado River water management, and eventually to the whole world. I’ll be advising on both basics like licensing and of course the more complex bits like economic sustainability, where (via Tidelift) my head mostly is these days.

Many thanks to John Fleck (GNOME documentation project, ret.) for dragging my head into this space years ago by writing about it so well for so long.

Broader opens: on the relevance of cryptolaw for open lawyers

Mon, 23 May 2022 00:00:00 GMT

I’ve been thinking a lot of late about what “libre” and “open” mean to me, in large part by thinking about movements adjacent to open source software, and how open software might learn/borrow from its progeny. I hope to go into that more this summer, but in the meantime, I’m publishing this as a related “just blog it and get it out” note.

A chart from a recent presentation I gave on legal topics adjacent to open. Security, DAOs, smart contracts, and Swiss non-profits, among others, show up here and stem from, or are more salient in, the crypto space.

This post started as an email to a private list, giving my best-case argument for why open lawyers should pay attention to crypto/blockchain/web3 even if it’s apparent that most of these things are at best naive and at worst planet-destroying scams. I think it’s worth sharing in public to get more comments and more thoughts on this attempt to steel man the argument for cryptolaw.

So, why should open-adjacent lawyers take crypto seriously?

#The Bad Bits

#Liability

I’ll start with a point designed to appeal to the most diehard crypto-haters (and to be clear, that’s mostly me too!) Quite simply, crypto (particularly but not just smart contracts) is an almost ideal test case for anyone who wants to bring product liability into software. For decades now, we’ve argued (essentially) that software is too complicated, and so software developers should not be liable when it breaks. And in any case, how do you figure out who owes what to whom when it breaks?

In crypto, those arguments start to look particularly weak. The code is much simpler, and the damages are very specific and clear: “my money(-like-thing) disappeared!” And of course this breakage happens all the time; I haven’t looked but I assume there’s an entire category on Web 3 Is Going Great devoted just to software bugs.

Given all this, lawyers will be tempted to bring product liability cases, and judges will be tempted to resolve them. If that happens, and it finally brings serious product liability to software, what does that mean for our FAVORITE BLOCKS OF ALL-CAPS TEXT? To put it another way: the worse you think blockchain is, probably the more worried you should be about the impact of blockchain on every free software license.

(For this point, I am indebted to Mark Radcliffe, who has been writing and speaking on this issue for a while.)

#Ethics, or lack thereof

To continue again with the “the more you hate crypto, the more you should pay attention” theme: lots of developers also hate crypto! In the past year I have been repeatedly asked about anti-crypto riders to attach to open source licenses. This would of course make them non-OSI-approved, but lots of developers hate crypto even more than they like (or are aware of) OSI. I suspect that if ethics-focused licenses ever really take off, anti-crypto energy may be the main driver. How those licenses are defined will make a difference, possibly in clauses that live well-past the current crazy.

#The Better(?) Bits

#Creates lots of code

To turn towards the more positive side: crypto is one of the most dynamic nearly-completely-FOSS sectors out there; it’d be weird for the open community more broadly to ignore them as FOSS consumers and producers. They write a lot of FOSS-licensed code!

As a practical matter, even if you think tokens/blockchain are likely to fail in the long run, it is likely that some of this code will leak back into non-token applications, so its licensing (and related: licensing hygiene) matters.

#Governance innovation

Open source communities have traditionally had at least some members interested in how to govern online communities. Many of us who have been around long enough will have participated in more than one discussion of which version of Ranked Choice Voting to use 😭

Crypto is innovating furiously in the online governance space. As with all “innovation” most of that will turn out to be pointless or actively bad. But as a few practical examples of how it is filtering back into open source:

questioning Delaware as a default incorporation location for open-adjacent non-profits, particularly in favor of Switzerland
DAO-like proposals for the “exit to community” of Open Collective
Governance putatively optimized for financial sustainability

Again, most of that is somewhere between naivete and scam, but not all of it. Open lawyers (and open leaders more generally) should be aware of these ideas and have responses for them.

#Taking ‘freedom’ seriously, sometimes

Related to the previous point, as the Cryptographic Autonomy License process reminded us, at least some crypto communities are taking the principles of free software very seriously and extending them to critical future issues like data governance and privacy. If open source wants to move the ball forward on these values and methodologies, the action is by and large in crypto (even if finding the good-faith action is a little bit like finding a needle in a haystack of greed and scams).

#‘Smart’ contracts as new legal form?

Smart contracts are mostly garbage (because they are software and most software is garbage) but the interface of this new legal form with existing institutions is both (1) intellectually interesting and (2) has a lot of parallels to early adoption of open licensing as a legal form/tool. I’d love to interview the author of this paper on smart-contracts-as-vending-machines, for example. Similarly, I suspect there is something to be learned from efforts to bring arbitration to the smart contract space.

#Money and interest

Finally, there is, quite simply, a pile of crypto-derived money and therefore employment out there. I personally find taking that money pretty distasteful, but lots of friends are taking it in good faith. Every open and open-adjacent lawyer will be getting questions (and many of will be getting paid for their time) out of that pile of money in coming months and years.

Whether we like it or not, this money — and the people paid by it — will set agendas and influence directions. We need to take it seriously even if we dislike it.

#Closing (re-)disclaimer

Again: lots of cryptocurrency/web3 is malicious, and the primary legal response to carbon-emitting proof-of-work should be to figure out how to lock people up for it.

But there are, I suspect, a growing number of overlaps between what “we” do in “open” and what “they” are doing “there”. If we want to be seriously forward-looking, we need to take it seriously even if we hate it.

Editing a background check policy

Fri, 05 Nov 2021 00:00:00 GMT

We’re implementing a background check policy for some roles at Tidelift, because we see security-critical information from our customers. Our background check provider (who I won’t name, because this isn’t about them) has a template policy that is pretty good! But the rest of their product has a very high standard for UX—their designers generally do not settle for pretty good.

“The red pen bleeds during term paper season… (11/52)” by Rodger_Evans is licensed under CC BY-ND 2.0

Since I know they care, and since employment documents (especially ones that relate to bias) are an important way Tidelift communicate about our company values, I took the time to send them my changes. Having done that work I figured I’d make it a blog post too :) Some notes:

#Consistency between software and legal documents

A legal document is, in many cases, a part of a company’s user experience. As such, it needs to be vetted for consistency with the rest of the software, just as you’d vet any other part of the UX.

This is hard, and easy to screw up, because let’s face it—who likes reading and re-reading legal documents? Not even lawyers, if we’re being honest. This particular document screws this up in two ways.

First, the tool (very correctly!) encourages companies not to do a background check for every position, since that introduces a significant bias against people who may have been rehabilitated and should have a fair chance at employment. But the legal document says very plainly that “all offers of employment are contingent on … a background check” (emphasis mine). The legal terms must be brought into alignment with the software’s reality.

Similarly, one of the benefits of this tool is that it takes care of the paperwork for you—without pens and paper. And yet the legal document says that a “signed, written consent will be obtained … in compliance with … law”. Now, good American lawyers know that under the E-SIGN Act of 2000, lots of digital things are “signatures” for the purposes of American law, but most people don’t know that. Good drafting will avoid confusing these non-lawyers by simply saying the consent will be “explicit” and recorded by the service.

#Multi-clause sentences and checklists

This is not always the case, but many sentences in legal documents would benefit from being broken up into bullet points, so that each criteria is easier to follow or even treat as a checklist. Consider the difference between:

A decision to withdraw an offer of employment will be made only after conducting an individualized inquiry into whether the information obtained is job-related and a decision to withdraw an offer is consistent with business necessity.

Original policy

And:

A decision to withdraw an offer of employment will be made only after conducting an individualized inquiry into whether:

the information obtained through the reference check is relevant to the nature and performance of the role; and

withdrawal is consistent with the business’s needs.

My revisions

This sounds sort of trivial, but clear writing really can help you spot errors. In this case, breaking up a sentence into bullet points made me notice that the document was inconsistent—an important anti-bias process step was listed in another section, but silently dropped in this list. So someone skimming just the one section of the policy might get it very, very wrong. (Programmers reading this will be nodding along right now—this is debugging by using better formatting to ease code inspection.)

Similarly, where a process is spread across multiple paragraphs, consider using numbered bullet points to emphasize the checklist-like nature of the process and improve the ability to discuss. Much easier to ask “did you do step 4” than “did you do the second clause of the third sentence”.

#Q&A style

I continue to believe that many legal documents should at least be edited (not necessarily finalized) in a Q&A style—in other words, changing each section header to a question, and making sure the section actually answers the question. I talked a bit more about that in this post about doing it for a draft of the Mozilla Public License.

In all cases, doing this forces you to make sure that each section has a focused, clear purpose. For example, in the original draft of this policy, there was a section titled “Evaluating Background Check Results”. Revising that into a question (“How will we evaluate the results of the background check?”) helped me realize that one sentence was about a related, but different topic—privacy. Breaking that out into its own privacy section both clarifying the original section and allowed the new section to respond more forcefully to employee concerns about confidentiality.

In the best cases the Q&A framing can really help understanding for non-legal (and even legal) readers. In this case, I found that a well-placed question helped differentiate “why the company does it” from “how the company does it”—which was muddled in the original draft, and important to aid understanding of a tricky anti-bias concept.

#Be careful about definitions

Last but not least—you can often tell when a document has suffered from copy/paste when it uses a defined term exactly once, rather than multiple times. Not only does this give you the opportunity to remove the defined term (in this case “Company”) but it also reminds you to give extra focus on the ways that term is used, since it is likely to have copy/paste problems. (In this particular case the stray “Company” thankfully didn’t point to anything worse than jarring word choice—but at least it was easy to eliminate!)

#Interested in learning more? Come work with me!

I can’t promise we approach everything with this level of detail; we’re still a small startup and one of the ways we balance the tension between pragmatism and idealism is to Just Get Things Done. But I’m also proud of the way so many of us think through the things some other companies get wrong. If that sounds like fun, we’re hiring!

Notes on histories: the European nation-state, the Lakota, and Athens

Tue, 05 Oct 2021 00:00:00 GMT

I have been doing a variety of history reading of late, but have not had time to properly synthesize them. They keep coming up in conversation, though, so I wanted to write down some bullet points I could refer to. I hope they are interesting and/or provocative in a good way to someone.

Resemblance to the history of open source was rarely why I read these books. (In fact at least one was read deliberately to get away from open source thinking.) And yet the parallels — around power, mindshare, “territory”, autonomy, empowerment, innovation—keep coming back to me. I leave conclusions, for the most part, for now, to the reader.

Final disclaimer: in the interest of finally publishing a damn thing (I read Ober years ago!), this post will necessarily condense and butcher thousands of pages of scholarship. Please read with that in mind — errors and oversights are almost certainly mine and not the fault of the original authors.

#The Sovereign State and Its Competitors, Hendrik Spruyt

Triskelion by Zack McCune, CC BY via Noun Project

This book attempts to understand how Europe got from feudalism to the modern nation-state. It’s explicitly an argument against a view of history where nation-states were inevitable, instead trying to show that there were other possible paths during the late Middle Ages. (The book is very Euro-centric without acknowledging that, which is a shame since I think the book would be well-complemented by an analysis of how European nation-states interacted in colonial settings with non-nation-states, about which more later.)

The core argument goes something like this:

what is feudalism anyway? at some level, it means “no entity has a monopoly on power in a territory”, because feudal lords, the church, tribal-like kinship relationships, etc., all overlap and interact in complicated ways.
you get out of feudalism, and into nation-states by:
punctuated-equilibrium-style evolution: a major shock to existing system (in Spruyt’s analysis, massive economic growth starting in c. 1000) which creates new power centers (bourgeoisie and new cities), which destabilizes feudalism and …
creates a diverse set of post-feudal options: wealthy, powerful city-states in Italy; leagues of cities in Germany; something like the modern nation-state in France. (It is this diversity which Spruyt says a lot of historians ignore, and certainly which American high-school history completely ignores.) But…
that situation (with a lot of different, competing options) is unstable even if each individual solution makes sense for that place/time (i.e., “city-states were stable in/good for Italy” and “city-states were not stable in/fit for Europe” can both be very true), so then…
competition and conscious self-selection leaves you with modern nation-states on top, for a variety of reasons, including simply that nation states prefer negotiating with other nation-states; i.e., hard for France to make treaties with a loose coalition (league) of cities, so it partners with (and therefore empowers) other units like it.

I would love to see a similar analysis for the history of various corporate forms or industries. I’ve seen it suggested, for example, that the combination of the telegraph and the railroad made multi-jurisdiction limited-liability corporations the dominant form in the US, but there was nearly simultaneously a huge explosion in experimentation around cooperatives—should we complicate the “telegraphs → big companies” narrative in the same way Spruyt is attempting to complicate it here for the transition from feudal society to nation-states?

The mapping to open source is probably pretty obvious: internet-enabled development (and then internet-enabled distribution) delivered a shock to the existing software business ecosystem; for a time we had a flourishing of institutional/organizational forms. There is certainly a narrative (perhaps correct? perhaps not?) that we are settling into a new equilibrium with a smaller number of forms. What might this history tell us about where we’re going (and what questions we should ask about the narrative of where we’re going?)

#Lakota America: A New History of Indigenous Power, Pekka Hämäläinen

Las Labradas by Zack McCune, CC BY via the Noun Project

US history books rarely show Native American tribes as entities with agency—the world acts on them, but not vice-versa. This book aims to be an antidote to that, showing over a course of roughly 200 years how the Lakota acted, learned, and changed in response to the world around them (including, but definitely not limited to, the US).

I definitely did not read this with the intent of “oh, this will make me think about open source”; I figured it was about as far away as I could get, and yet as I read I couldn’t help but think about parallels.

I think it’s important to be clear: by drawing parallels here I definitely don’t want to suggest that changes in open source are in any way morally/ethically comparable to genocide; if (free?)/open source culture vanished altogether tomorrow that would be a genuine tragedy, but an extremely minor tragedy compared to the very deliberate genocide that occurred occurred in North America.

But it’s hard not to see parallels in the gradual encirclement and disruption of one culture by another very different culture. Some other thoughts:

In one of the many ways in which the book thoughtfully gives the Lakota agency, the author writes of that “[t]hey had welcomed America’s merchandize but not its paternal embrace; they had accepted the Americans as traders and potential allies, but not as their sovereigns. They had, in other words, refused to be ‘discovered’ by [Lewis and Clark]”.
Just like in Spruyt’s Sovereign State, much is made of the simply different notions of “territory” between the nation-state and its competitors; in this case, between the Lakota whose governing style the book describes as “ranging widely but ruling lightly… a malleable, forever transmuting regime”, with little attention to borders or even ultimately to control, and the Americans who “were content with a cartographic proof of.. sovereignty”, needing (and imputing power to) lines on a map.
Technology is a small but significant undercurrent in the book: first guns, then horses, then ultimately the railroad. The first of these two were enthusiastically adopted by the Lakota, and indeed powered much of their imperial expansion in the 1800s. But they could not adopt the railroad in the same way. Nor was writing, though he does say that “[a] key element of Lakotas’ diplomatic prowess was the fact that they had so many literate allies who interpreted and explained [American] documents for them.”
“Contemporary Americans saw the Powder River country as an Indigenous retreat, an insular world intentionally cut off from the rapidly expanding American empire of cities, railroads, settlers, farms, ranches, and capitalism—a perception that has dominated outsider views of the Lakotas ever since. In reality, the Powder River country under the Lakota rule was a safe and dynamic cosmopolitan world of its own where transnational commercial circuits converged, where Indians enjoyed many comforts and advantages of the industrial age, and where new ideas about being in the world were constantly debated. Lakotas knew full well that they lived in a transitional period of innovation, quickening change, and questioning of old conventions. But contrary to the tired old stereotype of obstinate, tradition-bound Indians, they embraced this radical regeneration of their world.”

Additional selected Kindle highlights from my read are here.

#Democracy and Knowledge: Innovation and Learning in Classical Athens, Josiah Ober

Moab Owl by Zack McCune, CC BY via the Noun Project

Ober is a data-driven classicist, focused on Athens and how it fit into the broader milieu of classical Greece. In my distant recollection, this book (or perhaps often just my takeaway from it) argues that:

Since you have literally a thousand Greek city states, you’re running a real experiment you can draw real conclusions from. And Athens, in a real material sense (backed by a variety of interesting data sets) “won” this experiment. (This has some parallels to Spruyt, arguing that in essence there was a flourishing of alternatives and then a winnowing.)
This greatness was in large part predicated on Athen’s ability as a democracy (relative to its neighbors, at any rate) to create and synthesize effective knowledge. In other words, it was better at being a government specifically because it was a democracy, using “local”/small-group/individual knowledge to make itself more effective.
Athens then ultimately failed (after nearly 200 years) in part because neighboring oligarchic governments took its good ideas, and re-implemented them. (This issue is also explored in Ober’s Rise and Fall of Classical Greece.)

I do wish I still had my original notes from reading this a decade or so ago; both it and Rise and Fall are deep and rich books that stirred my political theory bones in a great way.

Setting new expectations for open source maintainers

Wed, 18 Aug 2021 00:00:00 GMT

Originally published at opensource.com.

For a long time, there were two basic tests for releasing open source: “Does it do what I need it to do?” and “Does it compile?”

Sure, it was nice if it did things for others, but more than anything else, it at least needed to be fun for the developer and run at all for others. Then with the rise of package management, things leveled up a bit: “Is it packaged?” Shortly after that, the increasing popularity of test-driven development added another requirement: “Do the tests pass?”

Each of these new requirements made more work for open source maintainers, but (by and large) maintainers didn’t grump too much about them. I think this happened for two reasons: First, the work was often aligned with skills developers needed to learn for their jobs, and second, they were broadly perceived as beneficial for all users of the software, not just corporate developers.

But that is changing—and in ways that may not work out so well for open source and enterprises.

#The new enterprise burdens

Here in 2021, it’s clear that a new set of standards for open source is coalescing. These bring new labor to be done, either by open source developers or as part of a metadata overlay. These new standards include:

Security information and auditing: Security assessments of open source packages have traditionally been carried out by third parties, either through in-house security teams or by the distributed process coordinated through the MITRE Common Vulnerabilities and Exposures database. With new security training like the Linux Foundation’s CII badges and projects like OpenSSF and Google’s SLSA, the new buzzword is “end to end”—meaning maintainers and projects must make themselves security experts and create security controls. While this is almost certainly a good idea for the industry overall, it’s yet more work expectations with no immediate prospect of compensation.
Legal metadata: Traditionally, open source communities like GNU, Debian, and Fedora believed (with good reason) that the default level of mandatory licensing metadata was at the package level, with per-file licensing information often disfavored at best and unrepresentable at worst. SPDX, followed more recently by clearlydefined.io, has decided that license information must be complete, machine-readable, and accurate in every file. This is clearly correct for all users, but the vast majority of the benefit accrues the most deep-pocketed enterprises in practice. In the meantime, if we want accurate global coverage, the vast majority of the burden will fall on maintainers and require intricate legal assessment. (Adding these to the Linux kernel took literally years.)
Procurement information: The newest ask from the industry is to provide Software Bills of Material (SBOM) throughout the software stack—which inevitably includes vast quantities of open source. Again, this is not entirely unreasonable, and indeed open source has long led the way here via the package management techniques that open source language communities pioneered. But the completeness of coverage and depth of information being demanded (including, in some proposals, information about the identity of developers) is a step-change in what is required—primarily to benefit the governments and massive enterprises that can afford to do the detailed, package-by-package analysis of software provenance.

This new work may be quite different from previous waves of new obligations for open source developers—and we should think about why that is and what we might do about it.

#Is this work going to work?

As I suggested in the opening to this piece, the continued maturation of open source has regularly placed new burdens on maintainers. (At Mozilla, we used to call these “table stakes”—a poker term, indicating the things you had to do to even sit at the poker table, or in tech terms, to be considered for enterprise use.) So in some sense, this new wave of obligations is nothing new. But I do want to suggest that in two significant ways, these new mandates are problematic.

First, this work is increasingly highly specialized and so less helpful for individual maintainers to learn. The strongest open source developers have always had diverse skills (not just coding, but also marketing, people management, etc.). That’s been part of the draw of open source—you learn those things along the way, making you a better developer. But when we start adding more and more requirements that specialists (e.g., a legal team or a security team) would cover in a corporate setting, we reduce the additional value to developers of participating in open source.

To put it another way: Developers clearly serve their self-interest by learning basic programming and people skills. It is less clear that they serve their self-interests by becoming experts in issues that, in their day jobs, are likely delegated to experts, like procurement, legal, and security. This works out fine in open source projects big enough to have large, sophisticated teams, but those are rare (even though they gather the lion’s share of press and attention).

Second, these new and increasingly specialized requirements primarily benefit a specific class of open source users—large enterprises. That isn’t necessarily a bad thing—big enterprises are essential in many ways, and indeed, the risks to them deserve to be taken seriously.

But in a world where hundreds of billions of dollars in enterprise value have been created by open source, and where small educational/hobby projects (and even many small companies) don’t really benefit from these new unfunded mandates, developers will likely focus on other things, since few of them got into open source primarily to benefit the Fortune 500.

In other words, many open source developers enjoy building things that benefit themselves and their friends and are even willing to give up nights and weekends for that. If meeting these new requirements mostly benefits faceless corporations, we may need to find other carrots to encourage developers to create and maintain new open source projects.

According to the Tidelift 2021 managed open source survey, more than half of maintainers have quit or considered quitting because they were experiencing burnout.

(Tidelift)

#Why “unfunded mandate?”

In U.S. politics, an “unfunded mandate” occurs when a government requires someone else (usually a lower-level government) to do new work while not funding the new work.

Sometimes, unfunded mandates can be good—many times, they are used to create equity and justice programs, for example, that local governments really should be doing as a matter of course. Arguably, many security initiatives fall into this category—burdensome, yes, but necessary for all of us to use the internet effectively.

But other times, they just create work for small entities that are already overwhelmed juggling the responsibilities of modern governance. If that sounds familiar to open source developers, no surprise—they’re already burnt out, and this is creating more work without creating more time or money.

According to the Tidelift 2021 managed open source survey, more than half of maintainers have quit or considered quitting because they were experiencing burnout.

(Tidelift)

#Aligning incentives—by paying the maintainers

We were pleased to see Google call this issue out in a recent filing on SBOMs with the National Telecommunications and Information Administration (NTIA).

“Unfortunately, much of the burden of maintaining our digital infrastructure falls on the backs of unpaid, volunteer contributors. The NTIA should carefully evaluate ways to fund and assist these communities as they work with industry to comply with new regulations.”

Tidelift’s filling to the same NTIA call for comments made similar points about money, scale, and reliability. In response, in its own summary, the NTIA acknowledged that “funding sources” are a challenge and also said:

“Further research is necessary to understand the optimal … incentives for sharing, protecting, and using SBOM data.”

Given the dynamic of increasing professionalization—or to put it more bluntly, increasing work—that I’ve described above, it is refreshing to see an acknowledgment from significant industry players that developer incentives should be considered as we move into the next era of open source. We, as an industry, must figure out how to address this together, or we’ll both fail to reach our goals and burn out developers—the worst of all worlds.

Governing Values-Centered Tech Non-Profits; or, The Route Not Taken by FSF

Wed, 07 Apr 2021 00:00:00 GMT

A few weeks ago, I interviewed my friend Katherine Maher on leading a non-profit under some of the biggest challenges an org can face: accusations of assault by leadership, and a growing gap between mission and reality on the ground.

We did the interview at the Free Software Foundation’s Libre Planet conference. We chose that forum because I was hopeful that the FSF’s staff, board, and membership might want to learn about how other orgs had risen to challenges like those faced by FSF after Richard Stallman’s departure in 2019. I, like many others in this space, have a soft spot for the FSF and want it to succeed. And the fact my talk was accepted gave me further hope.

Unfortunately, the next day it was announced at the same conference that Stallman would rejoin the FSF board. This made clear that the existing board tolerated Stallman’s terrible behavior towards others, and endorsed his failed leadership—a classic case of non-profit founder syndrome.

While the board’s action made the talk less timely, much of the talk is still, hopefully, relevant to any value-centered tech non-profit that is grappling with executive misbehavior and/or simply keeping up with a changing tech world. As a result, I’ve decided to present here some excerpts from our interview. They have been lightly edited, emphasized, and contextualized. The full transcript is here.

#Sunlight Foundation: harassment, culture, and leadership

In the first part of our conversation, we spoke about Katherine’s tenure on the board of the Sunlight Foundation. Shortly after she joined, Huffington Post reported on bullying, harassment, and rape accusations against a key member of Sunlight’s leadership team.

[I had] worked for a long time with the Sunlight Foundation and very much valued what they’d given to the transparency and open data open government world. I … ended up on a board that was meant to help the organization reinvent what its future would be.

I think I was on the board for probably no more than three months, when an article landed in the Huffington Post that went back 10 years looking at … a culture of exclusion and harassment, but also … credible [accusations] of sexual assault.

And so as a board … we realized very quickly that there was no possible path forward without really looking at our past, where we had come from, what that had done in terms of the culture of the institution, but also the culture of the broader open government space.

Katherine

#Practical impacts of harassment

Sunlight’s board saw immediately that an org cannot effectively grapple with a global, ethical technological future if the org’s leadership cannot grapple with its own culture of harassment. Some of the pragmatic reasons for this included:

The [Huffington Post] article detailed a culture of heavy drinking and harassment, intimidation.

What does that mean for an organization that is attempting to do work in sort of a progressive space of open government and transparency? How do you square those values from an institutional mission standpoint? That’s one [pragmatic] question.

Another question is, as an organization that’s trying to hire, what does this mean for your employer brand? How can you even be an organization that’s competitive [for hiring] if you’ve got this culture out there on the books?

And then the third pragmatic question is … [w]hat does this mean for like our funding, our funders, and the relationships that we have with other partner institutions who may want to use the tools?

Katherine

FSF suffers from similar pragmatic problems—problems that absolutely can’t be separated from the founder’s inability to treat all people as full human beings worthy of his respect. (Both of the tweets below lead to detailed threads from former FSF employees.)

Tweet by @georgialyle

Since the announcement of Stallman’s return, all top leadership of the organization have resigned, and former employees have detailed how the FSF staff has (for over a decade) had to deal with Richard’s unpleasant behavior, leading to morale problems, turnover, and even unionization explicitly to deal with RMS.

Tweet by @paulnivin

And as for funding, compare the 2018 sponsor list with the current, much shorter sponsor list.

So it seems undeniable: building a horrible culture has pragmatic impacts on an org’s ability to espouse its values.

#Values and harassment

Of course, a values-centered organization should be willing to anger sponsors if it is important for their values. But at Sunlight, it was also clear that dealing with the culture of harassment was relevant to their values, and the new board had to ask hard questions about that:

The values questions, which … are just as important, were… what does this mean to be an organization that focuses on transparency in an environment in which we’ve not been transparent about our past?

What does it mean to be an institution that [has] progressive values in the sense of inclusion, a recognition that participation is critically important? … Is everyone able to participate? How can we square that with the institution that are meant to be?

And what do we do to think about justice and redress for (primarily the women) who are subjected to this culture[?]

Katherine

Unlike Sunlight, FSF is not about transparency, per se, but RMS at his best has always been very strong about how freedom had to be for everyone. FSF is an inherently political project! One can’t advocate for the rights of everyone if, simultaneously, one treats staff disposably and women as objects to be licked without their consent, and half the population (women) responds by actively avoiding the leadership of the “movement”.

So, in this situation, what is a board to do? In Sunlight’s case:

[Myself and fellow board member Zoe Reiter] decided that this was a no brainer, we had to do an external investigation.

The challenges of doing this… were pretty tough. [W]e reached out to everyone who’d been involved with the organization we also put not just as employees but also trying to find people who’ve been involved in transparency camps and other sorts of initiatives that Sunlight had had run.

We put out calls for participation on our blog; we hired a third party legal firm to do investigation and interviews with people who had been affected.

We were very open in the way that we thought about who should be included in that—not just employees, but anyone who had something that they wanted to raise. That produced a report that we then published to the general public, really trying to account for some of the things that have been found.

Katherine

The report Katherine mentions is available in two parts (results, recommendations) and is quite short (nine pages total).

While most of the report is quite specific to the Sunlight Foundation’s specific situation, the FSF board should particularly have read page 3 of the recommendations: “Instituting Board Governance Best Practices”. Among other recommendations relevant to many tech non-profits (not just FSF!), the report says Sunlight should “institute term limits” and “commit to a concerted effort to recruit new members to grow the Board and its capacity”.

#Who can investigate a culture? When?

Katherine noted that self-scrutiny is not just something for large orgs:

[W]hen we published this report, part of what we were hoping for was that … we wanted other organizations to be able to approach this in similar challenges with a little bit of a blueprint for how one might do it. Particularly small orgs.

There were four of us on the board. Sunlight is a small organization—15 people. The idea that an even smaller organizations don’t have the resources to do it was something that we wanted to stand against and say, actually, this is something that every and all organizations should be able to take on regardless of the resources available to them.

Katherine

It’s also important to note that the need for critical self scrutiny is not something that “expires” if not undertaken immediately—communities are larger, and longer-lived, than the relevant staff or boards, so even if the moment seems to be in the relatively distant past, an investigation can still be valuable for rebuilding organizational trust and effectiveness.

[D]espite the fact that this was 10 years ago, and none of us were on the board at this particular time, there is an accounting that we owe to the people who are part of this community, to the people who are our stakeholders in this work, to the people who use our tools, to the people who advocated, who donated, who went on to have careers who were shaped by this experience.

And I don’t just mean, folks who were in the space still—I mean, folks who were driven out of the space because of the experiences they had. There was an accountability that we owed. And I think it is important that we grappled with that, even if it was sort of an imperfect outcome.

Katherine

#Winding down Sunlight

As part of the conclusion of the report on culture and harassment, it was recommended that the Sunlight board “chart a new course forward” by developing a “comprehensive strategic plan”. As part of that effort, the board eventually decided to shut the organization down—not because of harassment, but because in many ways the organization had been so successful that it had outlived its purpose.

In Katherine’s words:

[T]he lesson isn’t that we shut down because there was a sexual assault allegation, and we investigated it. Absolutely not!

The lesson is that we shut down because as we went through this process of interrogating where we were, as an organization, and the culture that was part of the organization, there was a question of what would be required for us to shift the organization into a more inclusive space? And the answer is a lot of that work had already been done by the staff that were there…

But the other piece of it was, does it work? Does the world need a Sunlight right now? And the answer, I think, in in large part was not to do the same things that Sunlight had been doing. …

The organization spawned an entire community of practitioners that have gone on to do really great work in other spaces. And we felt as though that sort of national-level governmental transparency through tech wasn’t necessarily needed in the same way as it had been 15 years prior. And that’s okay, that’s a good thing.

Katherine

We were careful to say at Libre Planet that I don’t think FSF needs to shut down because of RMS’s terrible behavior. But the reaction of many, many people to “RMS is back on the FSF board” is “who cares, FSF has been irrelevant for decades”.

Tweet by @azumanga

That should be of great concern to the board. As I sometimes put it—free licenses have taken over the world, and despite that the overwhelming consensus is that open won and (as RMS himself would say) free lost. This undeniable fact reflects very badly on the organization whose nominal job it is to promote freedom. So it’s absolutely the case that shutting down FSF, and finding homes for its most important projects in organizations that do not suffer from deep governance issues, should be an option the current board and membership consider.

Which brings us to the second, more optimistic topic: how did Wikimedia react to a changing world? It wasn’t by shutting down! Instead, it was by building on what was already successful to make sure they were meeting their values—an option that is also still very much available to FSF.

#Wikimedia: rethinking mission in a changing world

Wikimedia’s vision is simple: “A world in which every single human can freely share in the sum of all knowledge.” And yet, in Katherine’s telling, it was obvious that there was still a gap between the vision, the state of the world, and how the movement was executing.

We turned 15 in 2016 … and I was struck by the fact that when I joined the Wikimedia Foundation, in 2014, we had been building from a point of our founding, but we were not building toward something.

So we were building away from a established sort of identity … a free encyclopedia that anyone can edit; a grounding in what it means to be a part of open culture and free and libre software culture; an understanding that … But I didn’t know where we were going.

We had gotten really good at building an encyclopedia—imperfect! there’s much more to do!—but we knew that we were building an encyclopedia, and yet … to what end?

Because “a free world in which every single human being can share in the sum of all knowledge”—there’s a lot more than an encyclopedia there. And there’s all sorts of questions:

About what does “share” mean?

And what does the distribution of knowledge mean?

And what does “all knowledge” mean?

And who are all these people—“every single human being”? Because we’ve got like a billion and a half devices visiting our sites every month. But even if we’re generous, and say, that’s a billion people, that is not the entirety of the world’s population.

Katherine

As we discussed during parts of the talk not excerpted here, usage by a billion people is not failure! And yet, it is not “every single human being”, and so WMF’s leadership decided to think strategically about that gap.

FSF’s leadership could be doing something similar—celebrating that GPL is one of the most widely-used legal documents in human history, while grappling with the reality that the preamble to the GPL is widely unheeded; celebrating that essentially every human with an internet connection interacts with GPL-licensed software (Linux) every day, while wrestling deeply with the fact that they’re not free in the way the organization hopes.

Some of the blame for that does in fact lie with capitalism and particular capitalists, but the leadership of the FSF must also reflect on their role in those failures if the organization is to effectively advance their mission in the 2020s and beyond.

#Self-awareness for a successful, but incomplete, movement

With these big questions in mind, WMF embarked on a large project to create a roadmap, called the 2030 Strategy. (We talked extensively about “why 2030”, which I thought was interesting, but won’t quote here.)

WMF could have talked only to existing Wikimedians about this, but instead (consistent with their values) went more broadly, working along four different tracks. Katherine talked about the tracks in this part of our conversation:

We ran one that was a research track that was looking at where babies are born—demographics I mentioned earlier [e.g., expected massive population growth in Africa—omitted from this blog post but talked about in the full transcript.]

[Another] was who are our most experienced contributors, and what did they have to say about our projects? What do they know? What’s the historic understanding of our intention, our values, the core of who we are, what is it that motivates people to join this project, what makes our culture essential and important in the world?

Then, who are the people who are our external stakeholders, who maybe are not contributors in the sense of contributors to the code or contributors to the projects of content, but are the folks in the broader open tech world? Who are folks in the broad open culture world? Who are people who are in the education space? You know, stakeholders like that? “What’s the future of free knowledge” is what we basically asked them.

And then we went to folks that we had never met before. And we said, “Why don’t you use Wikipedia? What do you think of it? Why would it be valuable to you? Oh, you’ve never even heard of it. That’s so interesting. Tell us more about what you think of when you think of knowledge.” And we spent a lot of time thinking about what these… new readers need out of a project like Wikipedia. If you have no sort of structural construct for an encyclopedia, maybe there’s something entirely different that you need out of a project for free knowledge that has nothing to do with a reference—an archaic reference—to bound books on a bookshelf.

Katherine

This approach, which focused not just on the existing community but on data, partners, and non-participants, has been extensively documented at 2030.wikimedia.org, and can serve as a model for any organization seeking to re-orient itself during a period of change—even if you don’t have the same resources as Wikimedia does.

Unfortunately, this is almost exactly the opposite of the approach FSF has taken. FSF has become almost infamously insulated from the broader tech community, in large part because of RMS’s terrible behavior towards others. (The list of conference organizers who regret allowing him to attend their events is very long.) Nevertheless, given its important role in the overall movement’s history, I suspect that good faith efforts to do this sort of multi-faceted outreach and research could work—if done after RMS is genuinely at arms-length.

#Updating values, while staying true to the original mission

The Wikimedia strategy process led to a vision that extended and updated, rather than radically changed, Wikimedia’s strategic direction:

By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge, and anyone who shares our vision will be able to join us.

Wikipedia

In particular, the focus was around two pillars, which were explicitly additive to the traditional “encyclopedic” activities:

Knowledge equity, which is really around thinking about who’s been excluded and how we bring them in, and what are the structural barriers that enable that exclusion or created that exclusion, rather than just saying “we’re open and everyone can join us”. And how do we break down those barriers?

And knowledge as a service, which is without thinking about, yes, the technical components of what a service oriented architecture is, but how do we make knowledge useful beyond just being a website?

Katherine

I specifically asked Katherine about how Wikimedia was adding to the original vision and mission because I think it’s important to understand that a healthy community can build on its past successes without obliterating or ignoring what has come before. Many in the GNU and FSF communities seem to worry that moving past RMS somehow means abandoning software freedom, which should not be the case. If anything, this should be an opportunity to re-commit to software freedom—in a way that is relevant and actionable given the state of the software industry in 2021.

A healthy community should be able to handle that discussion! And if the GNU and FSF communities cannot, it’s important for the FSF board to investigate why that is the case.

#Checklists for values-centered tech boards

Finally, at two points in the conversation, we went into what questions an organization might ask itself that I think are deeply pertinent for not just the FSF but virtually any non-profit, tech or otherwise. I loved this part of the discussion because one could almost split it out into a checklist that any board member could use.

The first set of questions came in response to a question I asked about Wikidata, which did not exist 10 years ago but is now central to the strategic vision of knowledge infrastructure. I asked if Wikidata had been almost been “forced on” the movement by changes in the outside world, to which Katherine said:

Wikipedia … is a constant work in progress. And so our mission should be a constant work in progress too.

How do we align against a north star of our values—of what change we’re trying to effect in the world—while adapting our tactics, our structures, our governance, to the changing realities of the world?

And also continuously auditing ourselves to say, when we started, who, you know, was this serving a certain cohort? Does the model of serving that cohort still help us advance our vision today?

Do we need to structurally change ourselves in order to think about what comes next for our future? That’s an incredibly important thing, and also saying, maybe that thing that we started out doing, maybe there’s innovation out there in the world, maybe there are new opportunities that we can embrace, that will enable us to expand the impact that we have on the world, while also being able to stay true to our mission and ourselves.

Katherine

And to close the conversation, I asked how one aligns the pragmatic and organizational values as a non-profit. Katherine responded that governance was central, with again a great set of questions all board members should ask themselves:

[Y]ou have to ask yourself, like, where does power sit on your board? Do you have a regenerative board that turns over so that you don’t have the same people there for decades?

Do you ensure that funders don’t have outsize weight on your board? I really dislike the practice of having funders on the board, I think it can be incredibly harmful, because it tends to perpetuate funder incentives, rather than, you know, mission incentives.

Do you think thoughtfully about the balance of power within those boards? And are there … clear bylaws and practices that enable healthy transitions, both in terms of sustaining institutional knowledge—so you want people who are around for a certain period of time, balanced against fresh perspective.

[W]hat are the structural safeguards you put in place to ensure that your board is both representative of your core community, but also the communities you seek to serve?

And then how do you interrogate on I think, a three year cycle? … So every three years we … are meant to go through a process of saying “what have we done in the past three, does this align?” and then on an annual basis, saying “how did we do against that three year plan?” So if I know in 15 years, we’re meant to be the essential infrastructure free knowledge, well what do we need to clean up in our house today to make sure we can actually get there?

And some of that stuff can be really basic. Like, do you have a functioning HR system? Do you have employee handbooks that protect your people? … Do you have a way of auditing your performance with your core audience or core stakeholders so that you know that the work of your institution is actually serving the mission?

And when you do that on an annual basis, you’re checking in with yourself on a three year basis, you’re saying this is like the next set of priorities. And it’s always in relation to that that higher vision. So I think every nonprofit can do that. Every size. Every scale.

Katherine

#The hard path ahead

The values that the FSF espouses are important and world-changing. And with the success of the GPL in the late 1990s, the FSF had a window of opportunity to become an ACLU of the internet, defending human rights in all their forms. Instead, under Stallman’s leadership, the organization has become estranged and isolated from the rest of the (flourishing!) digital liberties movement, and even from the rest of the software movement it was critical in creating.

This is not the way it had to be, nor the way it must be in the future. I hope our talk, and the resources I link to here, can help FSF and other value-centered tech non-profits grow and succeed in a world that badly needs them.

4 questions for the OSI board of directors candidates

Thu, 11 Mar 2021 00:00:00 GMT

Originally published at opensource.com.

The Open Source Initiative (OSI) is the community-driven nonprofit organization that maintains and evaluates compliance with the Open Source Definition. Last year, I wrote a piece for Opensource.com with a series of questions for candidates in the 2020 election for the OSI board of directors. Several candidates answered on the OSI wiki, which I appreciated and used to help guide my vote as a member.

A year later, a new election is upon us, and it seems like a great time to check in on my questions and see what they tell us about OSI’s year.

#Big changes on big questions

OSI has managed to have a steady and successful year, despite the challenges of 2020–2021. In particular, OSI has answered a couple of my questions through action—not just talking the talk but also walking the walk.

My first question for last year’s candidates was: If OSI could only do one thing, what would it be? Very recently, the organization answered that question by publishing an updated mission statement. A new mission statement might seem like a small thing, but it is big in a couple of ways. First, as I said last year, there are a lot of different answers to the question “what is OSI for?”—and those different answers have been a source of tension both within and outside the organization. The new mission statement doesn’t narrow things down to “just one thing,” but it does center stewardship of the Open Source Definition as “the foundation of our ecosystem.” That’s a welcome focus.

In late 2020, the organization also announced it intended to hire an executive director for the first time, with long-term plans to have two to three other employees. This answers my second question last year (Should OSI move towards a board that…does less on a day-to-day basis?) with a resounding “yes.” While I did (and still do) see the potential case for a small, board-driven organization, overall, I think this is very much the right move for OSI. It will help the board stay high-level while making key initiatives more effective.

#Still working in a changing world

Two of the questions I asked last year are still very pertinent, and I’d ask them of any new candidates this year.

What should OSI do about the tens of millions of people who regularly collaborate to build software online (often calling that activity, colloquially, open source) but have literally no idea what OSI is or what it does?

This is still pertinent, as the growth of open source projects increased during the pandemic. OSI has started to think harder about this, in part through its first online conference this year, the State of the Source. But with open source continuing to sprawl, every board member should have a coherent theory of what OSI should do about this.
If an Ethical Software Initiative sprung up tomorrow, what should OSI’s relationship to it be?

Welp, it did spring up, in January 2021. OSI, as best as I can tell, hasn’t publicly acknowledged the group’s existence. That seems to me to be…less than ideal. Unpleasant personal politics between the Free Software Foundation (FSF) and OSI made it hard for those organizations to work together for years, damaging both of their causes. OSI should learn from this. If nothing else, a healthy arms-length relationship between OSI and ethical source organization(s) would tend to foster constructive disagreement—something sorely needed. How will new (or returning) board members handle this in the next term?

#The new challenges

In an organization that has recommitted to the centrality of the Open Source Definition, questions of how to interpret that definition will continue to be paramount. This is particularly true for the board, whose members generally don’t sign up to read licenses but nevertheless are the final arbiters of licensing decisions.

This would be true even if nothing else were going on in the world, but instead, we seem to be dealing with a resurgence of companies running a “rights ratchet,” where ever-more-restrictive open or quasi-open licenses are foisted on existing user bases in the name of openness and (arguably) exploiting vagueness in the Open Source Definition.

So, the two questions I’d add for the current candidates are:

When a license decision involves a topic on which the Open Source Definition is vague or otherwise unhelpful, what should the board do?

For example, the OSD does not specify that it must be easy, reasonable, or even possible to comply with innovative copyleft restrictions. What should happen in this situation? Do we give the benefit of the doubt to a license submitter? Does it depend on who the submitter is? Should we update an FAQ or otherwise adjust the OSD? Defer to the licensing committee or license review? Or do nothing at all? This is a fraught question, so I don’t envy the board. But it is nevertheless part of the board’s core role. (This is in some ways a more focused version of a question I asked last year: “If OSI has to choose between being an agent of change and a stabilizing force, which should it prefer?”)
What role should the new staff play in license evaluation (or the OSD more generally)?

There are a variety of ways that staff could support the license-review process (like adding tooling or summarizing discussions). There are probably also quite a few reasons why staff should stay out of the process altogether, such as a desire to center community decision making. Given the plan to add staff and the renewed centrality of the OSD, what do the board candidates think the relationship between the two should be? Hands off? Deeply involved? Focused elsewhere?

#Good people, hard jobs

Finally, as with all nonprofit board roles, the question of “you have 24 hours in the day and are talented enough to do many different things; why do you want to give some of those hours to OSI?” is every bit as pertinent as it was last year. Thankfully, the board has stabilized with no resignations this (very tough!) year. Nevertheless, I expect the candidates will face hard choices about their time in 2021–2022, and it is fair to ask how they plan to prioritize.

I look forward to candidates’ responses. The OSI remains important for all of us, and the quality of candidates always reflects that—surely one of the better (if small) signs of the continued success and health of open source overall.

6 questions for the OSI board of directors candidates

Sun, 01 Mar 2020 00:00:00 GMT

Originally published at opensource.com.

In a twitter exchange about ethical licenses, my friend Stephen O’Grady said something that I thought was sharp:

the energy cost is only part of the issue. maybe it’s significant over the long term, maybe not.

the collateral damage of the process to individuals and institutions with no other goal than protecting open source, however, is material IMO.

— steve o’grady (@sogrady) February 19, 2020

It’s also very timely, given the upcoming Open Source Initiative (OSI) board of directors elections. Unsurprisingly, with all the various activity in open source licensing in the past 12-18 months, the OSI board has never seen more candidates, and with a greater range of interests and goals. They could take the organization in a variety of different directions, so figuring out how to vote is not going to be easy for anyone.

Inspired in large part by a variety of conversations at FOSDEM, as well as my experience as a one-term OSI board member and longtime OSI volunteer, I’m going to lay out the questions I’ve asked OSI board candidates, and the reasoning behind those questions.

The core challenge: The organization is facing a rapidly changing environment with a variety of tough constraints, including being very central to how the industry operates. To be successful, new board members will have to both grapple with current realities and offer a vision for a rapidly changing future—one or the other likely won’t be enough.

A definitional note: There’s a lot of conflict right now over what “open source” is.

Lots of folks, for perfectly good reasons, insist on an OSI- and license-centric definition of the term: “Open source software is made by many people and distributed under an (Open Source Definition)-compliant license.” The broader culture (say, Merriam-Webster or Wikipedia, or many developers in the “GitHub generation”) tends to define open source more broadly, usually with a primary focus on collaboration and no reference to the OSI’s Open Source Definition. To avoid confusion in this essay, I’ll try to use “open source” when I mean OSI’s precise definition, and “open collaboration” or “open software collaboration” when I mean the less precise but much broader definition grounded in collaborative, online development of software (which usually implies, but does not specify, having few or no barriers to modification, use, and redistribution).

#The current state of OSI

When looking at the future of OSI, two main things are critical, but perhaps not obvious, to know about the present state of the organization.

#What is OSI for?

At FOSDEM, there were a lot of interesting conversations about what OSI could do. But once you started asking “why,” many of the conversations kept getting hung up on the core question of what OSI is for. In short, there are a lot of different answers to this question.

For some people, OSI is for “guaranteeing software freedom,” however, that is defined; for others, OSI is for creating a predictable environment for developers and their employers. For some, OSI is primarily about defending the Open Source Definition; for others, that goal is just one of many things the organization should do. And there are many other purposes; these are only a few! There are tensions among these, but also many ways in which they are compatible and overlapping, which is how the org has gotten as far as it has without always having clearly stated goals.

There’s also the interesting tension between what OSI thinks it should do, and what others think it should do. You can think of the OSI as analogous to the EU: it promoted stability, reduced friction, built a huge market, and stopped open warfare. OSI’s biggest beneficiaries really like that stability, but many of the people who want to get actively involved in OSI’s day-to-day work really do mean actively involved, which implies some changes that might rock the boat. After all, few people want to take on a largely thankless goal like maintaining the status quo.

And finally, there’s the challenge of the ever-increasing gap between the tens of millions who use the term “open source” interchangeably with “open software collaboration” and the much smaller number who, when they say open source, explicitly know about and reference the OSI Open Source Definition.

#How does OSI do what it does?

OSI is currently a fairly shoestring organization, despite having been a key stabilizer for the software commons that is the basis of literally trillions of dollars of market value. To continue the EU analogy, it’s like the organization brought continental peace and prosperity, but then no member states paid taxes.

Because of this, OSI has only one employee, and most of the org’s day-to-day work is still done by volunteer board members. As any non-profit expert will tell you, this is not a happy combination. In this situation, board members usually find it challenging to create a long-term vision because they’re too focused on nuts-and-bolts, but also find it hard to execute on any long-term plans because of board member turnover.

None of that is the fault of the people involved—they’re all making the best of a difficult situation. But in this situation, even a non-profit executing on a very clear vision and strategy would have a hard time.

#So what should we know about candidates?

On the OSI wiki, I have asked candidates a few pointed questions, listed below. I should stress that I think there are many ways to answer these questions in good faith, and I genuinely don’t mean any of them as “gotchas” with only one right answer. I’ve tried to write them, instead, to illuminate, not just for candidates but for voters as well.

If OSI could do only one thing, what would it be? Realistically, OSI and candidates only have the bandwidth for a handful of things; understanding the candidate’s absolute #1 priority tells a lot about where that person will focus their energy. A legitimate answer might be “building organizational capacity to do more than one thing!” But if so, it means focusing on that in the short-term to the exclusion of many other things.
Should OSI move towards a board that advises more and does less on a day-to-day basis? If so, what will you do to help bring about that change? If not, why not? I tend to think that OSI needs more resources, and should have a plan to acquire and deploy those resources. However, there are also legitimate good-faith arguments for an organization that is very cautious, limited, and driven by day-to-day board involvement, so I’m open to being persuaded by a thoughtful candidate on that point.
If OSI has to choose between being an agent of change and a stabilizing force, which should it prefer? Much of the tension between license innovation of all stripes (not just ethical source, but also data/SaaS licensing) and OSI is a philosophical question about change and stability. I’d like to see candidates explain where they’ll end up when push comes to shove (as it definitely will for candidates in this turbulent period).
What should OSI do about the tens of millions of people who regularly collaborate to build software online (often calling that activity, colloquially, open source) but have literally no idea what OSI is or what it does? A strong candidate should be able to grapple with the reality that most open collaborative developers don’t know or don’t care about OSI. That said, there is a wide variety of potential answers—for example, one could say “our audience is the key decision-makers in the software industry, not the broader public, so OSI should speak to those decision-makers by doing…,” or “we absolutely need to speak to that broader public again, so we should…,” or many things in between (like the current affiliates program, which is limited but definitely still one of the best things the organization has done in the past decade).
You have 24 hours in the day and are talented enough to do many different things. Why do you want to give some of those hours to OSI? Frankly, while perusing biographies, at least some of the candidates seem like they would be both happier and most impactful focusing on their main project (and I’ve told at least one of them that directly). We should hear why they think this is a good use of their time. A weak answer may suggest their interest will fade, a real problem for a board that has had a good number of resignations over the past several years. Or they may be a single-issue board member who pitches in less on other topics—not ideal for an organization that still relies on board members to do a lot of the day-to-day.
If an Ethical Software Initiative sprung up tomorrow, what should OSI’s relationship to it be? In a world with zillions of open and open-adjacent groups, how OSI manages relationships with them (Low priority? High priority? Hostile? Collaborative?) is likely to be a critical indicator of the OSI’s overall success. Given the particular timeliness of the ethical license question, and how fraught it is, I’m asking about this through the ethical lens, but one could easily reframe it to focus on other organizations like the Free Software Foundation or Linux Foundation.

#Where do I stand?

As I’ve mentioned in blog posts and some recent talks, I think the enormous success of open collaboration is the most critical challenge and opportunity right now. When we have 100 million open collaborative developers, which we likely will within the next couple of years, we’ll need very different social and legal tools than when we had 10,000 developers, all of whom were one or two degrees of separation from someone who was in the room when the phrase open source was coined.

This growth means a vast diversity of problems to be solved, and a vast diversity of experiences and motivations brought to bear on those problems. It also means that, whether or not the OSI likes it, there is going to be lots of experimentation within open software collaboration, with varying relationships to formal OSI-defined open source. These experiments will take a lot of different forms: among others, pushing the bounds of existing licenses, using non-licensing forms of coordination like codes of conduct, and merely relying on norms baked into collaboration tools like GitHub. Some of this experimentation will be serious and thoughtful, some of it less so. How the OSI responds and leads will be critical to defining the organization’s success in the next decade.

At the same time as it faces this challenge, the OSI has played an important role over the last 15 years in creating a stable, broad commons of programming resources—the biggest pool of shared, no-cost human infrastructure that has ever existed. One can quibble around the edges of this, and I certainly have, but I think overall, it isn’t too much to say that the existence and relative predictability/stability of this commons has been a significant net plus for all of humanity. And, as I think Stephen was hinting at in the tweet I opened this piece with, it’s entirely possible that a distracted or unfocused OSI could accidentally (or intentionally) weaken this commons.

If you take these two dynamics—growth and stability—as a given, as I do, then I see the OSI’s primary challenge as being how to respect, safeguard, and grow the existing open source commons while also reacting appropriately and constructively to these new open collaboration innovations. There is also an important secondary challenge: How will it do these things within the very real organizational constraints it currently faces?

As a concrete example: Lots of folks in the open source space have expressed concerns about the enforceability of ‘ethical’ licenses. OSI can choose from many possible responses to this, based on a combination of the organization’s goals, its role within the industry, and the resources it has to implement those responses. I want to vote for candidates who indicate that they’ve thought all these factors through, not just one aspect of it.

#Where to go next

As I’ve said, I have posted these questions to all the board candidates, and will urge affiliates to think about them as well. Hopefully, it helps voters make choices in what certainly proves to be a very wide-ranging election.

Surviving Crisis on Twitter

Tue, 25 Feb 2020 00:00:00 GMT

[This was originally published right before the COVID pandemic hit, with the expectation that it was about the upcoming 2020 campaign and presidential election. In 2022 I revised and renamed it, since much of the advice was still very relevant.]

I’m a political junkie, perhaps in some ways more now than ever. And yet, in late 2019-early 2020 I was posting very little about the 2020 election on Twitter. An old friend with similar political compulsions asked how I was doing it. The answer was ironically too long for Twitter. It also proved deeply relevant after COVID and many other ongoing crises hit. So how does one benefit from — perhaps even enjoy? — Twitter in our extended ongoing crisis? Read on!

#Reduce Twitter altogether

Step 0: use Freedom or a similar blocking tool to keep Twitter out of your life when you’re trying to get other stuff done. I generally block Twitter during the entire working day on my work computer, and during the early morning (6-8am), morning (9-12) and afternoon (1-5) on my tablet and phone.

This is occasionally irritating since I do sometimes need Twitter for work but overall is worth it.

(Perhaps worth noting here that after the 2016 election I didn’t just reduce Facebook, I stopped logging in altogether unless I absolutely needed to for some reason. Absolutely zero regrets about that, though from time to time I miss certain people I only connected with there, and am curious to what extent I could effectively replicate the strategy described in this post there. Last I checked you could not firmly block specific words, which I think is critical to healthy engagement with social media—see next section.)

#Reduced my Twitter political inputs

Partial list of words I block on twitter, including “president” “omicron” and “Pelosi”.

Step 1: simply reduce the amount of political stuff that I see when I go to Twitter. I see all kinds of other wonderful stuff instead! What I do in this direction:

Turn off the algorithmic feed. You want control over what you see; no one else (and certainly not an algorithm designed to suck your eyeballs in) should drive that.
Unsubscribe from all ‘news’ feeds on twitter—@nytimes, @cnn, etc. I use other mechanisms (see below) to get them daily at most. More generally, I aggressively turn off all news notifications on my phone. If the missiles launch and I need to hug my loved ones, someone will text me.
Unsubscribe from people I don’t know personally. For me, that’s basically all celebrites (except Lin-Manuel) but if that sounds too aggressive, you can Marie Kondo your follows with the help of the Tokimeki Unfollow tool. Two (small) exceptions for me:
- Have they taught me something I didn’t know, because they’re giving me diverse perspectives not in my personal network? That can be troubling/non-joyful, but still valuable.
- Have they given me opportunities for real-world action that you can’t get in some other way? For me, this is primarily local organizations — several San Francisco bike, transit, and YIMBY activists. (I find this to almost never be the case from national media, because the opportunities for practical action are too limited.)
Turn off all pure retweets with the Turn Off Retweets tool. Yes, even from your friends. In my experience, pure retweets are highly likely to be more angry/emotional, and less informative; if people have something interesting to add they’ll quote-tweet. Yes, there was some FOMO here. I got over it very quickly. If it is important, I see it eventually.
Mute (aka filter) political words aggressively. Here are Twitter’s instructions. A sampling of my word list is the highlighted image for this post. Note that I mute the name of politicans I often agree with, not just assholes! You do not need a constant stream of affirmation news either. Turn it off. The world will go on without it.

#(optional) Replace with better news sources

I still feel the need for a lot of politics news. A few tips on managing this:

I subscribe to news via non-Twitter mechanisms, primarily Feedbin, a feed reader that allows me to follow both old-school RSS feeds and new-school email newsletters.
As with Twitter, block whatever your chosen mechanism is most of the day with Freedom. You don’t need to be informed all day long. (If I really had the right willpower, I’d try to keep my non-job-relevant news consumption to weekly, but I don’t (yet) have that willpower.)
As much as possible, make this local news. Important national/global news will trickle in as you need it. In my case, key local news sources are Mission Local and the Chronicle.

#(dangerous) Use Twitter lists

I call this “dangerous” because in my experience it becomes very tempting to check Twitter lists in the same way you used to check your main feed, defeating the whole point. But you can move political follows to a list and check in on them occasionally. If you must do this, a few thoughts:

Make the list as diverse as possible. Ideally don’t follow anyone who your “main” follows are already following or RTing. For me personally, about a decade ago I started unfollowing most high-profile journalists and, in particular, made a deliberate effort to follow then-up-and-coming Black journalists, many of whom have now become high-profile themselves. Hearing them in their more personal voices on Twitter, as opposed to at article-length, has made me a better, more empathetic American. (Sadly, many of the best, like Vann Newkirk, have left Twitter, but I can hardly blame them!)
Follow at least some folks who you don’t agree with ideologically, assuming they’re making fairly good-faith efforts to inform and engage. There’s a lot of those on the right post-Trump.
Again, even if you must do this, don’t follow @nytimes and @cnn. These accounts are not designed to inform you, they’re designed to hook you. And I say this as a paying NYT and Washington Post subscriber!

#(hard, but helpful) come to terms with the world as it is, and act in that framework

At some point in the past few years, I accepted that I’m going to have a baseline level of anger about the state of the world, and that I have to focus on what I can change and let go of what I can’t. (Twitter anger is the latter.) So what can I change? Where is my anger productive?

I’ve found that doing things offline—for me, mostly giving money—really helps. In particular, giving to causes that seek systemic (usually, that means political/government) change like 350.org and local activist groups, and giving a lot, and regularly. This, frankly, makes it a lot easier for me to ignore anger online — each new tweet is not likely to make me be more angry, or give more, because I’m already basically giving what I can. Being confident about that really reduced my FOMO when I started filtering aggressively.

I hear from non-parents/non-startup-founders that physical-world activism (door-knocking, phone banking, local gov meeting-attending, etc.) can be great in this way too but sadly I can’t confirm :(

(I also want to acknowledge that, in the current state of the world, ‘letting go’ gets harder the less privilege you have. I have no great response to that, except to say that I empathize and am trying to fight for you where and how I can.)

#Improving my outputs

Having done all that, here’s how I try to improve the Twitter environment for others:

When in doubt, send it to a group of friends instead. You’ll get the same dopamine hit and no one will call you on it 5-10 years from now.
If I must RT or otherwise share politics news, I only quote tweet because that forces me to ask “what am I adding to this? why should I say it? What can I add that others can’t?” If I can’t add something, if I’m just amplifying anger, I try to shut up instead.
If I must be angry, I’ve tried to follow a rule that I only express that offline if I am also telling other people who are angry how to constructively address the problem. I don’t just say “I’m so mad about global warming”, say “I’m mad about global warming, here’s what I’m doing to help fix it, you can too”. If I don’t have a ‘here’s what I’m doing’ to add to it … I go back to ‘figure out what I can do’.

#This isn’t perfect

Twitter has made me a literally better person, because it has exposed me to viewpoints I don’t have in my daily life that have made me more empathetic to others. It has changed my politics, making me vastly more open to systemic critiques of US center-left politics. So I’m reluctant to say ‘use it less, particularly for politics’. But I feel like it’s the only way to stay mentally well in our current world.

Complying with Creative Commons license attribution requirements in slides and powerpoint

Mon, 27 Feb 2017 00:00:00 GMT

When I was at Mozilla and WMF, I frequently got asked how to give proper credit when using Creative Commons-licensed images in slideshows. I got the question again last week, and am working on slides right now, so here’s a quick guide.

#The basics

First, a quick refresher. To comply with Creative Commons (CC) attribution requirements, you need to provide four things in a “reasonable” manner:

the title of the work (if there is one);
the author (might be an internet username);
the source (where you got it); and
the license (including version).

CC helpfully condenses those to “TASL”. An example:

“Larry Lessig giving #ccsummit2011 keynote” by David Kindler is licensed under CC BY 2.0

Creating this information has traditionally been a pain, but this one were generated with one click by the great new “copy credit as text” button in the CC search beta!

Once you’ve created an appropriate credit line, the question, then, is what is a “reasonable” way to put it into a slide deck? There are a few options.

#The maximalist option

An obvious option is to put the credit information on every slide, like the lower right hand corner here:

From “‘Program and Engagement Coordination’ – A reflective process management to take movement conferences to the next level”, by Cornelius Kibelka, under CC BY 4.0.

This has some benefits:

Clearly complies with the license.
Regularly reminds the audience that the images are available and reusable.
If you reorganize the slides, the credit stays with the image.

Things that aren’t so great:

Distracts from your message.
Very difficult to read, so not very useful to the audience, or motivating for the author.

#What Lessig does

To keep the focus on his content, Creative Commons founder Lessig puts all his attributions on a single slide at the end of each talk. (This is consistent with his famous “Lessig method” — large, bold images and very few words.) You can see an example just before the end of a talk he gave in 2013. Note that Lessig does not give an oral explanation of what is on the slide, or mention of the license, since they are shown during applause.

My own slides do something similar:

I give more detail by providing links, and note that all images are specifically CC BY-SA 3.0 unless otherwise noted.

So what’s good/bad about this approach? Good:

Doesn’t distract from your message as a speaker (which is the reason you’re speaking, after all!)
Complies with the license, since it is “reasonable” for the slide medium.

Bad:

Doesn’t give the authors much recognition.
Only weakly informs the audience that that the images are available and reusable (since it is at the end and nearly unreadable).
If you reorder your slides, or copy and paste into a different deck, you also have to remember to reorder/reuse your attribution slide.

#Improving recognition and utility

Given those drawbacks, here are two things you can consider doing to improve on Lessig’s approach.

#Fix utility with a clear link to downloadable information

Consider adding a slide at the end, before the full attribution slide, that provides a download link and mentions the license — something like “download slides, and get links and licenses for images, at lu.is/talks”. If you leave that slide up during Q&A, and the URL is short and memorable, the audience can easily find the licensing information later when it is useful to them.

#Recognize authors with a thank-you slide

The small type and quick flash of a long attribution slide may be legally compliant, but it does not help give authors the recognition they often want. So consider adding a “thank you” slide with just the names of authors, and a prominent CC logo, without any titles and licensing information. It will make the authors happy, especially if any of them are in the audience!

What to know before jumping into a career as an open source lawyer

Tue, 07 Feb 2017 00:00:00 GMT

Originally published at opensource.com.

You enjoy thinking about free software licenses, you’re angry about the latest patent troll, and you’ve said IANAL so many times that you’ve considering becoming an open source lawyer. What now?

#By the numbers

First, going to law school is a gamble. Recent American law school graduates must fight fiercely for one of the few jobs that can cover their massive debt, and roughly 50% fail the California bar. And, the open source gamble is bigger, because the opportunities are even fewer.

Only a few dozen new grads a year are hired to do anything even vaguely involving open source. Only a few dozen lawyers in the entire world dedicate more than a quarter of their time to open source. Only a lucky handful, like those at Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC), work primarily directly for communities and volunteer developers.

Note that international law schools are less expensive, but fewer open source legal jobs exist outside the US, so overall the gamble is similar.

Next, before we dive into being an open source lawyer, consider that there are many other routes to making the world’s software better, like being an engineer, usability expert, or an activist.

#What do you hope to accomplish?

If you do want to fight for one of those few jobs, ask yourself what you are actually looking to accomplish. Think of most open source law as a niche within “technology transactions” (or “tech trans” for short). Tech trans is the branch of law concerned with selling or licensing intellectual property rights. While this focus is commonly on licensing proprietary technology, many of the same principles apply to open source licensing, and usually tech trans lawyers are the ones who get the call to deal with open source issues.

Two good introductions to the day-to-day work of tech trans lawyers are The Tech Contracts Handbook and A Primer on IP Licensing. If reading (and highlighting and underlining) these books whets your appetite, you might be ready to get more serious about a tech trans career. If you fall asleep partway through reviewing your first indemnity clause then that might be a sign.

Tech trans isn’t the only way to become a lawyer who works on open source, of course. The biggest open source organizations need people with many different skillsets. Several members of Red Hat’s legal team were patent attorneys, and Wikimedia’s last general counsel was a former federal prosecutor. However, if you want to work day-to-day with open source, tech trans is your best bet.

#How to get a tech trans job

You can improve your odds of landing a job as a tech trans attorney, and at getting and succeeding at open source work once you get that job, if you:

Have a tech job first. Working for a few years in tech is the best thing you can do to help you succeed in technology law. Best case, you realize you love that career and skip law school (and law school debt) altogether. Worst case, you have stories to discuss in interviews and useful experience working with code and engineers. Don’t become a paralegal—taking this route is common route for non-tech lawyers, but it doesn’t give you relevant tech experience.
Participate in an open community. I’ve had college students who have never contributed to an open source project tell me they want to become open source lawyers. But contributing gives you hands-on experience, builds your network, and helps you understand the logic and processes behind the licenses you’ll have to interpret.
Pick a top law school with a strong IP faculty. Lawyers are notoriously snobby when hiring new graduates, so apply to schools that have a strong overall reputation and a good intellectual property faculty. Acceptance into these schools is very difficult, and if you don’t get in, you have a good (and relatively cheap) early warning about the odds of getting a job after graduation.
Take more than IP courses, like advanced classes in contracts. To be a great tech trans (and open source) lawyer, you need to know about copyrights, patents, and trademark, but reading and drafting contracts is every bit as important. Introductory contracts courses don’t cover those topics, so seek out advanced contracts courses. Knowledge of tax, corporate law, and litigation is also helpful, because open source companies often encounter those issues.
Consider working in-house your first summer. At top law schools, most students look to get a law firm job their first summer. Consider looking for jobs at tech companies instead—they’re usually very hands on and will give you a good background as you start career.
Be willing to move to California. While North Carolina, New York, and Massachusetts have some terrific open source jobs, you’ll maximize your chance of getting work by going to California because many law firms (and clients) who do tech work are based there.

#Where to start your career

Starting your career at a software company rather than a law firm is possible, but doing so is often considered a career handicap because junior in-house counsel tend to do the repetitive, less-diverse work. Instead, the best way to get tech trans (and open source) work is to go to a law firm that already does a lot of it. The senior lawyers at these firms use their reputation to bring the work in, and then the junior lawyers (hopefully you) actually get to do the work.

Your law school’s hiring office can help you find rankings of firms that do tech trans, like this one, and explain how to apply. When you interview, let lawyers know that (1) open source is an area you’re interested in and have relevant skills for, but (2) make clear to them that you’re interested in all the other aspects of tech trans—because you will be doing plenty of traditional licensing and startup work as well.

#Bottom line on the open source lawyer

Advising clients on open source issues is a ton of fun—you often get to do deep dives into the technology to understand how it works, you can have a huge impact on their products and bottom line, and you can also help build healthy communities of paid developers and volunteers who are creating better tech.

However, getting there is a very long road that not many people can get on or stay on. Taking the steps above can help get you there. Good luck!

Deep thanks to the many members of Red Hat’s legal team who helped me start my career, and who may recognize their own advice!

React's license: necessary and open?

Mon, 31 Oct 2016 00:00:00 GMT

I got multiple emails last week about React’s patent license, and this analysis made the rounds. So a few quick thoughts.

tl;dr: React’s patent license (1) isn’t a bad idea, because the BSD license is not explicit about granting patent rights; and (2) probably meets the requirements of the Open Source Definition.

Disclaimer: I have in the past counseled Facebook, but I do not currently represent them, and have never advised them on React.

#Why are we here?

Big software companies who genuinely want to give away infrastructure code like React generally have three slightly conflicting goals:

be super-permissive (because you want maximum use)
(a) including GPL-compatibility! (if you take maximum use seriously)
give users confidence that you won’t sue them over patents
(optional) have defensive patent clauses (if you want to discourage your users from suing you over patents)

Here’s the problem: historically, there hasn’t been a license that meets all of those needs. No license gives both #1(a) and #3, because FSF has historically considered patent termination an incompatibility with GPL v2. BSD/MIT does #1, but doesn’t do 3 – and may not give you confidence about patents (#2).

#BSD doesn’t give patent confidence?!?

You might be surprised when I say the BSD license may not give users confidence around patents. You’re not alone! El Camino Legal writes:

I’ve never heard any lawyer postulate that [the BSD license] does not grant a license to fully exploit the licensed software under all of the licensor’s intellectual property. … Developers-licensees (or, more to the point, their lawyers) have traditionally been very confident that the BSD License does not leave room for a licensor to successfully sue under patents.

I personally think a court should and probably wouldread the BSD license in this way. But I — and many other FOSS experts — are not “very” confident about this, especially for clients at high patent risk for some reason.

Why not? In short, the BSD license does not actually say “you have a license to use our patents” — it just says “you can use our software”. Courts should in this case say “of course allowing you to use their software also allows you to use their patents”. (In US patent law, this is called an implied license.) But whether a court will do this varies from country to country, and even court to court. And in an era (hopefully ending soon!) of mass litigation over software patents, some large companies — and individuals — reasonably want more confidence than that.

You don’t have to take my word for it: law firms, scholars, and FSF have written about concerns with implied licenses. Google took the issue seriously enough to write a React-like additional permission for WebM; and Oracle explicitly cited the problem as motivation for writing, and getting OSI approval for, a BSD-style license with explicit patent grant. (HP doesn’t like Oracle’s license, but still agrees that “there may be a need” to address the problem.)

Don’t over-react by deleting all your BSD-license code! BSD’s implied patent license is probably fine, the vast majority of the time. But if you use BSD-licensed code and face increased patent risk (say, you compete with the author, and they have a lot of patents) then it is reasonable to investigate more. And if you publish code under BSD there is no harm, and some potential benefit, in resolving the uncertainty up front with explicit patent language. This is exactly what Facebook seems to have tried here.

#Is it well-written?

Since (until recently) there were no standard permissive licenses with an explicit patent license, concerned companies have used custom-drafted licenses. Unfortunately, virtually no one gets new open licenses right on the first try. For example, Google revised their WebM patent language after early feedback from the open license community. And even the most careful open license drafters have a clause they regret. (Ask me over a beer sometime.)

Given that history, it isn’t surprising that this new license is somewhat inelegant. For example, El Camino is correct that the “Necessary Claim” language comes from standards rather than software. (I suspect Facebook got it from either the Apache license and the WebM patent grant.) I’d personally add that “for the avoidance of doubt” is usually not good practice. And I’m curious why they called this an “additional” grant in the title of the document — on the one hand, that could be read to acknowledge the implicit grant in the BSD license (great!), but on the other hand it could be read to weaken the value of the termination clause (not so hot). (And of course, Facebook also had some second thoughts, updating the license to allow countersuits – against themselves!)

#Is it open?

El Camino’s blog post has gotten attention in large part for claiming that the React license is not open source. Respectfully, I think they’ve gotten this wrong, and I want to correct the record.

Their claim that React is not open source hinges on the definition of a “fee” in section 1 of the Open Source Definition. The Definition says:

The license shall not require a royalty or other fee for such sale.

El Camino argues that the React license clause that requires you not to sue Facebook over patents is a “fee”, since the licensee “pays a price… not… paid with money” to use the software. This interpretation is not unreasonable! Giving up your options is, indeed, a “price” in some sense.

However, the OSI and the broader open source community have always interpreted “fee” to mean monetary payment. This is reflected in the annotatedOpen Source Definition, which states that this clause “require[s] free redistribution” (emphasis mine).

More conclusively, the GPL (indeed, all copyleft licenses) also require you to give up some options — the option to make proprietary derivatives! If “fee” was defined as “giving up options”, then the GPL would never have been treated as an open license. Instead, GPL has always been considered open by the Open Source Initiative — pretty conclusive evidence that “fee” means monetary payment.

And of course, as El Camino noted in an update to their original post, OSI approved similar patent language when they approved MPL 1.1.

I’m not going to firmly claim that the React license is compliant with the Open Source Definition, since it hasn’t gone through a full OSI review. But I think the concern raised by El Camino is based on a (well-intentioned) misunderstanding of the Open Source Definition, and the language would likely pass an OSI review for OSD compliance.

#Is it a good idea?

Of course, a license can meet the requirements of the Open Source Definition and still not be a great idea. For example, when drafting MPL 2.0 we realized that narrowing MPL 1.1’s patent termination clause would encourage use in some cases while not hurting Mozilla’s contributors. I suspect that, overall, React’s license would be better if it made the same change. But, again, “you might not want to use it if your company is a frequent patent litigator and/or huge Facebook competitor” is not the same as “not open”.

#License protects users, not just Facebook

It is important to note that there are two key ways that this clause protects React’s users, not just Facebook.

First, there is the obvious one: this gives users a very explicit patent license. If Zuckerberg retires tomorrow (or, um, sells their open source components to Oracle) React’s users will still have a very clear license to those patents.

Second, this clause gives Facebook the ability to protect React users who are sued over React-related patents, not just Facebook. Would Facebook actually protect React users that way? No idea! But if I’m a troll and considering suing React users en masse, this language at least gives a reason to pause and think twice. (MPL 2.0’s patent retaliation clause, canceling not just the patent license but also the copyright license, would have even more teeth – something for Facebook to consider if they revise this again :)

#Bottom line

Is the React license elegant? No. Should you be worried about using it? Probably not. If anything, Facebook’s attempt to give users an explicit patent license should probably be seen as a good faith gesture that builds some confidence in their ecosystem.

But yeah, don’t use it if your company intends to invest heavily in React and also sue Facebook over unrelated patents. That… would be dumb. :)

Public licenses and data: So what to do instead?

Mon, 26 Sep 2016 00:00:00 GMT

I just explained why open and copyleft licensing, which work fairly well in the software context, might not be [legally workable](http://lu.is/2016/09/copyleft-and-data-database-law-as-poor-platform/), or [practically a good idea](http://lu.is/2016/09/copyleft-and-data-databases-as-poor-subject/), around data. So what to do instead? tl;dr: say no to licenses, say yes to norms.

“Day 43-Sharing” by A. David Holloway, under CC BY 2.0.

#Partial solutions

In this complex landscape, it should be no surprise that there are no perfect solutions. I’ll start with two behaviors that can help.

#Education and lawyering: just say no

If you’re reading this post, odds are that, within your organization or community, you’re known as a data geek and might get pulled in when someone asks for a new data (or hardware, or culture) license. The best thing you can do is help explain why restrictive “public” licensing for data is a bad idea. To the extent there is a community of lawyers around open licensing, we also need to be comfortable saying “this is a bad idea”.

These blog posts, to some extent, are my mea culpa for not saying “no” during the drafting of ODbL. At that time, I thought that if only we worked hard enough, and were creative enough, we could make a data license that avoided the pitfalls others had identified. It was only years later that I finally realized there were systemic reasons why we were doomed, despite lots of hard work and thoughtful lawyering. These posts lay out why, so that in the future I can say no more efficiently. Feel free to borrow them when you also need to say no :)

#Project structure: collaboration builds on itself

When thinking about what people actually want from open licenses, it is important to remember that how people collaborate is deeply impacted by factors of how your project is structured. (To put it another way, architecture is also law.) For example, many kernel contributors feel that the best reason to contribute your code to the Linux kernel is not because of the license, but because the high velocity of development means that your costs are much lower if you get your features upstream quickly. Similarly, if you can build a big community like Wikimedia’s around your data, the velocity of improvements is likely to reduce the desire to fork. Where possible, consider also offering services and collaboration spaces that encourage people to work in public, rather than providing the bare minimum necessary for your own use. Or more simply, spend money on community people, rather than lawyers! These kinds of tweaks can often have much more of an impact on free-riding and contribution than any license choice. Unfortunately, the details are often project specific - which makes it hard to talk about in a blog post! Especially one that is already too long.

#Solving with norms

So if lawyers should advise against the use of data law, and structuring your project for collaboration might not apply to you, what then? Following Peter Desmet, Science Commons, and others, I think the right tool for building resilient, global communities of sharing (in data and elsewhere) is written norms, combined with a formal release of rights.

Norms are essentially optimistic statements of what should be done, rather than formal requirements of what must be done (with the enforcement power of the state behind them). There is an extensive literature, pioneered by Nobelist Elinor Ostrom, on how they are actually how a huge amount of humankind’s work gets done - despite the skepticism of economists and lawyers. Critically, they often work even without the enforcement power of the legal system. For example, academia’s anti-plagiarism norms (when buttressed by appropriate non-legal institutional supports) are fairly successful. While there are still plagiarism problems, they’re fairly comparable to the Linux kernel’s GPL-violation problems - even though, unlike GPL, there is no legal enforcement mechanisms!

#Norms and licenses have similar benefits

In many key ways, norms are not actually significantly different than licenses. Norms and licenses both can help (or hurt) a community reach their goals by:

Educating newcomers about community expectations: Collaboration requires shared understanding of the behavior that will guide that collaboration. Written norms can create that shared expectation just as well as licenses, and often better, since they can be flexible and human-readable in ways legally-binding international documents can’t.
Serving as the basis for social pressure: For the vast majority of collaborative projects, praise, shame, and other social nudges, not legal threats, are the actual basis for collaboration. (If you need proof of this, consider the decades-long success of open source before any legal enforcement was attempted.) Again, norms can serve this role just as well or not better, since it is often desire to cooperate and a fear of shaming that are what actually drive collaboration.
Similar levels of enforcement: While you can’t use the legal system to enforce a norm, most people and organizations also don’t have the option to use the legal system to enforce licenses - it is too expensive, or too time consuming, or the violator is in another country, or one of many other reasons why the legal system might not be an option (especially in data!) So instead most projects result to tools like personal appeals or threats of publicity - tools that are still available with norms.
Working in practice (usually): As I mentioned above, basing collaboration on social norms, rather than legal tools, work all the time in real life. The idea that collaboration can’t occur without the threat of legal sanction is really a somewhat recent invention. (I could actually have listed this under differences - since, as Ostrom teaches us, legal mechanisms often fail where norms succeed, and I think that is the case in data too.)

#Why are norms better?

Of course, if norms were merely “as good as” licenses in the ways I just listed, I probably wouldn’t recommend them. Here are some ways that they can be better, in ways that address some of the concerns I raised in my earlier posts in this series:

Global: While building global norms is not easy, social norms based on appeals to the very human desires for collaboration and partnership can be a lot more global than the current schemes for protecting database or hardware rights, which aren’t international. (You can try to fake internationalization through a license, but as I pointed out in earlier posts, that is likely to fail legally, and be ignored by exactly the largest partners who you most want to get on board.)
Flexible: Many of the practical problems with licenses in data space boil down to their inflexibility: if a license presumes something to be true, and it isn’t, you might not be able to do anything about it. Norms can be much more generous - well-intentioned re-users can creatively reinterpret the rules as necessary to get to a good outcome, without having to ask every contributor to change the license. (Copyright law in the US provides some flexibility through fair use, which has been critical in the development of the internet. The EU does not extend such flexibility to data, though member states can add some fair dealing provisions if they choose. In neither case are those exceptions global, so they can’t be relied on by collaborative projects that aim to be global in scope.)
Work against, not with, the permission culture: Lessig warned us early on about “permission culture” - the notion that we would always need to ask permission to do anything. Creative Commons was an attempt to fight it, but by being a legal obligation, rather than a normative statement, it made a key concession to the permission culture - that the legal system was the right terrain to have discussions about sharing. The digital world has pretty whole-heartedly rejected this conclusion, sharing freely and constantly. As a result, I suspect a system that appeals to ethical systems has a better chance of long-term sustainability, because it works with the “new” default behavior online rather than bringing in the heavy, and inflexible, hand of the law.

#Why you still need a (permissive) license

Norms aren’t enough if the underlying legal system might allow an early contributor to later wield the law as a threat. That’s why the best practice in the data space is to use something like the Creative Commons public domain grant (CC-Zero) to set a clear, reliable, permissive baseline, and then use norms to add flexible requirements on top of that. This uses law to provide reliability and predictability, and then uses norms to address concerns about fairness, free-riding, and effectiveness. CC-Zero still isn’t perfect; most notably it has to try to be both a grant and a license to deal with different international rules around grants.

#What next?

In this context, when I say “norms”, I mean not just the general term, but specifically written norms that can act as a reference point for community members. In the data space, some good examples are DPLA’s “CCO-BY” and the Canadensys biodiversity initiative. A more subtle form can be found buried in the terms for NIH’s Clinical Trials database. So, some potential next steps, depending on where your collaborative project is:

If your community has informal norms (“attribution good! sharing good!”) consider writing them down like the examples above. If you’re being pressed to adopt a license (hi, Wikidata!), consider writing down norms instead, and thinking creatively about how to name and shame those who violate those norms.
If you’re an organization that publishes licenses, consider using your drafting prowess to write some standard norms that encapsulate the same behaviors without the clunkiness of database (or hardware) law. (Open Data Commons made some moves in this direction circa 2010, and other groups could consider doing the same.)
If you’re an organization that keeps getting told that people won’t participate in your project because of your license, consider moving towards a more permissive license + a norm, or interpreting your license permissively and reinforcing it with norms.

Good luck! May your data be widely re-used and contributors be excited to join your project.

Copyleft, attribution, and data: other considerations

Wed, 21 Sep 2016 00:00:00 GMT

Public licenses for databases don't work well. Before going into solutions to that problem, though, I wanted to talk briefly about some things that are important to consider when thinking about solutions: real-world examples of the problems; a common, but bad, solution; and a discussion of the motivations behind public licenses.

“Bullfrog map unavailable”, by Peter Desmets, under CC BY 3.0 unported

#Real-world concerns, not just theoretical

When looking at solutions, it is important to understand that the practical concerns I blogged about aren’t just theoretical — they matter in practice too. For example, Peter Desmet has done a great job showing how overreaching licenses make bullfrog maps (and other data combinations) illegal. Alex Barth of OpenStreetMap has also discussed how ODbL creates problems for OSM users (though he got some Wikipedia-related facts wrong). And I’ve spoken to very well-intentioned organizations (including thoughtful, impactful non-profits) scared off from OSM for similar reasons.

On the flip side, because these rules are based on such flimsy legal grounds, sophisticated corporate legal departments often feel comfortable circumventing the requirements by exploiting loopholes. (Needless to say, they don’t blog about the problems with the licenses - they just go ahead and use the loopholes.) So overreaching attempts to create new rights are, in many ways, the worst of both worlds: they hurt well-intentioned cooperation, and don’t dissuade parties with a significant interest in exploiting the commons.

#What not to do: create new “rights”

When thinking about solutions, it is unfortunately also important to say what isn’t a good idea: create new rights, or override limitations on old ones. The Free Software Foundation, to their great credit, has always consistently said that if weakening copyright also weakens the GPL, they’ll take that tradeoff; and that vice-versa, the GPL should not ask for rights that go beyond copyright law. The most recent copyleft licenses from Creative Commons, Mozilla, and the FSF all make this explicit: limitations on copyright, like fair use, are not trumped by our licenses.

Unfortunately, many people have a good-faith desire to see copyleft-like results in other domains. As a result, they’ve gone the wrong way on this point. ODbL is probably the most blatant example of this: even at the time, Science Commons correctly pointed out that ODbL’s attempt to create database rights by contract outside of the EU was a bad idea. Unfortunately, well-intentioned people (including me!) pushed it through anyway. Similarly, open hardware proponents have tried to stretch copyright to cover functional works, with predictably messy results.

This is not just practically wrong, for the reasons I’ve explained in earlier posts. It is also ethically wrong for those of us who want to see more data sharing, because any “rights” we create by fiat are going to end up being used primarily to stop sharing, not encourage it.

Consider this section a brief sketch for a future post - if I forgot something big, please let me know, but please don’t roast me in comments for being brief or reductive about your favorite motivation.

It is important when writing about public licenses to remember why the idea of placing restrictions on re-use is so intuitively appealing outside of software. If we don’t understand why people want to do less-than-public domain, it’s hard to come up with solutions that actually work. Motivations tend to be some combination (varying from person to person and community to community) of:

Recognition: Many people want to at least be recognized for their work, even when they ask for nothing else. (When Creative Commons assessed usage after their 1.0 licenses, 97-98% of people chose attribution.) This sentiment underlies many otherwise “permissive” licenses, as well as academic norms around plagiarism and attribution.
Reducing free riding: Lots of people are afraid that commons can be destroyed by people who use the resource without giving back. Historically, this “tragedy of the commons” was about rivalrous goods (like fisheries), but the same concern is often raised in the context of collaborative communities, whose labor can be rivalrous even when their goods are non-rivalrous. Some people like share-alike requirements because, pragmatically, they feel such requirements are one way to prevent (or at least reduce) this risk by encouraging people to either participate fully or not participate at all. (If you’re interested in this point, I’ve written about it before.)
“Fairness”: Many people like share-alike out of a deep moral sense that if you take, you should also give back. This often looks the same as the previous point, but with the key distinction that at least some people focused on fairness care more about process and less about outcomes: a smaller, less productive community with more sharing may, for them, be better than a larger, more productive community where not everyone shares perfectly.
Access to allow self-help: Another variation on the previous two points is a use of copyleft that focuses less on “is the author helping me by cooperating” and more on “did the author give me materials I can then use to help myself”. In this view, increased access to raw material (like source code, or data) can be good even the authors are non-cooperative. (To those familiar with the Linux kernel discussions, this is essentially “I got a lousy driver, and the authors hate me, but at least I got *a* driver”.)
Ethical: Many people simply think data/source should never be proprietary, and so will use any means possible, like copyleft, to increase the amount of non-proprietary code in the world.

All of these motivations can be more or less valid at different points in time, in ways that (again) deserve a different post. (For example, automatic attribution may not have the same impact as “human” attribution, which may not be a surprise given the evidence on crowding out of intrinsic motivations.)

Finally, next (and final?) post: what solutions we’ve got.

Copyleft and data: databases as poor subject

Wed, 14 Sep 2016 00:00:00 GMT

*tl;dr: Open licensing works when you strike a healthy balance between obligations and reuse. Data, and how it is used, is different from software in ways that change that balance, making reasonable compromises in software (like attribution) suddenly become insanely difficult barriers.*

In my last post, I wrote about how database law is a poor platform to build a global public copyleft license on top of. Of course, whether you can have copyleft in data only matters if copyleft in data is a good idea. When we compare software (where copyleft has worked reasonably well) to databases, we’ll see that databases are different in ways that make even “minor” obligations like attribution much more onerous.

Card Puncher from the 1920 US Census.

#How works are combined

In software copyleft, the most common scenarios to evaluate are merging two large programs, or copying one small file into a much larger program. In this scenario, understanding how licenses work together is fairly straightforward: you have two licenses. If they can work together, great; if they can’t, then you don’t go forward, or, if it matters enough, you change the license on your own work to make it work.

In contrast, data is often combined in three ways that are significantly different than software:

Scale: Instead of a handful of projects, data is often combined from hundreds of sources, so doing a license conflicts analysis if any of those sources have conflicting obligations (like copyleft) is impractical. Peter Desmet did a great job of analyzing this in the context of an international bio-science dataset, which has 11,000+ data sources.
Boundaries: There are some cases where hundreds of pieces of software are combined (like operating systems and modern web services) but they have “natural” places to draw a boundary around the scope of the copyleft. Examples of this include the kernel-userspace boundary (useful when dealing with the GPL and Linux kernel), APIs (useful when dealing with the LGPL), or software-as-a-service (where no software is “distributed” in the classic sense at all). As a result, no one has to do much analysis of how those pieces fit together. In contrast, no natural “lines” have emerged around databases, so either you have copyleft that eats the entire combined dataset, or you have no copyleft. ODbL attempts to manage this with the concept of “independent” databases and produced works, but after this recent case I’m not sure even those tenuous attempts hold as a legal matter anymore.
Authorship: When you combine a handful of pieces of software, most of the time you also control the licensing of at least one of those pieces of software, and you can adjust the licensing of that piece as needed. (Widely-used exceptions to this rule, like OpenSSL, tend to be rare.) In other words, if you’re writing a Linux kernel driver, or a Wordpress theme, you can choose the license to make sure it complies. Not necessarily the case in data combinations: if you’re making use of large public data sets, you’re often combining many other data sources where you aren’t the author. So if some of them have conflicting license obligations, you’re stuck.

#How attribution is managed

Attribution in large software projects is painful enough that lawyers have written a lot on it, and open-source operating systems vendors have built somewhat elaborate systems to manage it. This isn’t just a problem for copyleft: it is also a problem for the supposedly easy case of attribution-only licenses.

Now, again, instead of dozens of authors, often employed by the same copyright-owner, imagine hundreds or thousands. And imagine that instead of combining these pieces in basically the same way each time you build the software, imagine that every time you have a different query, you have to provide different attribution data (because the relevant slices of data may have different sources or authors). That’s data!

The least-bad “solution” here is to (1) tag every field (not just data source) with licensing information, and (2) have data-reading software create new, accurate attribution information every time a new view into the data is created. (I actually know of at least one company that does this internally!) This is not impossible, but it is a big burden on data software developers, who must now include a lawyer in their product design team. Most of them will just go ahead and violate the licenses instead, pass the burden on to their users to figure out what the heck is going on, or both.

#Who creates data

Most software is either under a very standard and well-understood open source license, or is produced by a single entity (or often even a single person!) that retains copyright and can adjust that license based on their needs. So if you find a piece of software that you’d like to use, you can either (1) just read their standard FOSS license, or (2) call them up and ask them to change it. (They might not change it, but at least they can if they want to.) This helps make copyleft problems manageable: if you find a true incompatibility, you can often ask the source of the problem to fix it, or fix it yourself (by changing the license on your software).

Data sources typically can’t solve problems by relicensing, because many of the most important data sources are not authored by a single company or single author. In particular:

Governments: Lots of data is produced by governments, where licensing changes can literally require an act of the legislature. So if you do anything that goes against their license, or two different governments release data under conflicting licenses, you can’t just call up their lawyers and ask for a change.
Community collaborations: The biggest open software relicensing that’s ever been done (Mozilla) required getting permission from a few thousand people. Successful online collaboration projects can have 1-2 orders of magnitude more contributors than that, making relicensing is hard. Wikidata solved this the right way: by going with CC0.

#What is the bottom line?

Copyleft (and, to a lesser extent, attribution licenses) works when the obligations placed on a user are in balance with the benefits those users receive. If they aren’t in balance, the materials don’t get used. Ultimately, if the data does not get used, our egos feel good (we released this!) but no one benefits, and regardless of the license, no one gets attributed and no new material is released. Unfortunately, even minor requirements like attribution can throw the balance out of whack. So if we genuinely want to benefit the world with our data, we probably need to let it go.

#So what to do?

So if data is legally hard to build a license for, and the nature of data makes copyleft (or even attribution!) hard, what to do? I’ll go into that in my next post.

Copyleft and data: database law as (poor) platform

Mon, 12 Sep 2016 00:00:00 GMT

tl;dr: Databases are a very poor fit for any licensing scheme, like copyleft, that (1) is intended to encourage use by the entire world but also (2) wants to place requirements on that use. This is because of broken legal systems and the way data is used. Projects considering copyleft, or even mere attribution, for data, should consider other approaches instead.

The original database: Hollerith Census Machine Dials, by Marcin Wichary, under CC BY 2.0.

I’ve been a user of copyleft/share-alike licenses for a long time, and even helped draft several of them, but I’ve come around to the point of view that copyleft is a poor fit for data. Unfortunately, I’ve been explaining this a lot lately, so I want to explain why in writing. This first post will focus on how the legal system around databases is broken. Later posts will focus on how databases are hard to license, and what we might do about it.

#FOSS licensing, and particularly copyleft, relies on legal features database rights lack

Defenders of copyleft often have to point out that copyleft isn’t necessarily anti-copyright, because copyleft depends on copyright. This is true, of course, but the more I think about databases and open licensing, the more I think “copyleft depends on copyright” almost understates the case - global copyleft depends not just on “copyright”, but on very specific features of the international copyright system which database law lacks. To put it in software terms, the underlying legal platform lacks the features necessary to reliably implement copyleft. Consider some differences between the copyright system and database law:

Maturity: Copyright has had 100 or so years as an international system to work out kinks like “what is a work” or “how do joint authors share rights?” Even software copyright law has existed for about 40 years. In contrast, database law in practice has existed for less than 20 years, pretty much all of that in Europe, and I can count all the high court rulings on it on my fingers and toes. So key terms, like “substantial”, are pretty hard to define-courts and legislatures simply haven’t defined, or refined, the key concepts. This makes it very hard to write a general-purpose public license whose outcomes are predictable.
Stability: Related to the previous point, copyright tends to change incrementally, as long-standing concepts are slowly adapted to new circumstances. (The gradual broadening of fair use in the Google era is a good example of this.) In contrast, since there are so few decisions, basically every decision about database law leads to upheaval. Open Source licenses tend to have a shelf-life of about ten years; good luck writing a database license that means the same thing in ten years as it does today!
Global nature: Want to share copyrighted works with the entire world? Copyright (through the Berne Convention) has you covered. Want to share a database? Well, you can easily give it away to the whole world (probably!), but want to reliably put any conditions on that sharing? Good luck! You’ve now got to write a single contract that is enforceable in every jurisdiction, plus a license that works in the EU, Japan, South Korea, and Mexico. As an example again, “substantial” - used in both ODbL and CC 4.0 - is a term from the EU’s Database Directive, so good luck figuring out what it means in a contract in the US or within the context of Japan’s database law.
Default rights: Eben Moglen has often pointed out that anyone who attacks the GPL is at a disadvantage, because if they somehow show that the license is legally invalid, then they get copyright’s “default”: which is to say, they don’t get anything. So they are forced to fight about the specific terms, rather than the validity of the license as a whole. In contrast, in much of the world (and certainly in the US), if you show that a database license is legally invalid, then you get database’s default: which is to say, you get everything. So someone who doesn’t want to follow the copyleft has very, very strong incentives to demolish your license altogether. (Unless, of course, the entire system shifts from underneath you to create a stronger default - like it may have in the EU with the Ryanair case.)

With all these differences, what starts off as hard (“write a general-purpose, public-facing license that requires sharing”) becomes insanely difficult in the database context. Key goals of a general-purpose, public license - global, predictable, reliable - are very hard to do. In upcoming posts, I’ll try to explain why, even if it were possible to write such a license from a legal perspective, it might not be a good idea because of how databases are used.

Free as in ... ? My LibrePlanet 2016 talk

Wed, 23 Mar 2016 00:00:00 GMT

Below is the talk I gave at LibrePlanet 2016. The tl;dr version:

Learning how political philosophy has evolved since the 1670s shows that the FSF’s four freedoms are good, but not sufficient.
In particular, the “capability approach” pioneered by Amartya Sen and Martha Nussbaum is applicable to software, and shows us how to think about improving the capability of people.
There are a bunch of ways that free software, as a movement, could refocus on liberating people, not code.

I did not talk about it in the talk (given the audience), but I think this approach is broadly applicable to every software developer who wants to make the world a better place (including usability-inclined developers, open web/standards folks, etc.), not just FSF members.

I was not able to use my speaker notes during the talk itself, so these may not match terribly well with what I actually said on Saturday - hopefully they’re a bit more coherent. Video will be posted here when I have it. [Update: video here.]

Most of you will recognize this phrase as borrowed from the Wikimedia Foundation. Think on it for a few seconds, and how it differs from the Four Freedoms.

I’d like to talk today about code freedom, and what it can learn from modern political philosophy.

Last time I was at Libre Planet, I was talking with someone in a hallway, and I mentioned that Libre Office had crashed several times while I was on the plane, losing some data and making me redo some slides. He insisted that it was better to have code freedom, even when things crashed in a program that I could not fix without reading C++ comments in German. I pointed out, somewhat successfully, that software that was actually reliable freed me to work on my actual slides.

We were both talking about “freedom” but we clearly had different meanings for the word. This was obviously unsatisfying for both of us - out common language/vocabulary failed us.

This is sadly not a rare thing: probably many of us have had the same conversation with parents, friends, co-workers, etc.

So today I wanted to dig into “freedom” - what does it mean and what frameworks do we hang around it.

So why do we need to talk about Freedom and what it means? Ultimately, freedom is confusing. When card-carrying FSF members use it, we mean a very specific thing - the four freedoms. When lots of other people use it, they mean… well, other things. We’ll get into it in more detail soon, but suffice to say that many people find Apple and Google freeing. And if that’s how they feel, then we’ve got a very big communication gap.

I’m not a political philosopher anymore; to the extent I ever was one, it ended when I graduated from my polisci program and… immediately went to work at Ximian, here in Boston.

My goal here today is to show you that when political philosophers talk about freedom, they also have some of the same challenges we do, stemming from some of the same historical reasons. They’ve also gotten, in recent years, to some decent solutions - and we’ll discuss how those might apply to us.

Apologies if any of you are actually political philosophers: in trying to cram this into 30 minutes, we’re going to take some very, very serious shortcuts!

Let’s start with a very brief introduction to political philosophy.

Philosophers of all stripes tend to end up arguing about what is “good”; political philosophers, in particular, tend to argue about what is “just”. It turns out that this is a very slippery concept that has evolved over time. I’ll use it somewhat interchangeably with “freedom” in this talk, which is not accurate, but will do for our purposes.

Ultimately, what makes a philosopher a political philosopher is that once they’ve figured out what justice might be, they then argue about what human systems are the best ways to get us to justice.

In some sense, this is very much an engineering problem: given the state of the world we’ve got, what does a better world look like, and how do we get there? Unlike our engineering problems, of course, it deals with the messy aspects of human nature: we have no compilers, no test-driven-development, etc.

So before Richard Stallman, who were the modern political philosophers?

Your basic “intro to political philosophy” class can have a few starting points. You can do Plato, or you can do Hobbes (the philosopher, not the tiger), but today we’ll start with John Locke. He worked in the late 1600s.

Locke is perhaps most famous in the US for having been gloriously plagiarized by Thomas Jefferson’s “life, liberty, and pursuit of happiness”. Before that, though, he argued that to understand what justice is, you have to look at what people are missing when they don’t have government. Borrowing from earlier British philosophers (mostly Hobbes), he said (in essence) that when people have no government, everyone steals from - and kills - everyone else. So what is justice? Well, it’s not stealing and killing!

This is not just a source for Jefferson to steal from; it is perhaps the first articulation of the idea that every human being (at least, every white man) is entitled to certain inalienable rights - what are often called the natural rights.

This introduces the idea that individual freedom (to live, to have health, etc.) is a key part of justice.

Locke was forward-thinking enough that he was exiled to the Netherlands at one point. But he was also a creature of his time, and concluded that monarchy could be part of a just system of government, as long as the people “consented” by, well, not immigrating.

This is in some sense pretty backwards, since in 1600s Europe, emigration isn’t exactly easy. But it is also pretty forward looking - his most immediate British predecessor, Hobbes, basically argued that Kings were great. So Locke is one of the first to argue that what the people want (another aspect of what we now think of as individual freedom) is important.

It is important to point out that Locke’s approach is what we’d now call a negative approach to rights: the system (the state, in this case) is obligated to protect you, but it isn’t obliged to give you anything.

Coming from the late 1600s, this is not a crazy perspective - most governments don’t even do these things. For Locke to say “the King should not take your stuff” is pretty radical; to have said “and it should also give you health care” would have also made him the inventor of science fiction. And the landed aristocracy are typically fans!

(Also, apologies to my typographically-sensitive friends; kerning of italicized fonts in Libre Office is poor and I got lazy around here about manually fixing it.)

But this is where Locke starts to fall down to modern ears: if you’re not one of the landed aristocracy; if you’ve got no stuff for the King to take, Locke isn’t doing much for you. And it turns out there are a whole lot of people in 1600s England without much stuff to take. So let’s fast forward 150+ years.

You all know who Marx is; probably many of you have even been called Marxists at one point or another!

Marx is complicated, and his historical legacy even more so. Let’s put most of that aside for today, and focus on one particular idea we’ve inherited from Marx.

For our purposes, out of all of Marx, we can focus on the key insight that people other than the propertied class can haveneeds.(This is not really his insight; but he popularizes it.) I

Having recognized that humans have needs, Marx then goes on to propose that, in a just society, the individual might not be the only one who has a responsibility to provide those needs - the state, at least when we reach a “higher phase” of economic and moral development, should also provide.

This sounds pretty great on paper, but it is important to grok that Marx argues that his perfect system will happen only when we’ve reached such a high level of economic development that no one will need to work, so everyone will work only on what they love. In other words, he ignores the scarcity we face in the real world. He also ignores inequality - since the revolution will have washed away all starting differences. Obviously, taken to this extreme, this has led to a lot of bad outcomes in the world - which is what gives “marxism” its bad name.

But it is also important to realize that this is better than Locke (who isn’t particularly concerned with inequality), and in practice the idea (properly moderated!) has led to the modern social welfare state. So it is a useful tool in the modern philosophical toolkit.

Fast forward again, another 100 years. Our scene moves down the street, to Harvard. Perhaps the two most important works of political philosophy of the 20th century are written and published within four years of each other, further up Mass Avenue from MIT.

John Rawls publishes his Theory of Justice in 1971; Robert Nozick follows up with his Anarchy, the State, and Utopia in 1974.

Rawls and Nozick, and their most famous books, differ radically in what they think of as justice, and what systems they think lead to the greatest justice. (Nozick is the libertarian’s libertarian; Rawls more of a welfare-state type.) Their systems, and the differences between them, are out of our scope today (though both are fascinating!).

However, both agree, in their ways, that any theory of a just world must grapple with the core fact that modern societies have a variety of different people, with different skills, interests, backgrounds, etc. (This shouldn’t be surprising, given that both were writing in the aftermath of the 60s, which had made so clear to many that our societies were pretty deeply unjust to a lot of people.)

This marks the beginning of the modern age of political philosophy: Locke didn’t care much about differences between people; Marx assumed it away. Nozick and Rawls can be said, effectively, to mark the point when political philosophy starts taking difference seriously.

But that was 40 years ago - what has happened since then?

So that brings us to the 1990s, and also to 2016. (If you haven’t already figured it out, political philosophy tends to move pretty slowly.)

The new-ish hotness in political philosophy is something called capability theory. The first work is put forward by Amartya Sen, an Indian economist working with (among others) the United Nations on how to focus their development work. Martha Nussbaum then picked up the ball, putting in a great deal of work to systematize it.

When Sen starts working on what became capability theory, he’s a development economist trying to help understand how to help improve the lives of his fellow Indian citizens. And he’s worried that a huge focus on GDP is not leading to very good outcomes. He turns to political theory, and it doesn’t help him: it is focused on very abstract systems. John Locke saying “life, liberty, property” and “sometimes monarchs are OK” doesn’t help him target the UN’s investment dollars.

So his question becomes: how do I create a theory of What is Just that actually helps guide decisions in the real world? Capability theory, in other words, is ultimately pragmatic.

To put it another way, you can think of the capability approach as an attempt to figure out what effective freedom is: how do we take freedom out of textbooks and into something that really empowers people?

One of the key flaws for Sen of existing theories was that they talked about giving people at worst, negative rights (protecting their rights to retain property they didn’t have) and at best, giving them resources (giving them things or training they couldn’t take advantage of). He found this unconvincing, because in his experience India’s constitution gave all citizens those formal rights, but often denied them those rights in practice, through poverty, gender discrimination, caste discrimination, etc.

And so from this observation we have the name of the approach: it focuses on what, pragmatically, people need to be capable of acting freely.

Some examples may be helpful here to explain what Sen and Nussbaum are getting at.

For example, if all men and women have the same formal access to education, but women get fewer job callbacks after college than men with identical resumes, or men refuse to care for children and aging parents, then it seems unlikely that we can really claim to have a just society.

Somalia, circa 1995-2000, was, on the face of it, a libertarian paradise: it gave you a lot of freedom to start businesses! No minimum wage, no EPA.

But it turns out you need more than “freedom from government interference” to run a business: you have to have a lot of other infrastructure as well. (Remember, here, Locke’s “negative” rights: government not stopping you, v. government supporting you.)

These examples suggest that answering political philosopher question #1 (“what is justice?”) requires more than just measuring access to resources. What you want to know to understand whether a system is just, you have to measure whether all people have the opportunity to get to the important goals.

In other words, do they have the capability to act?

This is the core insight that the capabilities approach is grounded in: it is helpful, but not enough, to say “someone has the natural rights” (Locke) or “some time in the future everyone will have the same opportunity” (Marx).

(Is any of this starting to ring a bell?)

Capability approach is, again, very pragmatic, and comes from a background of trying to allocate scarce development resources in the real world, rather than a philosopher’s cozy university office. So if you’re trying to answer the political philosopher’s question (“what system”), you need to pick and choose a few capabilities to focus on, and figure out what system will support those capabilities.

Again, an example might be helpful here to show how picking the right things to focus on can be important when you’re aiming to build a system that supports human capability.

If you focus on only one dimension, you’re going to get things confused. When Sen was beginning his work, the development community tended to focus exclusively on GDP. Comparing the Phillippines and South Africa by this number would have told you to focus your efforts on the Philippines.

But one of the most basic requirements to effective freedom - to supporting people’s capability to act - is being alive! When we look at it through that lens, we pretty quickly see that South Africa is worth more energy. It’s critical to look through that broader lens to figure out whether your work is actually building human freedom.

This is, perhaps, the most contentious area of capability theory - it’s where writing is being done across a variety of disciplines, including economics, political philosophy, sociology, and development. This writing has split into two main areas: the pragmatists, who just want to figure out useful tools that help them improve the world, and the theorists, who want to ground the theory in philosophy (sometimes as far back as Aristotle).

This is a great place to raise Martha Nussbaum again: she’s done the most to bring theoretical rigor to the capability approach. (Some people call Sen’s work the “capability approach”, to show that it is just a way of thinking about the problem; and Nussbaum’s work “capability theory”, to show that it is a more rigorous approach.)

I have bad news: there is no one way of doing this. Some approaches can include:

Local nuance: What is valued and important in one culture may not be in another; or different obstacles may exist in different places and times. Nussbaum’s work particularly focuses on this, interviewing people both to find criteria that are particularly relevant to them, but also to attempt to identify global values.
Democracy: Some of Sen’s early research showed that democracies were better at getting people food than non-democracies of similar levels of economic development, leading to avoidance of famines. So “what people prioritize based on their votes” is a legitimate way to understand the right capabilities to focus on.
Data: you’ll almost never see a table like the one I just showed you in most political philosophy! The capability approach embraces the use of data to supplement our intuitions and research.
Old-fashioned philosophizing: it can be perfectly appropriate to sit down, as Richard did, and noodle over our problems. I tend to think that this is particularly important when we’re identifying future capabilities - which is of course our focus here.

Each of these can be seen as overlapping ways of identifying the best issues to identify - all of them will be useful and valid in different domains.

Shared theme of that last slide? Thinking primarily about people. Things are always a means to an end in the capability approach - you might still want to measure them as an important stepping stone to helping people (like GDP!) but they’re never why you do something.

There is no one right way to pick which capabilities to focus on, which drives lots of philosophers mad. We’ll get into this in more detail soon - when I talk about applying this to software.

Probably the bottom line: if you want to know how to get to a more just system, you want to ask about the capabilitiesof the humans who are participating in that system. Freedom is likely to be one of the top things people want - but it’s a means, not the end.

So now we’ve come to the end of the philosophy lecture. What does this mean for those of us who care about software?

So, again, what do political philosophers care about?

The FSF’s four freedoms try to do the right thing and help build a more just world.

If you don’t have some combination of time, money, or programming skills, it isn’t entirely clear the four freedoms do a lot for you.

The four freedoms are negative rights: things no one can take away from you. And that has been terrific for our elites: Locke’s landed aristocracy is our Software as a Service provider, glad the King can’t take away his right to run MySQL. But maybe not so much for most human beings. This brings us to our second question - what system?

Inspired by the capability approach, what I would argue that we need is a focus on effective freedom. And that will need not just a change to our focus, but to our systems as well - we need to be pragmatic and inclusive.

So let me offer four suggestions for free software inspired by the capability approach.

We need to start by having empathy for all our users, since our goal should be software that liberates all people.

Like the bureaucrat who increases GDP while his people die young, if we write billions of lines of code, but people are not empowered, we’ve failed. Empathy for others will help us remember that.

Sen, Nussbaum, and the capability approach also remind us that to effectively provide freedom to people we need to draw opinions and information from the broadest possible number of people. That can simply take the form of going and listening regularly to why your friends like the proprietary software they use, or ideally listening to people who aren’t like you about why they don’t use free software. Or it can take the form of surveys or even data-driven research. But it must start with listening to others. Scratching our own itch is not enough if we want to claim we’re providing freedom.

Or to put it another way: our communities need to be as empowering as our licenses. There are lots of great talks this weekend on how to do that - you should go to them, and we should treat that as philosophically as important as our licenses.

I think it is important to point out that I think the FSF is doing a lot of great work in this area - this is the most diversity I’ve seen at Libre Planet, and the new priorities list covers a lot of great ground here.

But it is also a bad sign that at the new “Open Source and Feelings” conference, which is specifically aimed at building a more diverse FOSS movement, they chose to use the apolitical “open” rather than “free”. That suggests the FSF and free software more generally still have a lot of work to do to shed their reputation as being dogmatic and unwelcoming.

Which brings me to #2: just as we have to listen to others, we have to be self-critical about our own shortcomings, in order to grapple with the broad range of interests those users might have.

At the begining of this talk, I talked about my last visit to Libre Planet, and how hard it was to have a conversation about the disempowerment I felt when Libre Office crashed. The assumption of the very well-intentioned young man I was talking to was that of course I was more free when I had access to code. And in a very real way, that wasn’t actually true - proprietary software that didn’t crash was actually more empowering to me than libre software that did crash. And this isn’t just about crashing/not-crashing.

Ed Snowden reminded us this morning that Android is freely-licensed, but that doesn’t mean it gives them the capability to live a secure life.

Again, here, FSF has always done some of the right thing! You all recognize this quote: it’s from freedom zero. We often take pride in this, and we should!

But we also often say “we care about users” but only test what the license is. I’ve never seen someone say “this is not free, because it is impossible to use” - it is too easy, and too frequent, to say “well, the license says you can run the program as you wish, so it passes freedom zero”. We should treat that as a failure to be humble about.

Humility means admitting our current. unidimensional systems aren’t great at empowering people. The sooner we admit that freedom is complex, and goes beyond licensing, the quicker we can build better systems.

The third theme of advice I’d give is to think about impact. Again, this stems from the fundamental pragmatism of the capability approach. A philosophy that is internally consistent, but doesn’t make a difference for people, is not a useful philosophy. We need to take that message to heart.

Mako Hill’s quantitative research has shown us that libre code doesn’t necessarily mean quality code, or sucessful projects. If we want to impact users, we have to understand why our core development tools are no longer best-in-class, and fix them, or develop new models to replace them.

We built CVS, SVN, and git, and we used those tools to build some of the most widely-used pieces of software on earth. But it took the ease of use of github to make this accessible to millions of developers.

Netsplit.de is a search engine for IRC services. Even if both of these numbers are off by a factor of two (say, because of private networks missing from the IRC count, and if Slack is inflating user counts), it still suggests Slack will have more users than IRC this year. We need to think about why that is, and why free software like IRC hasn’t had the impact we’d like it to.

If we’re serious about spreading freedom, this sort of “post-mortem” of our successes and failures is not optional - it is a mandatory part of our commitment to freedom.

I’ve mentioned that democracy is one way of choosing what capabilities to focus on, and is typically presumed in serious analyses of the capability approach - the mix of human empowerment and (in Sen’s analysis) better pragmatic impact make it a no-brainer.

A free software focused on impact could make free licensing a similar no-brainer in the software world.

Dan Gillmor told us this morning that “I came for the technical excellence and stayed for the freedom”: as both he and Edward Snowden said this morning, we have to have broaden our definition of technical excellence to include usability and pragmatic empowerment. When we do that, our system - the underlying technology of freedom - can lead to real change.

This is the last, and hardest, takeaway I’ll have for the day.

We’ve learned from the capability approach that freedom is nuanced, complex, and human-focused. The four freedoms, while are brief, straightforward, and easy to apply, but those may not be virtues if our goal is to increase user freedom.

As I’ve said a few times, the four freedoms are like telling you the king can’t take your property: it’s not a bad thing, but it also isn’t very helpful if you don’t have any property.

We need to re-interpret “run the program as you wish” in a more positive light, expanding our definitions to speak to the concerns about usability and security that users have.

The capability approach provides us with questions - where do we focus? - but not answers. So it suggests we need to go past licensing, but doesn’t say where those other areas of focus might be. Here are some suggestions for what directions we might evolve free software in.

Learning from Martha Nussbaum and usability researchers, we could work with the next generation of software users to understand what they want, need, and deserve from effective software freedom.

We could learn from other organizations, like UNICEF, who have built design and development principles. The graphic here is from UNICEF’s design principles, where they talk about how they will build software that improves freedom for their audience.

It includes talk about source code - as part of a coherent whole of ten principles, not an end in and of itself.

Many parts of our community (including FSF!) have adopted codes of conduct or similar policies. We could draw on the consistent themes in these documents to identify key values that should take their place alongside the four freedoms.

Finally, we can vote with our code: we should be contributing where we feel we can have the most impact on user freedom, not just code freedom. That is a way of giving our impact: we can give our time only to projects that empower all users. In my ideal world, you come away determined to focus on projects that empower all people, not just programmers.

Ultimately, this is my vision, and why I remain involved in free software - I want to see people who are liberated. I hope after this talk you all understand why, and are motivated to help it happen. Thanks for listening.

The All Writs Act on Wikipedia v. legal academic reach

Thu, 18 Feb 2016 00:00:00 GMT

Legal friends! The world needs you. Here’s the graph of readership of All Writs Act on Wikipedia:

That’s 45,035 reads yesterday (by humans, not bots).((Big thanks to the tech team for figuring out how to differentiate - not something we could do until fairly recently, at least for public stats!)) That would put it 5th on SSRN’s all-time legal download list, right between William Landes and Cass Sunstein. Not bad company! Or in other words: anything you fix in this article in the next day or two is likely to be the most-read thing you ever write.

The article has been edited 39 times since the Apple letter was published. So it is a lot better than two days ago. But it could still use a lot of love - history, applicability outside of the Apple situation, etc. Contribute!

Since lawyers are particularly concerned about citation, it is worth mentioning that the editing experience especially when adding citations has become vastly better in the past year - in most cases for articles on SSRN, simply dropping the link into our citation editor will get you a fully-fleshed out and formatted citation (with thanks to our friends at Zotero!)

Software that liberates people: feels about FSF@30 and OSFeels@1

Fri, 02 Oct 2015 00:00:00 GMT

tl;dr: I want to liberate people*; software is a (critical) tool to that end. There is a conference this weekend that understands that, but I worry it isn’t FSF’s.*

Feelings are facts, by wrote, CC BY 2.0

This morning, social network chatter reminded me of FSF’s 30th birthday celebration. These travel messages were from friends who I have a great deal of love and respect for, and represent a movement to which I essentially owe my adult life.

Despite that, I had lots of mixed feels about the event. I had a hard time capturing why, though.

While I was still processing these feelings, late tonight, Twitter reminded me of a new conference also going on this weekend, appropriately called Open Source and Feelings. (I badly wanted to submit a talk for it, but a prior commitment kept me from both it and FSF@30.)

I saw the OSFeels agenda for the first time tonight. It includes:

Design and empathy (learning to build open software that empowers all users, not just the technically sophisticated)
Inclusive development (multiple talks about this, including non-English, family, and people of color) (so that the whole planet can access, and participate in developing, open software)
Documentation (so that users understand open software)
Communications skills (so that people feel welcome and engaged to help develop open software)

This is an agenda focused on liberating human beings by developing software that serves their needs, and engaging them in the creation of that software. That is incredibly exciting. I’ve long thought (following Sen and Nussbaum’s capability approach) that it is not sufficient to free people; they must be empowered to actually enjoy the benefits of that freedom. This is a conference that seems to get that, and I can’t wait to go (and hopefully speak!) next year.

The Free Software Foundation event’s agenda:

licenses
crypto
boot firmware
federation

These are important topics. But there is clearly a difference in focus here — technology first, not people. No mention of community, or of design.

This difference in focus is where this morning’s conflicted feels came from. On the one hand, I support FSF, because they’ve done an incredible amount to make the world a better place. (OSFeels can take open development for granted precisely because FSF fought so many battles about source code.) But precisely because I support FSF, I’d challenge it, in the next 15 years, to become more clearly and forcefully dedicated to liberating *people.*In this world, FSF would talk about design, accessibility, and inclusion as much as licensing, and talk about community-building protocols as much as communication protocols. This is not impossible: LibrePlanet had at least some people-focused talks (e.g.), and inclusion and accessibility are a genuine concern of staff, even if they didn’t rise to today’s agenda. But it would still be a big change, because at the deepest level, it would require FSF to see source code as just one of many requirements for freedom, rather than “the point of free software”.

At the same time, OSFeels is clearly filled with people who see the world through a broad, thoughtful ethical lens. It is a sad sign, both for FSF and how it is perceived, that such a group uses the deliberately apolitical language of openness rather than the language of a (hopefully) aligned ethical movement — free software. I’ll look forward to the day (maybe FSF’s 45th (or 31st!) birthday) that both groups can speak and work together about their real shared concern: software that liberates people. I’d certainly have no conflicted feelings about signing up for a conference on that :)

Wikimania 2015 - random thoughts and observations

Wed, 22 Jul 2015 00:00:00 GMT

Random thoughts from Wikimania, 2015 edition (2013, 2014):

“Wikimania 2015 Reception at Laboratorio Arte Alameda - 02” by Jarek Tuszynski, under CC BY 4.0

Dancing: After five Wikimedia events (not counting WMF all-hands) I was finally dragged onto the dance floor on the last night. I’ll never be Garfield, but I had fun anyway. The amazing setting did not hurt.
Our hosts: The conference was excellently organized and run. I’ve never had Mexico City high on my list of “places I must see” but it moved up many spots after this trip.
First timers: I always enjoy talking to people who have never been to Wikimania before. They almost always seem to have enjoyed it, but of course the ones I talk to are typically the ones who are more outgoing and better equipped to enjoy things. I do hope we’re also being welcome to people who don’t already know folks, or who aren’t as outgoing.
Luis von Ahn: Good to chat briefly with my long-ago classmate. I thought the Q&A section of his talk was one of the best I’ve seen in a long time. There were both good questions and interesting answers, which is more rare than it should be.

“More than half of @duolingo’s engineers work on figuring how to engage our users.” -@LuisvonAhn #Wikimania2015 pic.twitter.com/RU3nCqHoDY

— Moiz Syed (@MoizSyed) July 18, 2015

Keynotes: I’d love to have one keynote slot each year for a contributor to talk about their work within the movement. Finding the right person would be a challenge, of course, as could language barriers, but it seems like it should be doable.
US English: I was corrected on my Americanisms and the occasional complexity of my sentence structure. It was a good reminder that even for fairly sophisticated speakers of English as a second language, California-English is not terribly clear. This is especially true when spoken. Verbose slides can help, which is a shame, since I usually prefer minimal slides. I will try to work on that in the future, and see how we can help other WMFers do the same.
Mobile: Really hope someday we can figure out how to make the schedule legible on a mobile device :) Good reminder we’ve got a long way to go there.
Community engagement: I enjoyed my departments “engage with” session, but I think next year we need to make it more interactive—probably with something like an introduction/overview followed by a World Cafe-style discussion. One thing we did right was to take questions on written cards. This helped indicate what the most important topics were (when questions were repeated), avoided the problem of lecture-by-question, and opened the floor to people who might otherwise be intimidated because of language barriers or personality. Our booth was also excellent and I’m excited to see some of the stories that came out of it.
Technology and culture: After talking about how we’d used cards to change the atmosphere of a talk, someone deliberately provoked me: shouldn’t we address on-wiki cultural issues the same way, by changing the “technology” used for discussion? I agree that technology can help improve things, and we should think about it more than we do (e.g.) but ultimately it can only be part of the solution - our most difficult problems will definitely require work on culture as well as interfaces. (Surprisingly, my 2009 post on this topic holds up pretty well.)
Who is this for? I’ve always felt there was some tension around whether the conference is for “us” or for the public, but never had language for it. An older gentleman who I spoke with for a while finally gave me the right term: is it an annual meeting or is it a public conference? Nothing I saw here changed my position, which is that it is more annual meeting than public conference, at least until we get much better at turning new users into long-term users.
Esino Lario looks like it will be a lot of fun. I strongly support the organizing committee’s decision to focus less on brief talks and more on longer, more interactive conversations. That is clearly the best use of our limited time together. I’m also excited that they’re looking into blind submissions (which I suggested in my Wikimania post from last year).
Being an exec: I saw exactly one regular talk that was not by my department, though I did have lots and lots of conversations. I’m still not sure how I feel about this tradeoff, but I know it will become even harder if we truly do transition to a model with more workshops/conversations and fewer lectures, since those will be both more valuable and more time-consuming/less flexible.
Some day: I wrote most of this post in the Mexico City airport, and saw that there are flights from there to La Habana. I hope someday we can do a Wikimania there.

What tools are changing our world next?

Sat, 06 Jun 2015 00:00:00 GMT

Quick brain dump after a bike ride home: free software took a huge leap in the late 90s and early 00s in large part because of non-ideological advantages that the rest of the world is now competing with or surpassing:

HDR automatically created by Google Photos from my old pictures of Muir Woods. Not perfect, but better than I ever bothered to do!

Collaboration tools: Because we got to the ‘net first, our tools for collaborating with each other were simply better than what proprietary developers were doing: cvs, mailman, wiki, etc., were all better than the silo’d old-school tools. Modern best-of-breed collaboration tools have all learned from what we did and added proprietary sauce on top: github, slack, Google Docs, etc. So our tools that are now (at best) as productive as our proprietary counterparts, and sometimes less productive but ideologically agreeable.
Release processes: “Release early/release often” made us better partners for our users. We’re now actively behind here: compare how often a mobile app or web user gets updates, exactly as the author intended, relative to a user of a modern Linux distro.
Zero cost: We did things for no (direct) cost by subsidizing our work through college, startups, or consulting gigs; now everyone has a subsidize-by-selling-something-else model (usually advertising, though sometimes freemium). Again, advantage (mostly?) lost.
Knowing our users: We knew a lot about our users, because we were our biggest users, and we talked to other users a lot; this was more effective than what passed for software design in the late 90s. This has been eclipsed by extensive a/b testing throughout the industry, and (to a lesser extent) by more extensive usage of direct user testing and design-thinking.

None of these are terribly original observations - all of these have been remarked on before. But after playing some with Google Photos this weekend, I’m ready to add another one to the list:

“big data”: It didn’t matter that neither libre nor proprietary developers had their user’s data, because no one could do much that was useful with it. Now, [Gmail’s spam filtering is better than SpamAssassin precisely because of all the data they have.](http://Both of these advantages have disappeared: the best-of-breed collaboration tools are all now proprietary (github, slack, etc.), and) Google Photos is nearly magical, again because they’ve processed literally billions of photos. That’s going to be difficult (impossible?) for pure peer production models to match. (I didn’t list machine learning because the techniques there can literally be done by summer interns - the blocker is the training data, not the processes.)

Worth asking what your project is doing that could be radically changed if your competitors get access to new technology. For example, for Wikipedia:

Collaborating: Wiki was best-of-breed (or close); it isn’t anymore. Visual Editor helps get editing back to par, but the social aspect of collaboration is still lacking relative to the expectations of many users.
Knowledge creation: big groups of humans, working together wiki-style, is the state of the art for creating useful, non-BS knowledge at scale. With the aforementioned machine learning, I suspect this will no longer the case in a (growing) number of domains.

I’m sure there are others…

Free-riding and copyleft in cultural commons like Flickr

Tue, 02 Dec 2014 00:00:00 GMT

Flickr recently started selling prints of Creative Commons Attribution-Share Alike photos without sharing any of the revenue with the original photographers. When people were surprised, Flickr said “if you don’t want commercial use, switch the photo to CC non-commercial”.

This seems to have mostly caused two reactions:

“This is horrible! Creative Commons is horrible!”
“Commercial reuse is explicitly part of the license; I don’t understand the anger.”

I think it makes sense to examine some of the assumptions those users (and many license authors) may have had, and what that tells us about license choice and design going forward.

Free ride!!, by Dhinakaran Gajavarathan, under CC BY 2.0

As I’ve explained before here, a major reason why people choose copyleft/share-alike licenses is to prevent free rider problems: they are OK with you using their thing, but they want the license to nudge (or push) you in the direction of sharing back/collaborating with them in the future. To quote Elinor Ostrom, who won a Nobel for her research on how commons are managed in the wild, “[i]n all recorded, long surviving, self-organized resource governance regimes, participants invest resources in monitoring the actions of each other so as to reduce the probability of free riding.” (emphasis added)

Copyleft is one of our mechanisms for this in our commons, but it isn’t enough. I think experience in free/open/libre software shows that free rider problems are best prevented when three conditions are present:

The work being created is genuinely collaborative — i.e., many authors who contribute similarly to the work. This reduces the cost of free riding to any one author. It also makes it more understandable/tolerable when a re-user fails to compensate specific authors, since there is so much practical difficulty for even a good-faith reuser to evaluate who should get paid and contact them.
There is a long-term cost to not contributing back to the parent project. In the case of Linux and many large software projects, this long-term cost is about maintenance and security: if you’re not working with upstream, you’re not going to get the benefit of new fixes, and will pay a cost in backporting security fixes.
The license triggers share-alike obligations for common use cases. The copyleft doesn’t need to perfectly capture all use cases. But if at least some high-profile use cases require sharing back, that helps discipline other users by making them think more carefully about their obligations (both legal and social/organizational).

Alternately, you may be able to avoid damage from free rider problems by taking the Apache/BSD approach: genuinely, deeply educating contributors, before they contribute, that they should only contribute if they are OK with a high level of free riding. It is hard to see how this can work in a situation like Flickr’s, because contributors don’t have extensive community contact. ((It is open to discussion, I think, whether this works in Wikimedia Commons, and how it can be scaled as Commons grows.))

The most important takeaway from this list is that if you want to prevent free riding in a community-production project, the license can’t do all the work itself — other frictions that somewhat slow reuse should be present. (In fact, my first draft of this list didn’t mention the license at all — just the first two points.)

#Flickr is practically designed for free riding

Flickr fails on all the points I’ve listed above — it has no frictions that might discourage free riding.

The community doesn’t collaborate on the works. This makes the selling a deeply personal, “expensive” thing for any author who sees their photo for sale. It is very easy for each of them to find their specific materials being reused, and see a specific price being charged by Yahoo that they’d like to see a slice of.
There is no cost to re-users who don’t contribute back to the author—the photo will never develop security problems, or get less useful with time.
The share-alike doesn’t kick in for virtually any reuses, encouraging Yahoo to look at the relationship as a purely legal one, and encouraging them to forget about the other relationships they have with Flickr users.
There is no community education about the expectations for commercial use, so many people don’t fully understand the licenses they’re using.

#So what does this mean?

This has already gone on too long, but a quick thought: what this suggests is that if you have a community dedicated to creating a cultural commons, it needs some features that discourage free riding — and critically, mere copyleft licensing might not be good enough, because of the nature of most production of commons of cultural works. In Flickr’s case, maybe this should simply have included not doing this, or making some sort of financial arrangement despite what was legally permissible; for other communities and other circumstances other solutions to the free-rider problem may make sense too.

And I think this argues for consideration of non-commercial licenses in some circumstances as well. This doesn’t make non-commercial licenses more palatable, but since commercial free riding is typically people’s biggest concern, and other tools may not be available, it is entirely possible it should be considered more seriously than free and open source software dogma might have you believe.

Understanding Wikimedia, or, the Heavy Metal Umlaut, one decade on

Tue, 28 Oct 2014 00:00:00 GMT

It has been nearly a full decade since Jon Udell’s classic screencast about Wikipedia’s article on the Heavy Metal Umlaut (current text; Jan. 2005). In this post, written for Paul Jones’ “living and working online” class, I’d like to use the last decade’s changes to the article to illustrate some points about the modern Wikipedia. ((I still haven’t found a decent screencasting tool that I like, so I won’t do proper homage to the original—sorry Jon!))

#Measuring change

At the end of 2004, the article had been edited 294 times. As we approach the end of 2014, it has now been edited 1,908 times by 1,174 editors. ((Numbers courtesy X’s edit counter.))

This graph shows the number of edits by year - the blue bar is the overall number of edits in each year; the dotted line is the overall length of the article (which has remained roughly constant since a large pruning of band examples in 2007).

The dropoff in edits is not unusual — it reflects both a mature article (there isn’t that much more you can write about metal umlauts!) and an overall slowing in edits in English Wikipedia (from a peak of about 300,000 edits/day in 2007 to about 150,000 edits/day now). ((It is important, when looking at Wikipedia statistics, to distinguish between stats about Wikipedia in English, and Wikipedia globally — numbers and trends will differ vastly between the two.))

The overall edit count — 2000 edits, 1000 editors — can be hard to get your head around, especially if you write for a living. Implications include:

Style is hard. Getting this many authors on the same page, stylistically, is extremely difficult, and it shows in inconsistencies small and large. If not for the deeply acculturated Encyclopedic Style we all have in our heads, I suspect it would be borderline impossible.
Most people are good, most of the time. Something like 3% of edits are “reverted”; i.e., about 97% of edits are positive steps forward in some way, shape, or form, even if imperfect. This is, I think, perhaps the single most amazing fact to come out of the Wikimedia experiment. (We reflect and protect this behavior in one of our guidelines, where we recommend that all editors Assume Good Faith.)

#The name change, tools, and norms

In December 2008, the article lost the “heavy” from its name and became, simply, “metal umlaut” (explanation, aka “edit summary”, highlighted in yellow):

A few take aways:

Talk pages: The screencast explained one key tool for understanding a Wikipedia article - the page history. This edit summary makes reference to another key tool - the talk page. Every Wikipedia article has a talk page, where people can discuss the article, propose changes, etc.. In this case, this user discussed the change (in November) and then made the change in December. If you’re reporting on an article for some reason, make sure to dig into the talk page to fully understand what is going on.
**Sources:**The user justifies the name change by reference to sources. You’ll find little reference to them in 2005, but by 2008, finding an old source using a different term is now sufficient rationale to rename the entire page. Relatedly…
**Footnotes:**In 2008, there was talk of sources, but still no footnotes. (Compare the story about Motley Crue in Germany in 2005 and now.) The emphasis on foonotes (and the ubiquitous “citation needed”) was still a growing thing. In fact, when Jon did his screencast in January 2005, the standardized/much-parodied way of saying “citation needed” did not yet exist, and would not until June of that year! (It is now used in a quarter of a million English Wikipedia pages.) Of course, the requirement to add footnotes (and our baroque way of doing so) may also explain some of the decline in editing in the graphs above.

#Images, risk aversion, and boldness

Another highly visible change is to the Motörhead art, which was removed in November 2011 and replaced with a Mötley Crüe image in September 2013. The addition and removal present quite a contrast. The removal is explained like this:

remove File:Motorhead.jpg; no fair use rationale provided on the image description page as described at WP:NFCC content criteria 10c

This is clear as mud, combining legal issues (“no fair use rationale”) with Wikipedian jargon (“WP:NFCC content criteria 10c”). To translate it: the editor felt that the “non-free content” rules (abbreviated WP:NFCC) prohibited copyright content unless there was a strong explanation of why the content might be permitted under fair use.

This is both great, and sad: as a lawyer, I’m very happy that the community is pre-emptively trying to Do The Right Thing and take down content that could cause problems in the future. At the same time, it is sad that the editors involved did not try to provide the missing fair use rationale themselves. Worse, a rationale was added to the image shortly thereafter, but the image was never added back to the article.

So where did the new image come from? Simply:

boldly adding image to lead

“boldly” here links to another core guideline: “be bold”. Because we can always undo mistakes, as the original screencast showed about spam, it is best, on balance, to move forward quickly. This is in stark contrast to traditional publishing, which has to live with printed mistakes for a long time and so places heavy emphasis on Getting It Right The First Time.

#In brief

There are a few other changes worth pointing out, even in a necessarily brief summary like this one.

Wikipedia as a reference: At one point, in discussing whether or not to use the phrase “heavy metal umlaut” instead of “metal umlaut”, an editor makes the point that Google has many search results for “heavy metal umlaut”, and another editor points out that all of those search results refer to Wikipedia. In other words, unlike in 2005, Wikipedia is now so popular, and so widely referenced, that editors must be careful not to (indirectly) be citing Wikipedia itself as the source of a fact. This is a good problem to have—but a challenge for careful authors nevertheless.
Bots: Careful readers of the revision history will note edits by “ClueBot NG”. Vandalism of the sort noted by Jon Udell has not gone away, but it now is often removed even faster with the aid of software tools developed by volunteers. This is part of a general trend towards software-assisted editing of the encyclopedia.
Translations: The left hand side of the article shows that it is in something like 14 languages, including a few that use umlauts unironically. This is not useful for this article, but for more important topics, it is always interesting to compare the perspective of authors in different languages.

#Other thoughts?

I look forward to discussing all of these with the class, and to any suggestions from more experienced Wikipedians for other lessons from this article that could be showcased, either in the class or (if I ever get to it) in a one-decade anniversary screencast. :)

My Wikimania 2014 talks

Thu, 04 Sep 2014 00:00:00 GMT

Primarily what I did during Wikimania was chew on pens.

Discussing Fluid Lobbying at Wikimania 2014, by Sebastiaan ter Burg, under CC BY 2.0

However, I also gave some talks.

The first one was on Creative Commons 4.0, with Kat Walsh. While targeted at Wikimedians, this may be of interest to others who want to learn about CC 4.0 as well.

[viewerjs /blog/wp-content/uploads/2014/09/Creative-Commons-4.0-Wikimania-2014-1.pdf]

Second one was on Open Source Hygiene, with Stephen LaPorte. This one is again Wikimedia-specific (and I’m afraid less useful without the speaker notes) but may be of interest to open source developers more generally.

[viewerjs /blog/wp-content/uploads/2014/09/Open-Source-Hygiene-1.pdf]

The final one was on sharing; video is below (and I’ll share the slides once I figure out how best to embed the notes, which are pretty key to understanding the slides):

Wikimania 2014 Notes - very miscellaneous

Tue, 02 Sep 2014 00:00:00 GMT

A collection of semi-random notes from Wikimania London, published very late:

Gruppenfoto Wikimania 2014 London, by Ralf Roletschek, under CC BY-SA 3.0 Austria

#The conference generally

**Tone:**Overall tone of the conference was very positive. It is possibly just small sample size—any one person can only talk to a small number of the few thousand at the conference—but seemed more upbeat/positive than last year.
Tone, 2: The one recurring negative theme was concern about community tone, from many angles, including Jimmy. I’m very curious to see how that plays out. I agree, of course, and will do my part, both at WMF and when I’m editing. But that sort of social/cultural change is very hard.
Speaker diversity: Heard a few complaints about gender balance and other diversity issues in the speaker lineup, and saw a lot of the same (wonderful!) faces as last year. I’m wondering if there are procedural changes (like maybe blind submissions, or other things from this list) might bring some new blood and improve diversity.
“Outsiders”: The conference seemed to have better representation than last year from “outside” our core community. In particular, it was great for me to see huge swathes of the open content/open access movements represented, as well as other free software projects like Mozilla. We should be a movement that works well with others, and Wikimania can/should be a key part of that, so this was a big plus for me.
Types of talks: It would be interesting to see what the balance was of talks (and submissions) between “us learning about the world” (e.g., me talking about CC), “us learning about ourselves” (e.g., the self-research tracks), and “the world learning about us” (e.g., aimed at outsiders). Not sure there is any particular balance we should have between the three of them, but it might be revealing to see what the current balance is.
Less speaking, more conversing: Next year I will probably propose mostly (only?) panels and workshops, and I wonder if I can convince others to do the same. I can do a talk+slides and stream it at any time; what I can only do in person is have deeper, higher-bandwidth conversations.
Physical space and production values: The hackathon space was amazingly fun for me, though I got the sense not everyone agreed. The production values (and the rest of the space) for the conference were very good. I’m torn on whether or not the high production values are a plus for us, honestly. They raise the bar for participation (bad); make the whole event feel somewhat… un-community-ish(?); but they also make us much more accessible to people who aren’t yet ready for the full-on, super-intense Wikimedian Experience.

#The conference for projects I work on

LCA: Legal/Community Affairs was pretty awesome on many fronts—our talks, our work behind the scenes, our dealing with both the expected and unexpected, etc. Deeply proud to be part of this dedicated, creative team. Also very appreciative for everyone who thanked us—it means a lot when we hear from people we’ve helped.
Maps: Great seeing so much interest in Open Street Map. Had a really enjoyable time at their 10th birthday meetup; was too bad I had to leave early. Now have a better understanding of some of the technical issues after a chat with Kolossos and Katie. Also had just plain fun geeking out about “hard choices” like map boundaries—I find how communities make decisions about problems like that fascinating.
Software licensing: My licensing talk with Stephen went well, but probably should have been structured as part of the hackathon rather than for more general audiences. Ultimately this will only work out if engineering (WMF and volunteer) is on board, and will work best if engineering leads. (The question asked by Mako afterwards has already led to patches, which is cool.)
Creative Commons: My CC talk with Kat went well, and got some good questions. Ultimately the rubber will meet the road when the translations are out and we start the discussion with the full community. Also great meeting User:Multichill; looking forward to working on license templates with him and May from design.
Metadata: The multimedia metadata+licensing work is going to be really challenging, but very interesting and ultimately very empowering for everyone who wants to work with the material on commons. Look forward to working with a large/growing number of people on this project.
Advocacy: Advocacy panel was challenging, in a good way. A variety of good, useful suggestions; but more than anything else, I took away that we should probably talk about how we talk when subjects are hard, and consensus may be difficult to reach. Examples would include when there is a short timeline for a letter, or when topics are deeply controversial for good, honest reasons.

#The conference for me

Lesson (1): Learned a lesson: never schedule a meeting for the day after Wikimania. Odds of being productive are basically zero, though we did get at least some things done.
Lesson (2): I badly overbooked myself; it hurt my ability to enjoy the conference and meet everyone I wanted to meet. Next year I’ll try to be more focused in my commitments so I can benefit more from spontaneity, and get to see some slightly less day-job-related (but enjoyable or inspirational) talks/presentations.
Research: Love that there is so much good/interesting research going on, and do deeply think that it is important to understand it so that I can apply it to my work. Did not get to see very much of it, though :/
Arguing with love: As tweeted about by Phoebe, one of the highlights was a vigorous discussion (violent agreement :) with Mako over dinner about the four freedoms and how they relate to just/empowering software more broadly. Also started a good, vigorous discussion with SJ about communication and product quality, but we sadly never got to finish that.
Recharging: Just like GUADEC in my previous life, I find these exhausting but also ultimately exhilarating and recharging. Can’t wait to get to Mexico City!

#Misc.

London: I really enjoy London—the mix of history and modernity is amazing. Bonus: I think the beer scene has really improved since the last time I was there.
Movies: I hardly ever watch movies anymore, even though I love them. Knocked out 10 movies in the 22 hours in flight. On the way to London:
- Grand Hotel Budapest (the same movie as every other one of his movies, which is enjoyable)
- Jodorowsky’s Dune (awesome if you’re into scifi)
- Anchorman (finally)
- Stranger than Fiction (enjoyed it, but Adaptation was better)
- Captain America, Winter Soldier (not bad?)
On the way back:
- All About Eve (finally - completely compelling)
- Appleseed:Alpha (weird; the awful dialogue and wooden “faces” of computer animated actors clashed particularly badly with the clasically great dialogue and acting of All About Eve)
- Mary Poppins (having just seen London; may explain my love of magico-realism?)
- The Philadelphia Story (great cast, didn’t engage me otherwise)
- Her (very good)

Slide embedding from Commons

Tue, 22 Jul 2014 00:00:00 GMT

A friend of a friend asked this morning:

Hmmm trying to upload a CC0 public domain presentation from #OKFest14 by @punkish and @SlideShare don’t have public domain license option :(

— Jenny Molloy (@jenny_molloy) July 22, 2014

I suggested Wikimedia Commons, but it turns out she wanted something like Slideshare’s embedding. So here’s a test of how that works (timely, since soon Wikimanians will be uploading dozens of slide decks!)

This is what happens when you use the default Commons “Use this file on the web -> HTML/BBCode” option on a slide deck pdf:

Not the worst outcome - clicking gets you to a clickable deck. No controls inline in the embed, though. And importantly nothing to show that it is clickable :/

Compare with the same deck, uploaded to Slideshare:

Some work to be done if we want to encourage people to upload to Commons and share later.

Update: a commenter points me at viewer.js, which conveniently includes a wordpress plugin! The plugin is slightly busted (I had to move some files around to get it to work in my install) but here’s a demo:

Update2: bugs are fixed upstream and in an upcoming 0.5.2 release of the plugin. Hooray!

[viewerjs /blog/wp-content/uploads/2014/07/Wikimedia_Legal_overview_2014-03-19.pdf]

Designers and Creative Commons: Learning Through Wikipedia Redesigns

Tue, 15 Jul 2014 00:00:00 GMT

tl;dr: Wikipedia redesigns mostly ignore attribution of Wikipedia authors, and none approach the problem creatively. This probably says as much or more about Creative Commons as it does about the designers.

disclaimer-y thing: so far, this is for fun, not work; haven’t discussed it at the office and have no particular plans to. Yes, I have a weird idea of fun.

A mild refresh from interfacesketch.com.

It is no longer surprising when a new day brings a new redesign of Wikipedia. After seeing one this weekend with no licensing information, I started going back through seventeen of them (most of the ones listed on-wiki) to see how (if at all) they dealt with licensing, attribution, and history. Here’s a summary of what I found.

#Completely missing

Perhaps not surprisingly, many designers completely remove attribution (i.e., history) and licensing information in their designs. Seven of the seventeen redesigns I surveyed were in this camp. Some of them were in response to a particular, non-licensing-related challenge, so it may not be fair to lump them into this camp, but good designers still deal with real design constraints, and licensing is one of them.

#History survives - sometimes

The history link is important, because it is how we honor the people who wrote the article, and comply with our attribution obligations. Five of the seventeen redesigns lacked any licensing information, but at least kept a history link.

Several of this group included some legal information, such as links to the privacy policy, or in one case, to the Wikimedia Foundation trademark page. This suggests that our current licensing information may be presented in a worse way than some of our other legal information, since it seems to be getting cut out even by designers who are tolerant of some of our other legalese?

#Same old, same old

Four of the seventeen designs keep the same old legalese, though one fails to comply by making it impossible to get to the attribution (history) page. Nothing wrong with keeping the existing language, but it could reflect a sad conclusion that licensing information isn’t worth the attention of designers; or (more generously) that they don’t understand the meaning/utility of the language, so it just gets cargo-culted around. (Credit to Hamza Erdoglu , who was the only mockup designer who specifically went out of his way to show the page footer in one of his mockups.)

#A winner, sort of!

Of the seventeen sites I looked at, exactly one did something different: Wikiwand. It is pretty minimal, but it is *something.*The one thing: as part of the redesign, it adds a big header/splash image to the page, and then adds a new credit specifically for the author of the header/splash image down at the bottom of the page with the standard licensing information. Arguably it isn’t that creative, just complying with their obligations from adding a new image, but it’s at least a sign that not everyone is asleep at the wheel.

#Observations

This is surely not a large or representative sample, so all my observations from this exercise should be taken with a grain of salt. (They’re also speculative since I haven’t talked to the designers.) That said, some thoughts besides the ones above:

Virtually all of the designers who wrote about why they did the redesign mentioned our public-edit-nature as one of their motivators. Given that, I expected history to be more frequently/consistently addressed. Not clear whether this should be chalked up to designers not caring about attribution, or the attribution role of history being very unclear to anyone who isn’t an expect. I suspect the latter.
It was evident that some of these designers had spent a great deal of time thinking about the site, and yet were unaware of licensing/attribution. This suggests that people who spend less time with the site (i.e., 99.9% of readers) are going to be even more ignorant.
None of the designers felt attribution and licensing was even important enough to experiment on or mention in their writeups. As I said above, this is understandable but sort of sad, and I wonder how to change it.

Postscript, added next morning:

I think it’s important to stress that I didn’t link to the individual sites here, because I don’t want to call out particular designers or focus on their failures/oversights. The important (and as I said, sad) thing to me is that designers are, historically, a culture concerned with licensing and attribution. If we can’t interest them in applying their design talents to our problem, in the context of the world’s most famously collaborative project, we (lawyers and other Commoners) need to look hard at what we’re doing, and how we can educate and engage designers to be on our side.

I should also add that the WMF design team has been a real pleasure to work with on this problem, and I look forward to doing more of it. Some stuff still hasn’t made it off the drawing board, but they’re engaged and interested in this challenge. Here is one example.

Democracy and Software Freedom

Sat, 21 Jun 2014 00:00:00 GMT

As part of a broader discussion of democracy as the basis for a just socio-economic system, Séverine Deneulin summarizes Robert Dahl’s Democracy, which says democracy requires five qualities:

First, democracy requires effective participation. Before a policy is adopted, all members must have equal and effective opportunities for making their views known to others as to what the policy should be.

Second, it is based on voting equality. When the moment arrives for the final policy decision to be made, every member should have an equal and effective opportunity to vote, and all votes should be counted as equal.

Third, it rests on ‘enlightened understanding’. Within reasonable limits, each member should have equal and effective opportunities for learning about alternative policies and their likely consequences.

Fourth, each member should have control of the agenda, that is, members should have the exclusive opportunity to decide upon the agenda and change it.

Fifth, democratic decision-making should include all adults. All (or at least most) adult permanent residents should have the full rights of citizens that are implied by the first four criteria.

From “An Introduction to the Human Development and Capability Approach“, Ch. 8 – “Democracy and Political Participation”.

“Poll worker explains voting process in southern Sudan referendum” by USAID Africa Bureau via Wikimedia Commons.

It is striking that, despite talking a lot about freedom, and often being interested in the question of who controls power, these five criteria might as well be (Athenian) Greek to most free software communities and participants- the question of liberty begins and ends with source code, and has nothing to say about organizational structure and decision-making – critical questions serious philosophers always address.

Our licensing, of course, means that in theory points #4 and #5 are satisfied, but saying “you can submit a patch” is, for most people, roughly as satisfying as saying “you could buy a TV ad” to an American voter concerned about the impact of wealth on our elections. Yes, we all have the theoretical option to buy a TV ad/edit our code, but for most voters/users of software that option will always remain theoretical. We’re probably even further from satisfying #1, #2, and #3 in most projects, though one could see the Ada Initiative and GNOME OPW as attempts to deal with some aspects of #1, #3, and #4

This is not to say that voting is the right way to make decisions about software development, but simply to ask: if we don’t have these checks in place, what are we doing instead? And are those alternatives good enough for us to have certainty that we’re actually enhancing freedom?

Exploring the legal issues around open data and open hardware

Mon, 19 May 2014 00:00:00 GMT

Originally published at opensource.com.

Drafting and using open licenses for data and hardware presents both familiar old challenges (like license proliferation) and new challenges (like less developed legal frameworks and different production models). About thirty people working in these areas recently gathered (under the umbrella of the FSF-E’s “European Legal Network”) to discuss the latest work in these areas under the Chatham House Rules. This article will summarize what the group learned, and, I hope, stimulate discussion to improve the state of licensing in those areas.

#Similar conditions

The legal issues around open data and open hardware have a lot in common with the legal issues around open software. This shouldn’t be surprising, because some of the technological and economic foundations are the same. These include:

Increased usefulness of information

In our dim, dark past, having information often was not very helpful for individuals or small organizations—they often lacked key skills or tools to create valuable things out of that information. In open software, this changed years ago with compilers. More recently, in hardware, 3D printing and easier access to contract manufacturers have changed the game; and in data, increased number crunching capabilities, open tools like R (programming language), and increased access to big open data sets like Wikidata and Open Street Map have opened new doors for a very wide variety of data geeks.

Collaboration happens outside

In the same dim past, collaboration was something that happened primarily within the walls of large organizations. As readers of Opensource.com know quite well, improved communication tools make it possible to collaborate publicly and across organizations. This increased ease of collaboration on any topic—software, hardware design, and data included—drives creativity, production, and (unfortunately) legal concerns. It has also broadened who participates—smaller and smaller organizations, as well as skilled individuals, with a variety of different motivations, have become involved in all of these areas. This is as true for data and hardware as it is for open software.

#Different conditions

Despite the key similarities, there are a variety of differences between software, data, and hardware. These practical differences, in turn, drive legal differences:

Ease of turning “source” information into a useful thing

While it has gotten much easier in many areas to turn “source” information (data, a hardware design, source code) into something useful, this change has not happened uniformly. For very basic physical things, 3D printing has dropped the costs of customization down dramatically, and may do so even more—one participant mentioned that in Japan, 3D printing stores are now a real thing! At the same time, certain basic electronics aren’t exactly easy to create and customize, but it is much easier to find manufacturers and experiment with components than it ever has been before (as my friend Richard Hughes has done). But for CPUs of any reasonable complexity/power, billion-dollar fabs for manufacturing are still a prerequisite. (Eli Greenbaum in particular made the point about ease of compilation during our event, and has written about related issues in 3D printing.)

Fragmented roles

In open software, most organizations that design software also compile that software, but that’s not always the case. Two open hardware organizations in attendance create extremely detailed hardware specifications, but outsource the actual fabrication of the hardware. This is different from both software and from a lot of traditional hardware development. On the flip side, many open data providers deliberately publish data that by itself is not very useful, with the hope that some outside innovator will find it useful and integrate it into something else. This is again somewhat different from software, where software tends to be published only when it is useful in the form it is published in (albeit sometimes to a small number of people).

Diversity of technology

In data, standards tend to be pretty well developed, but in “hardware” the technology is all over the place. There are few standards for design data interchange, and people are doing “open hardware” in such a broad variety of technical domains that it is hard to say that there is one such thing as “open hardware.” It may be often more accurate to speak of open mechanical engineering, open chip design, open connection standards, etc. Lumping all these different things together under the “open hardware” moniker, when they have different technologies, different economics, different motives for participation, etc., may distort our legal thinking.

Maturity of the legal systems

Despite its flaws, copyright law is relatively well-developed and relatively consistent, having been developed through international treaties for 100 years. In contrast, other legal rights that apply to data and hardware are often not consistently protected, and often are relatively “new” legally speaking—so they are difficult to interpret. For example, one speaker pointed out that in the U.K., there are four different design rights that might apply to open hardware designs. Database rights are newer, EU-only, and elaborated in only a handful of cases; and mask rights also apply to hardware and are not consistent. In each of these cases, the fact that the laws were not designed with “open” in mind leads to different, often conflicting problems for open lawyers.

#Old problems

Not surprisingly, given that so many issues (and many of the lawyers!) are the same, some old concerns came up repeatedly throughout the day. A few in particular were:

Proliferation

People are trying to address new problems, so they are writing new licenses and new agreements. This is natural and healthy, as it was early on for open software. The question is whether or not we end up with a healthy diversity of licenses addressing real problems; or whether we get an explosion of vanity licenses, or licenses that exist only to address problems “discovered” by non-experts that experts agree are not actually an issue. There were suggestions during the day that hardware is probably still in the “healthy innovation” phase, given the complexity of issues facing the hardware space, but that data may already be into proliferation.

Compatibility

Given that one of the key purposes of open licensing is reuse and recombination of materials, compatibility between licenses is important. One theme from the hardware portion of the event is that hardware is so diverse (in terms of both design and manufacture) that compatibility may be less important, and that community norms (i.e., everyone who works in technology X agrees on using license Y) may be able to practically replace formal legal theorizing about compatibility. On the flip side, in data, it may be even more important than in software, and that problems may already be coming up in practice.

Third-party rights

The core open software legal tools are typically only effective at organizing rights held by participants; rights held by third parties have always been tricky. In open software, these third-party rights are typically patents. In data and hardware, there will also be design rights, privacy rights, and others; all will potentially require solutions that live partially outside of the tools used by participants, like licenses and certificates of origin.

Freedom and openness

It was notable during the event that “free” hardware and data were hardly mentioned at all. This is partially because the event tended to attract lawyers on the pragmatic end of the spectrum, but I think also in part because the case for liberty in those areas has not been forcefully and consistently made in the way that FSF and RMS have consistently advanced those issues in software. Nevertheless, the compromises between principle and pragmatism were often lurking right below the surface, and it is inevitable that this will cause tension down the road, particularly in projects where government and educational interests become major participants (as they may in data).

#Different problems

Open source software licensing is now a relatively robust and mature area of the law; it was clear from the event that this is not yet the case for open data and hardware licensing. Some of that is merely because time has passed and expertise has been developed, but after the event I think there are a few key new problems that lawyers in this area will need to wrestle with:

Heterogeneity

At the end of the day, despite the many differences, the largest software companies and the loneliest hackers are fundamentally both doing the same thing—software. The big company may use or ship the lone hacker’s code, and the lone hacker may rely on libraries or APIs provided by the big company. In part because of this homogeneity, the instincts of open source license lawyers is to use “one size fits all” legal tools. In hardware, one of my key takeaways from the event is that there are so many different things going on—different technologies, different motivations for creation—on that these instincts to simplify and unify may lead us astray. We don’t want to try to fit round mechanical pegs into square chip design holes, for example. In data, I suspect extremely generalized, broad licenses are still the right instinct, but we do have to be careful to test that assumption and not take it for granted.

Different legal regimes

Experienced open source lawyers have a legal toolkit that in large part depends on well-understood features of copyright law. Our temptation will be to use those same tools in data and hardware, but it was clear after the event that this instinct will sometimes lead us into mistakes. In some cases, we may be able to borrow from other areas of law—for example, one presenter spoke of using a patent/standards approach for certain classes of hardware; but in other areas (particularly databases), the body of law may be so weakly developed that this is difficult to do, or may have many conflicting requirements and obligations that dealing with them will require more nuance and complexity than is typically possible in standardized, easy-to-understand licenses. These problems also increase the temptation to use contract instead of license law—which is often problematic both legally and ethically.

Copyleft

Copyleft/share-alike is a frequent request from open communities, and again, lawyers have a specific set of tools that we’re comfortable using in this area. But these tools will have to be rethought in data and hardware. This is partially for the reasons listed above—the legal regimes of database rights and design rights give us fewer useful tools and terminology to implement a copyleft in those spaces, for example. But there are also different mechanisms and paths for collaboration in these spaces, which may make legally-enforced copyleft a poor mechanism for encouraging sharing in those places.

#Next steps

Open lawyering, like open source development, thrives best when it communicates. In keeping with this tradition, the group agreed that the most important next steps are about improving communication: making sure that we talk with each other about new challenges, new models, and new licenses. Possible forums for this communication include the European Legal Network and (for open data) the Open Definition’s discussion list. If you’re interested in joining a list (or hopefully attending the next face-to-face meeting), drop me a line! I expect to see a lot of other activity in this space in the near future—open lawyers are lucky to live in interesting, if challenging, times.

I am the CADT; and advice on NEEDINFOing old bugs en masse

Fri, 28 Mar 2014 00:00:00 GMT

[Attention conservation notice: probably not of interest to lawyers;* this is about my previous life in software development.]*

Bugsquad barnstar, under MPL 1.1

Someone recently mentioned JWZ’s old post on the CADT (Cascade of Attention Deficit Teecnagers) development model, and that finally has pushed me to say:

I am the CADT.

I did the bug closure that triggered Jamie’s rant, and I wrote the text he quotes in his blog post. ((Both had help from others, but it was eventually my decision.))

Jamie got some things right, and some things wrong. The main thing he got right is that it is entirely possible to get into a cycle where instead of seriously trying to fix bugs, you just do a rewrite and cross your fingers that it fixes old bugs. And yes, this can particularly happen when you’re young and writing code for fun, where the joy of a from-scratch rewrite can overwhelm some of your other good senses. Jamie also got right that I communicated the issue pretty poorly. Consider this post a belated explanation (as well as a reference for the next time I see someone refer to CADT).

But that wasn’t what GNOME was doing when Jamie complained about it, and I doubt it is actually something that happens very often in any project large enough to have a large bug tracking system (BTS). So what were we doing?

First, as Brendan Eich has pointed out, sometimes a rewrite really is a good idea. GNOME 2 was such a rewrite - not only was a lot of the old code a hairy mess, we decided (correctly) to radically revise the old UI. So in that sense, the rewrite was not a “CADT” decision - the core bugs being fixed were the kinds of bugs that could only be fixed with massive, non-incremental change, rather than “hey, we got bored with the old code”. (Immediately afterwards, GNOME switched to time-based releases, and stuck to that schedule for the better part of a decade, which should be further proof we weren’t cascading.)

This meant there were several thousand old bugs that had been filed against UIs that no longer existed, and often against code that no longer existed or had been radically rewritten. So you’ve got new code and old bugs. What do you do with the old bugs?

It is important to know that open bugs in a BTS are not free. Old bugs impose a cost on developers, because when they are trying to search relevant bugs, old bugs can make it harder to find the things they really should be working on. In the best case, this slows them down; in the worst case, it drives them to use other tools to track the work they want to do - making the BTS next to useless. This violates rule #1 of a BTS: it must be useful for developers, or else it all falls apart.

So why did we choose to reduce these costs by closing bugs filed against the old codebase as NEEDINFO (and asking people to reopen if they were still relevant) instead of re-testing and re-triaging them one-by-one, as Jamie would have suggested? A few reasons:

number of triagers v. number of bugs: there were, at the time, around a half-dozen active bug volunteers, and thousands of pre-GNOME 2 bugs. It was simply unlikely that we’d ever be able to review all the old bugs even if we did nothing else.
focus on new bugs: new bugs are where triagers and developers are much more likely to be relevant - those bugs are against fresh code; the original filer is much more likely to respond to clarifying questions; etc. So all else being equal, time spent on new bugs was going to be much better for the software than time spent on old bugs.
steady flow of new bugs: if you’ve got a small number of new bugs coming in, perhaps you split your time - but we had no shortage of new bugs, nor of motivated bug reporters. So we may have paid some cost (by demotivating some reporters) but our scarce resource (developers) greatly appreciated it.
relative burden: with thousands of open bugs from thousands of reporters, it made sense to ask old them to test their bug against the new code. Reviewing their old bugs was a small burden for each of them, once we distributed it.

So when isn’t it a good idea to close ask for more information about old bugs?

Great at keeping old bugs triaged/relevant: If you have a very small number of old bugs that haven’t been touched in a long time, then they aren’t putting much burden on developers.
Slow code turnover: If your development process is such that it is highly likely that old bugs are still relevant (e.g., core has remained mostly untouched for many years, or effective use of TDD has kept the number of accidental new bugs low) this might not be a good idea.
No triggering event: In GNOME, there was a big event, plus a new influx of triagers, that made it make sense to do radical change. I wouldn’t recommend this “just because” - it should go hand-in-hand with other large changes, like a major release or important policy changes that will make future triaging more effective.

Relatedly, the team practices mailing list has been discussing good practices for migrating bug tracking systems in the past few days, which has been interesting to follow. I don’t take a strong position on where Wikimedia’s bugzilla falls on this point - Mediawiki has a fairly stable core, and the volume of incoming bugs may make triage of old bugs more plausible. But everyone running a very large bugzilla for an active project should remember that this is a part of their toolkit.

Summarizing "hacker legal education" crisply and cleanly

Tue, 19 Nov 2013 00:00:00 GMT

James Grimmelman is a better writer than I am. I already knew this, but in this commentary on Biella Coleman’s (excellent) Coding Freedom, he captures something I have struggled to express for years in two crisp, clean sentences:

Hacker legal education, with its roots in programming, is strong on formal precision and textual exegesis. But it is notably light on legal realism: coping with the open texture of the law and sorting persuasive from ineffective arguments.

This distinction is worth keeping in mind, for both sides of the professional/amateur legal discussion, to understand the relative strengths and weaknesses of their training and experience.

(Note that James says this, and I quote it, with all due love and respect, since we were both programmers before we were lawyers.)

Some quick notes on the occasion of my fourth OSI board face-to-face

Thu, 14 Nov 2013 00:00:00 GMT

The past two days were my fourth OSI face-to-face board meeting, this time about a block from my office in San Francisco.

Image by opensource.com under a CC BY-SA license.

Some brief thoughts:

I’m excited about the hire of our new General Manager (and first paid employee), Patrick Masson. One of the hardest things for an all-volunteer organization is execution: finishing the last 10% of tasks; reliably repeating necessary things; generally taking ideas from conception to reality. I expect in the short term that hiring Patrick will really help with those first two, and in the longer term, as he gets his feet under him, he’ll be a great help for the last one. Potentially a very exciting time for OSI.
Relatedly, we have a lot of proposals in the air, particularly with regards to membership and education/outreach. I hope in the next six months we’ll see a lot of concrete results from them.
This meeting represented a bit of a changing of the guard — it was the first board meeting for Richard Fontana and the last for a long-time member of our community who will be term-limited out at the end of this term. I always enjoy working with Richard, and fresh blood is great, but it was a good reminder that time continues to pass and that I should focus on, you know, getting things done :)
This is a small thing, but the OSI website now has a brief summary of open source on the front page. We also recently helped a high-profile website update and correct their definition of open source - the kind of small thing that isn’t very visible but will be influential in the long run, as we educate the next wave of open source devs. Hoorah for small victories!
You can help (I): We continue to look for help to update the OSI website, both by improving our license information and by updating or writing other pages on the website.
You can help (II): Richard’s addition to the board is significant, because just like I was part of the first class of board members nominated by affiliates, he is the first board member elected by the membership. That is an important milestone for us, as we move towards being more accountable to, and governed by, the open source community. You can help by joining as an individual member, or by encouraging your organizations to join as an affiliate.
I continue to be grateful to the Wikimedia Foundation (and my boss!) in supporting me in doing this. There is never a good time to take two days mostly off.
The relationship between OSI and other groups promoting open definitions was a continued source of discussion at the meeting, and I imagine will continue to be a repeating theme. I hope I can continue to act as a bridge with organizations in open data and open culture, and I expect Patrick will be great in helping us bridge to open education.

Reviewing the Manual of Style for Contract Drafting by Editing Twitter's Patent Agreement

Sun, 06 Oct 2013 00:00:00 GMT

strike {color:red;} u {color:blue;}

#Synopsis for lawyers

You should really buy the Manual of Style for Contract Drafting – it’ll make you a better drafter and editor. This post applies the book’s rules and guidelines to a publicly-available legal agreement (Twitter’s Innovator’s Patent Agreement) to explain what the book is and why it is valuable.

#tl;dr, for programmers

Contract writers have no equivalent of RFC 2119, mostly because contract drafting is hard. MSCD is a good try – defining terms and demanding consistency, just like the compiler lawyers lack. This post is a rewrite and fleshing out of the github edit history.

    <dl id="attachment_2631" class="wp-caption aligncenter" style="max-width:508px">
        <dt><a href="http://i0.wp.com/commons.wikimedia.org/wiki/File:Sales_contract_Shuruppak_Louvre_AO3760.jpg?ssl=1"><img src="http://i2.wp.com/tieguy.org/blog/wp-content/uploads/2013/10/Sales_contract_Shuruppak_Louvre.jpg?resize=508%2C480" alt="A contract for the selling of a field and a house." class="size-full wp-image-2631" /></a></dt>
        <dd>A contract for the selling of a field and a house, from <a href="https://en.wikipedia.org/wiki/Shuruppak">the Sumerian city of Shurrupak</a>, now in the Louvre.</dd>
    </dl><br />

#Introduction

I’ve believed for several years that the Manual of Style for Contract Drafting is a book that “every commercial lawyer should have on their desk“. You can judge the MSCD from its cover: it is aimed at people who draft contracts, attempting to teach them how to improve their writing style so that the contracts they create or negotiate are more legally precise, more concise, more enforceable, and easier to understand. When Ken offered me a copy of the Third Edition for a book review, I jumped. But good reviews got written fast and I had nothing new or different to add. So I let the book review project sit for a while. The thing is, once you’ve read MSCD, every time you read a legal document (even a good one!) you immediately start noticing small details that scream “MSCD would not approve”. So when I saw that Twitter’s Innovator’s Patent Agreement was on github, and started noticing those same small details, an idea was born: write a book review, in the form of public edits of the agreement. This is that review. Quoted text is from the agreement, with additions in blue underscore and deletions struck through in red (following standard legal style for edits). Unfortunately, the original plan (simply copy the comments from the github edit history into the blog post) did not pan out, but if you’re comfortable with reading git histories, an un-massaged version of the review below is in my github account.

#This is not about Twitter!

To be clear, this is a review of MSCD, not a critique of the Twitter IPA. The Twitter IPA was used simply to apply the book to a “real world” document and make it more tangible. The fact that you’ll see a bunch of edits below doesn’t mean the IPA is a bad document. Relative to some other documents I could name, including many I’ve written, this is actually a pretty small amount of edits. Because there are so many rules and suggestions (400+ pages of them!), applying MSCD to virtually any real-world contract will lead to a wall of edits. So this does not reflect badly on the drafters of the IPA, and shouldn’t be taken as a negative commentary on the substance of the agreement – which I think is important and innovative.

#Note for non-lawyers

As I noted in the tldr, this book has a lot in common with RFC 2119 – the document that tells internet standards writers what words like “should”, “must”, “recommended”, etc., mean in the context of Internet Engineering Task Force memos. RFC 2119 is important to write a good standard, but at the same time, it is not a substitute for understanding of the relevant technology. Similarly, this book is about contract style – it can tell you how to fix language, but isn’t a substitute for actually understanding contract law or other bodies of law a contract might deal with, like IP. So don’t buy it and think it’ll turn you into a contract drafter :)

#The Review

#Key principles

The book opens with a discussion of key principles for contract drafting (the “Characteristics of Optimal Contract Language”). Most of these are Plain English Drafting 101 stuff, like “omit archaisms” and “omit problematic terms of art”, or “be precise” and “employ usages consistently”. None of them are rocket science. And yet, once you’ve read the rest of the book (and as you’ll see below), you’ll realize that most contract drafters mostly only pay lipservice to these principles. By elaborating these principles into extensive, highly detailed rules, MSCD will make you realize how badly most contracts violate some of these “obvious” things.

#Organization and contract front matter

MSCD is very organized, in much the way you’d look at a contract – front to back (though not always). In that vein, chapter two covers the literal front of the contract – titles, introductory clauses, etc. It provides model language, ideal structures, and critiques traditional language; consistent with the rest of the book, it goes to an extreme level of detail to help drafters choose the exact best styles, consistent with the principles laid out in the first chapter. Applying these rules gives some sense of the flavor of the book as a whole. For example, MSCD 2.110-113 discusses (and recommends against) the traditional use of a single word: the defined term “Agreement”, primarily on grounds that it is repetitious (violating one of the principles of chapter 1). In the IPA, removing the term highlights that it was defined, but never used – a common mistake. (This is a recurring theme: carefully applying the MSCD rules will not only catch the rules highlighted by MSCD, but also find other problems.)

This INNOVATOR’s PATENT AGREEMENT(“Agreement”) is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation] corporation, having a place of business at Company Address (“Company”).

Some MSCD rules are incredibly minor. For example, MSCD 2.18 recommends against using ALL CAPS in the first sentence, because that is already done in the title. There is literally no substantive change here, but it makes things read a little better – which adds up for long documents.

INNOVATOR’sS PATENT AGREEMENT (IPA), Version 1.0

This INNOVATOR’s PATENT AGREEMENTinnovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation] corporation, having a place of business at Company Address (“Company”).

MSCD tries hard to be comprehensive, but can’t. The principles of the first chapter, like MSCD 1.63-1.66, “Contract Language Should Employ Usages Consistently”, help fill in the gap. In the absence of a rule on how to do templating, my revised IPA sticks with [ALL CAPS AND BRACKETS] for values that should be filled in when the document is used.

This innovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation][STATE OF INCORPORATION] corporation, having a place of business at Company Address[COMPANY ADDRESS] (“Company”).

The book’s attention to detail can occasionally be maddening. But on the whole, I find it helpful. By forcing you to look again at “the way things have always been done”, it can help you see ways to improve contract clarity and make things more readable without sacrificing (and often improving) precision. As an example, MSCD 2.68 recommends against including the address of a party that is a registered legal entity, because the combination of the full official name + the jurisdiction in which the organization is registered should be sufficient to uniquely identify the organization. From Ken’s perspective, if you need the address for communication, put it in a section on notices – not the beginning of the contract. See also the general principles of MSCD 1.41-1.58, “Contract Language Should Omit Redundancy”.

This innovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation, having a place of business at [COMPANY ADDRESS] (“Company”).

MSCD discusses dating agreements (i.e., when does the agreement actually take effect?) in some depth in 2.21-2.45 and 5.3-5.7 (four pages of discussion). This type of recommendation is one of the areas where MSCD shines, since thinking about this once and adopting a standard, carefully considered, style can avoid a variety of problems. The change below gives the agreement a date (and related signature block) in accordance with MSCD’s recommended defaults, but users of the agreement might want to consult MSCD and amend the agreement appropriately to their situation. (This is one of the rare sections where the book admits of much flexibility – it is often quite rigid in its recommendations.) MSCD’s recommendations usually, to my eye, improve readability. In one of the few recommendations that I find less readable, it recommends the wordier phrase below to replace “Agreed to and accepted” as the closing line of the document. I use it because (1) I’m seeking in this experiment/book review to follow MSCD’s recommendations, not necessarily my own instincts; and (2) MSCD’s recommendations in this area seem well justified – you can find them at 5.8-5.22. Note that, in the original intended use case of this document, the agreement may be dated in several other ways – for example, by submission to the patent office. However, as it is usually good form to date stand-alone agreements, I’ve included these terms here, whether or not strictly necessary. In the opening:

This innovator’s patent agreement is dated [DATE] and is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation (“Company”).

In the closing of the contract:

AGREED TO AND ACCEPTED:The parties are signing this agreement on the date stated in the introductory clause.

Strict application of MSCD while editing someone else’s contract would lead to horrible overkill, even when the recommendations are often well grounded. As an example, MSCD 2.46 recommends “between” as the preposition in the introductory clause, correctly calling traditional alternatives like ‘by and between’ “silly couplets” (a sign of legalese discussed in MSCD 1.42), and also rejecting the “made between” used in the IPA. No sane negotiator would quibble over “made between”, “by and between”, and “between”. However, it is also a good example of where internalizing MSCD’s arguments will encourage you to be concise. A word here, a word there- it adds up over time.

This innovator’s patent agreement is dated [DATE], and is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation (“Company”).

#Recitals, archaisms, and categorizing types of language

WHEREAS, using WHEREAS in recitals is archaic legalese, and WHEREAS avoiding archaisms is another principle all lawyers would tell you they endorse, and virtually none practice, and WHEREAS MSCD recommends not using whereas (MSCD 2.128), I have removed it from the IPA’s recitals, and used proper sentence structure (2.129). In discussion of recitals, MSCD uses a technique that recurs throughout the book: intense, specific, precise categorization, based on usage and purpose, with matching commentary and style guidelines. Recitals, for example, are categorized into “purpose” recitals, “context” recitals, and “simultaneous transaction” recitals, and then rules are provided for each. The IPA’s recital falls into the category of “purpose” recitals: indicating why the parties want to do this deal (2.118). Based on this categorization, MSCD suggests using ‘wants’ – which is “consistent with everyday English” – instead of the “oddly steamy” ‘desires to’ (2.131-132). [Were I editing for substance, I might add another sentence to explain why this particular agreement was used to reach the goal of assigning the invention.]

WHEREAS theThe Inventors have invented certain patentable subject matter whichmatter, and they desirewant to assign these inventions to the Company;.

#When nitpicking is also substantive change

The next change is probably the first change that will make lawyers seriously nervous, because it removes the magic words “good and valuable consideration“. In a passage that is typical of the book, 2.149-2.164 of MSCD goes into some detail about why the traditional “recital of consideration” is unnecessary, and what it should be replaced by. As is common where the book is at its best, the discussion doesn’t merely say “these are bad, you should remove them”, but instead discusses background law (the Restatements and caselaw), and explains why they support Ken’s conclusions. It also lectures the courts on what they should do, which I find tiresome. (Certainly not the only legal treatise with that problem.) In one of MSCD’s many suggestions that should be common sense, but isn’t, the book recommends that if there is some doubt as to whether or not there actually is consideration, the magic words should be replaced with an explicit discussion of what the consideration actually is. I have left that out here because it is a more substantive question, but it would be something for Twitter’s lawyers to consider if they ever considered adopting my changes.

NOW, THEREFORE, for good and valuable consideration, the receipt of which is hereby acknowledged, theThe parties therefore agree as follows:

#Specific words and the MSCD index

While diving into the IPA’s definitions, we can start seeing more of MSCD’s attention to detail by looking at the legal-ism “hereof”. MSCD hits on hereof in three places – 4.92, 13.260, and 15.12. The relevant one here is 13.260, which simply recommends avoiding all “here-” and “there-” words, correctly calling them “one of the hallmarks of legalese.” (See below for more discussion of herein.) This sort of thing is one of the strengths of the book. Almost a third of the book is Chapter 13, a list of words and phrases, with advice on how best to use every single one. Much of it does not apply to the admirably simple IPA, but most contracts will hit on a number of the words and benefit from reading the advice. Note that this change also uses “the date of this agreement” as part of the replacement for “hereof” because, for simplicity and readability, MSCD 2.28 recommends using “the date of this agreement” rather than the traditional “Effective Date”.

“Affiliate” means with respect to any Entity, any other Entity, whether or not existing on the date hereof,of this agreement, controlling controlled by or under common control with such first Entity.

MSCD 13.376 is quite clear: no latinisms, except the most basic ones – pro rata, status quo, vice versa. This is a good example of how following MSCD will make documents more readable not just for other lawyers, but also for non-lawyers as well.

Any sublicense granted by the Inventors under this section must be without threat or additional consideration; otherwise, the sublicense will be considered void ab initio.from the beginning.

Relatedly, MSCD’s index is excellent and really key to using MSCD well: once you’ve gone through the book once and have internalized the important points, you can use the index every time you’re unsure of a specific phrase or concept. So, here, I saw “hereof”, thought “I’m pretty sure MSCD has a discussion of ‘hereof’”, and used the index to quickly find and review the discussion. Certainly, the index is what made this review possible!

#Categories of contract language: performance, declaration, obligation

Chapter 3 of the book is about “categories of contract language”, where different categories (like language of agreement, of obligation, and of performance) are identified, and rules (and examples) set out for each one. Language of performance is highlighted as the kind of thing that the contract itself causes to occur. No less than 16 different commonly used ways of expressing this are identified and graded from “avoid” to “recommended.” “Hereby” comes out on top (“recommended”), and above “do hereby” click here now. Once you’ve read his analysis, you’ll probably agree it’s the best way to express that the contract itself causes the action to occur. So I use it here, despite it being an archaic “here” word. To me, breaking down language into categories like this (and others like them) are MSCD’s most useful mental discipline, because they help me think through exactly what I want a given clause to do, and then they give me the right language to do it with. [Again, trying to stick to edits MSCD specifically recommends. Here, the mixed-tense ‘sell’/’have sold’ language is very unclear and unusual, and could probably stand to be rethought or removed, but is not, as far as I can tell, a clear MSCD violation.]

Subject to the terms and conditions herein, Inventors do hereby sell, assign, and transfer and have sold, assigned, and transferred to the Company, for itself and its successors, transferees, and assignees, the entire worldwide right, title, and interest in and to the following patent application(s):

Another category of contract language that MSCD goes into in some depth is “language of declaration” – i.e., language used by the parties to declare facts. This category is then further split into statements – used when one party wants to assert that a statement is accurate – and acknowledgements – used when one party wants the other to admit knowledge and accuracy of a statement. Lawyers traditionally use “represents and warrants” to handle statements, but MSCD goes on at great length (citing caselaw, the UCC, and a few dictionaries) as to why this is a bad idea, and why “states” should be used instead. Importantly, he emphasizes that relying on “represents” to trigger a specific sort of remedy is unreliable, and that instead contract drafters should be explicit about what remedies they expect and how they will be enforced. (You can get the flavor of the argument, and his approach throughout the book, in Ken’s blog post on the issue.) Changing it here is a reminder that the book will make some lawyers uncomfortable (by challenging ritual word use) and can help drafting (by encouraging drafters to be precise and explicit about things like remedies). A more full rewrite of IPA could carefully consider the remedy question, though I tend to think that given the structure of the IPA it is not a substantive problem with the agreement.

Inventors representstate that Inventors have the rights, titles, and interests to convey as set forth herein; and Inventors covenant with Assignee that Inventors have not made and will not make any assignment, grant, mortgage, license, or other agreement affecting the rights, titles, and interests herein conveyed, except as explicitly set forth herein.

The other part of language of declaration – acknowledgement – is traditionally handled with “acknowledge and agree”. MSCD 3.318 (and 3.18) points out that the parties already “agree” to everything in the agreement in the opening of the contract, so “acknowledge and agree” later in the contract is redundant. (Redundancy is, correctly, another key sin MSCD acolytes hate.) This edit changes both “acknowledges and agrees” to simply “acknowledges”, and also removes a redundant “Inventors agree that”.

Inventors agree that Assignee may apply for and receive patents for Subject Matter in Assignee’s own name. Assignee acknowledges and agrees that the above promises are intended to run with the Patents and are binding on any future owner, assignee or exclusive licensee who has been given the right to enforce any claims of the Patents against third parties.

Assignee acknowledges and agrees that the promises in section 2 and 4 are intended to benefit third parties, except in the case of an assertion of claims of the Patents authorized under section 2.

“Language of obligation” is, not surprisingly, a key category of contract language, and one that MSCD goes into in some depth. One of the key recommendations on “language of obligation” is careful precision about what word is used to indicate obligation, which most contract drafters are somewhat sloppy about – sometimes using shall, sometimes using will, sometimes using must, without particular rhyme or reason. MSCD 3.46-3.85 recommends using “shall” instead of “agree to” to indicate when one party is obligated to – has a duty to – another. This is one of the few places where a post-MSCD contract will look more like legalese, but again, the justification is thorough and persuasive. Following this recommendation, I have removed two instances of “agree to”. The same analysis of language of obligation also recommends many places where shall should not be used- this same change removes two of those uses.

2. The Company, on behalf of itself and its successors, transferees, and assignees (collectively the “Assignee”), agreesshall notto assert any claims of any Patents which may be granted on any of the above applications unless asserted for a Defensive Purpose. An assertion of claims of the Patents shall be consideredis for a “Defensive Purpose” if the claims are asserted:

Inventors agree that Assignee may apply for and receive patents for Subject Matter in Assignee’s own name. Inventors agree,shall, when requested, and without further consideration,to execute all papers necessary to fully secure to Assignee the rights, titles and interests herein conveyed.

This license to the Inventors is not assignable, although the license shallwill pass to the heirs of an Inventor in the case that the Inventor is deceased, and the Inventors, individually or jointly, may appoint a representative who may act on their behalf in granting sublicenses under this section.

“Covenants to” also falls afoul of Ken’s sword as a poor choice for language of obligation (3.86). Here I remove it, though the usages in the IPA are somewhat unusual and so tricky to replace.

Assignee covenants with Inventors thatshall encumber any assignment or transfer of its right, title, or interest herein will be conveyed with the promises herein as an encumbrance.

Inventors state that Inventorsthey have the rights, titles, and interests to convey as set forth herein; and. Inventors covenant with Assigneestate that Inventorsthey have not made, and willshall not make, any assignment, grant, mortgage, license, or other agreement affecting the rights, titles, and interests herein conveyed, except as explicitly set forth herein.

#Ambiguity and Uncertainty

All of chapter 11 of MSCD is devoted to “the ambiguity of the part versus the whole” – essentially, the many ways that a drafter can make mistakes when trying to discuss parts of a whole (i.e., selling some parts, but not others, or making sure you sell all parts, or…). The section includes an interesting case study of a Third Circuit case, showing how drafters can very easily confuse judges. The change below is an attempt to remedy such an ambiguity in the IPA. “Each” (MSCD 11.83) appears to be the best way to cover the intent of the authors here, but “all” would probably also work and be consistent with the rest of the section.

(a) any and alleach inventions and improvements (“Subject Matter”) disclosed therein;

Chapter 11 isn’t the only single-minded chapter of that sort. Chapter 8 is devoted entirely to practical and scholarly discussion of the many variants of “reasonable efforts”, Chapter 9 to “material”, Chapter 10 to “references to time”, and Chapter 18 to “amendments”. Each one will show you flaws with common language and how to improve it. Chapter 7 is another, critical one – “Sources of Uncertainty in Contract Language”. Among the categories of uncertainty are lexical ambiguity, antecedent ambiguity, undue generality, and conflict. IPA mostly avoids these problems, but not always. For example, it uses “herein” throughout the agreement. Besides being a “here” word (discussed above) in many places it was unclear what the “herein” referred to – was it a specific section? the entire agreement? This is an example of the antecedent ambiguity Chapter 7 warns about. The same happens with the “promises” made in Sec. 2, which are referred to throughout the document, but never actually named or described in Sec. 2. A hacky solution would be to say “The Company promises” rather than the original “The Company agrees” (original language) or “The Company shall” (my language). A better solution might be to break up Sec. 2 into smaller sections and have one section that consists entirely of the “promises”, titled/named appropriately and then refered to by the rest of the document.

#Structuring the document

MSCD has extensive discussion of how documents should be structured (Chapter 4). Because of the overall simplicity of this document, I have not changed much. However, it recommends providing headings for sections (MSCD 4.15-21). As with many of the things that seem nitpicky at first, attempting to apply MSCD’s rules can expose substantive problems. In this change, I drafted headings for each section, but my attempt to write a meaningful heading for Sec. 3 suggests that it is not well-organized, and could be usefully split up into smaller sections. (A common problem; I ran into it with MPL.)

Assignment of Applications, Inventions, and Patents.

Limits on Assertion of Patents.

Patent Details.

License for Enforcement.

The same chapter’s discussion of enumerated clauses (MSCD 4.28-4.37) is (for me) one of the weaker sections in MSCD, because it is not entirely clear how to consistently apply them. In this case I have split up the list of (a), (b), etc. in Sec. 1 by adding a colon and made formatting changes (not shown here) to make the formatting consistent with the next section. This consistency makes it more obvious that “therein” and “thereto” are used in subparts (a) and (c) but “the above applications” in (b) and (d) – a problem I have not yet fixed, but a good example of how better typography and structuring can lead to better understanding of the text. It also makes more obvious that it is unclear whether the defined term “Patents” includes sections (b) and (c) – a potentially significant ambiguity in the text that should probably be resolved.

including:

#Defined Terms

MSCD’s chapter on Defined Terms covers a variety of topics, including location and structure of definitions. It also recommends against the common practice of redundantly defining singular and plural terms (like “‘Inventor’ or ‘Inventors’ means…”) on the sensible ground that the less redundant definition “wouldn’t confuse a reasonable reader”. Here the IPA follows the correct MSCD behavior, but checking MSCD’s rule led to a change fixing the capitalization of “inventor” in Sec. 4, likely an actual bug in the IPA.

Any sublicense granted by the Inventors under this section must be without threat or additional consideration; otherwise, the sublicense will be considered void ab initio. This license to the Inventors is not assignable, although the license shall pass to the heirs of an inventorInventor in the case that the inventorInventor is deceased, and the inventors,Inventors, individually or jointly, may appoint a representative who may act on their behalf in granting sublicenses under this section.

#Other Considerations

It is important to note that there are a variety of things I haven’t done here. I haven’t, for example, touched much substantively – I haven’t analyzed the validity of the patent grants. MSCD will not help you with this; it is not a substitute for substantive knowledge of the legal field you’re drafting the agreement in. I also haven’t touched some of the more complex drafting questions. For example, MSCD correctly points out that many “triplets” are redundant and reflect drafting that sounds pretty but is not legally precise. At the same time, without deep knowledge of the field, you often can’t winnow them down. So a careful MSCD reader will treat these as a warning flag and do more careful analysis. IPA has a few of these warning-flag triplets: “sell, assign, and transfer”, “successors, transferees, and assignees”, “right, title, and interest”. But it is out of the scope of this review to actually see if some of these words could be winnowed out. Similarly, the book has an extensive discussion of definitions – how they should be used, where they should be placed. Because of the structure of the IPA, “Defensive Purpose” (a key concept) is structured as a definition. I suspect that a truly thorough review of the document would have restructured that (based in part on an MSCD-driven analysis) though I can’t say for sure. Finally, this has just not been comprehensive. MSCD’s appendices have a sample edit, similar to this one, identifying 209 changes in a six page document. So you can really, really dig down if you want to, and I’m guessing Ken (if he reads this review) would have much more to say about it!

#Conclusion

This review really just scratches the surface of what MSCD can do for a drafter, but I think it yields a more readable, more correct document. It has to be taken with a grain of salt in places, but overall, the conclusion of this review is simple: everyone who writes or negotiates contracts for a living should buy and read it. Even if you apply only 1% of it, your contracts will be better than they were before.

Thoughts on the CC Summit

Thu, 29 Aug 2013 00:00:00 GMT

I was lucky enough to attend the Creative Commons Global Summit in Buenos Aires last week, including the pre-conference session on copyright reform.

Tattoo (cropped), by Os Keyes, used under CC BY-SA

Like Wikimania, there is simply too much here to summarize in coherent chunks, so here are my motes and thoughts during my return flight:

Maira Sutton of EFF summed up my strongest feeling about the event (and Wikimania, and many others) quite perfectly: “Getting a chance to finally meet those people you’ve admired from the Internet… Yea I hope that never gets old.” I hope I always remember that we are parts of a movement that draws much of its strength from being human - from being, simply, good to each other, and enjoying that. I realize sometimes being a lawyer gets in the way of that, but hopefully not too often ;)
At the copyright reform mini-conference, it was super-interesting to see the mix of countries playing offense and defense on copyright reform. Reform efforts discussed appeared to be patchwork; i.e., folks asking for one thing in one country, another in others, varying a great deal based on local circumstances. (The one “global” proposed solution was from American University/InfoJustice, who have worked with a team of lawyers from around the world to create a sort of global fair use/fair dealing exception called flexible use. An interesting idea.) Judging from my conversations at Wikimania and with Wikipedians at CC Summit, this is an area of great interest to Wikipedians, and possibly one where we could have a great impact as an example of the benefits of peer production.
Conversation around the revised CC 4.0 license drafts was mostly quite positive. The primary expressed concerns were about fragmentation and cross-jurisdictional compatibility. I understand these concerns better now, having engaged in several good discussions about them with folks at the conference. That said, I came away only confirmed on my core position on CC’s license drafting: when in doubt, CC should always err on the side of creating a global license and enabling low-complexity sharing.
This is not to say CC should rush things for 4.0, or be legally imprecise - just that they must be careful not to accidentally overlook the negative costs or overlawyering. Unfortunately, creating something knowingly imperfect is a profoundly difficult position for a lawyer to be in; something we’re trained to avoid at almost all costs. It is easiest to be in this position when there is an active negotiator on the other side, since they can actively persuade you about the compromise - instead of arguing against yourself. Public license drafting is perhaps unusually susceptible to causing this problem in lawyers; I do not envy the 4.0 drafters their difficult task.
There was a fair bit of (correct) complaining about the definition about Effective Technological Measures in the license - the most lawyerly piece of writing in 3.0 and the current drafts. Unfortunately, this is inevitable - to create a new, independent definition, instead of referring to the statute, is to risk protecting too much or too little, neither of which would be the correct outcome for CC. It would also make the license much longer than it currently is. I believe that the right solution is to drop the definition, and instead have a parallel distribution clause, where the important definition is easy: the recipient must be able to obtain at least one copy in which they are not prohibited from exercising the rights already defined. ETM then becomes much less important to define precisely.
Interesting to see that the distribution of licenses is mostly getting more free over time. After seeing the focuses of the various Creative Commons affiliates, I think this is probably not coincidence - they all seem quite dedicated to educating governments, OERs, and others about transaction costs associated with less free licenses, and many report good results.
That said, licensing data, even under free licenses, is going to be tricky - the trend there appears to be (at least) attribution, not disclaimer of rights. Attribution will be complicated for database integration; both from an engineering and a legal perspective.
Combined with the push towards government/institutional publication of data, there were a lot of talks and discussions about what to do with information that are difficult or inappropriate to edit, like scientific articles or historical documents. Lots of people think there is a lot of value to be added by tools that allow collaborative annotation and discussion, even on documents that can’t/shouldn’t be collaboratively edited. I think this could be a Wiki strength, if we built (or borrowed) the right tools, and I really hope we start on that soon.
Great energy in general from the affiliates around two areas: copyright reform, and encouragement of government and institutions to use CC licenses. I think these issues, and not the licenses themselves, will really be what drives the affiliates in the next 3-5 years. Remains to be seen where exactly CC HQ will fit into these issues - they are building a great team around OER, and announced support for copyright reform, but these are hard issues to lead from the center on, because they often need such specific, local knowledge.
Met lots of great people; too many to list here, but particularly great conversations with Prodi, Rafael, and folks from PLOS (who I think Wiki should partner with more). And of course catching up with a lot of old friends as well. In particular, perhaps my conversation with Kragen will spur me to finish my long-incomplete essay on Sen and Stallman.
I also had a particularly great conversation with my oldest friend, Dan, about what a modern-day attribution looks like. Now that we’re no longer limited to static textual lists of authors, as we have done since the dawn of the book, what can we do? How do we scale to mega-collaborative documents (like the Harry Potter page) that have hundreds or thousands of authors? How do we make it more two-way, so that there is not just formal attribution but genuine appreciation flowing both ways (without, of course, creating new frictions)? The “thanks” feature we’ve added to Wikipedia seems one small way to do this; Dan spoke also of how retweets simultaneously attribute and thank. But both of those are in walled silos- how can we take them outside of that?
Saw a great talk on “Copyright Exceptions in the Arab World” pan-Arab survey; really drove home how fragmented copyright statutes can be globally. (Translation, in particular, seemed an important and powerful exception, though my favorite exception was for military bands.) Of course, the practical impact of this is nearly nil - many of the organizations that are in charge of administering these literally don’t know they exist, and of course most of the people using the copyrights in the culture not only don’t know, they don’t care.
Beatriz Busaniche gave a nice talk; perhaps the most important single thing to me: a reminder that we should remember that even today most cultural communication takes place outside of (intentional) copyright.
Lessig is still Lessig; a powerful, clear, lucid speaker. We need more like him. In that vein, and after a late-night discussion about this exact topic, I remind speakers that before their next conference they should read Presentation Zen and Slideology.
Database rights session was interesting and informative, but perhaps did not ultimately move the ball forward very much. I fear that the situation is too complex, and the underlying legal concepts still too immature, for the big “add database to share-alike” step that CC is now committed to taking with 4.0. My initial impression (still subject to more research) is that Wikipedia’s factual and jurisdictional situation will avoid problems for us, but it may be worse for others.
After seeing all the energy from affiliates, as well as seeing it in Wikimedia’s community, I’m really curious about how innovation tends to happen in global NGOs like Red Cross or Greenpeace. Do national-level organizations discover issues and bring them to the center? Or is it primarily the center spotting issues (and solutions) and spurring the affiliates onward? Some mix? Obviously early CC was the former (Lessig personifies leadership from a center outwards) but the current CC seems to lean towards the latter. (This isn’t necessarily a bad place to be - it can simply reflect, as I think it does here, that the local affiliates are more optimistic and creative because they are closer to conditions on the ground.)
Watched two Baz Luhrmann films on my flight back, a fun reminder of the power of remix. I know most of my film friends think he’s awful, and admittedly for the first time I realized that Clair Danes is … not very good … in Romeo and Juliet. But in Luhrmann there is a zest, a gleeful chopping, mixing, and recreating of our culture. And I love that; I hope CC can help enable that for the next generation of Luhrmanns.

Final(?) Wikimania 2013 idea and notes dump

Fri, 16 Aug 2013 00:00:00 GMT

Me at Victoria Peak, the day after Wikimania, with thanks to Coren.

More random, more-or-less stream-of-(un)consciousness notes on the last few days of Wikimania:

The cab driver who got me to the airport had (at least) five cellphones. Two were mounted on each side of the steering wheel, and then a fifth appeared from somewhere else half-way through our drive to the airport. Two were Android(-ish?) smartphones, the others older phones. I’m sure there is some perfectly good reason for this, but no idea what it could be.
I had been under the impression that the island was essentially entirely either built up or too vertical to build on, so I had wondered how they’d managed to squeeze an entire Disneyland in there. Now I know; it is really quite amazing how much green, open space there is.
I was glad to hear Sue say that she cried while watching the South African Wikipedia Zero video, because I did too. As did lots of others, apparently. Still such a long way to reach the 13 out of 14 people on Earth who don’t use us every month, and so many different challenges to surmount - first access, then language, then engagement… oof. But obviously a worth challenge.
The 7-11s and Starbucks everywhere in HK are a reminder that the lines between national cultures are blurring faster than they ever have. I still got chicken feet as an unrequested pre-dinner appetizer one night, and unidentifiable fungus of some sort another afternoon. And I did get to see the very interesting, traditional Man Mo temple. But the trend is in favor of homogenization. This is in some ways very sad, as distinctive cultures make the world a richer place, but it will also over the long run make it easier for various contributors to understand each other - the classic mixed bag.
At the same time, was reminded in a few ways that barriers to communication are often surprisingly high- for example, a Chinese Wikipedian asked me (quite earnestly) about whether people disagreed about edits on English Wikipedia, which suggested we’re not very good at communicating to new Wikipedians in other languages even the most basic facts. (Asking “do English Wikipedians argue” feels to me like asking “is the sky blue for English Wikipedians?” - almost inconceivable that we haven’t already communicated that.)
Chinese Wikipedians are also working on an “intro to Wikipedia editing” tutorial that looks pretty cool. Made me sort of wonder if translating the newly-released How WP Works wikibook (or perhaps a shortened version of same?) might be a good/useful project for young Wiki movements, or if it is better to learn the same lessons through trial and error?
The German chapter has three policy people; the Foundation has zero (though all WMF’s lawyers pitch in on policy issues from time to time). I had sort of known this before, but not really internalized it. Still thinking through what that implies. (I had many great conversations with a bunch of the German chapter, and look forward to working with many of them.)
Very curious about the economics of the Octopus card. My impression as an outsider is that, through the Octopus cards, Hong Kong has established a defacto digital standard currency without relying on the inefficient, uninnovative, tax-on-the-body-politic leeches known as Visa and Mastercard. But that sounds too good to be true; there must be a catch to it.
Several Germans raved about the efficiency, politeness, etc. of the Hong Kong medical system. I chalk this up as a point for the Matt Yglesias “how government services are delivered and executed matters a lot and the US government should pay a lot more attention to that” school of thought.
The London organizers are extremely Bold; I wish them great luck in their planning and endeavors. I don’t think it’ll hurt the core conference to try these new experiments, and the payoff if it works could be huge, but I can understand the trepidation on the part of many long-time Wikimaniacs.
Had the opportunity to talk to a great variety of people who are passionate about the project; most who were excited and optimistic, some really concerned for a variety of reasons. I hope, of course, with my lawyer hat on, that I was able to calm those fears; in the mean time, it was a good reminder of the depth of passion for the project. (This was one of the many ways where I felt right at home, coming from years of GUADECs- the passion is real and deep and unfakeable in both places.)
That said, my biggest personal goal for the conference was to meet a broad cross-section of the community, rather than just the usual suspects from chapters, the board, etc. I feel like I had mixed achievement in this respect- I did have some pretty good conversations with non-chapter, non- (especially with people I met in line for food!) but at the end it was hard to do quite as much of it as I would have liked, especially for non-hacker folks. (The hacking days before the conference made meeting hackers much easier for me than it was to meet non-hacker editors.)
This really drove home that in the future, when I go somewhere for a non-Wiki conference, I really need to drop the local village pump or other comms channel an email and see if there is a meetup, editathon, etc. that I can crash.
We are deeply adaptable creatures, of course; I was quite overwhelmed by Hong Kong on day one and reasonably comfortable running around it on the free half-day I had before I flew home, and wish I’d had more time tosee it. Still, it seems to me a city that would be very difficult for me to live happily in without gigantic piles of money.
Surprising to me to realize (once it was pointed out by Mako) that many WP articles about a place don’t have a clear link to the equivalent WV page. That seems like low-hanging fruit; I found a couple Monday while seeing the town before my flight and will try to remember to fix them once I’m back on a real network connection.
Pretty happy with the two LCA team talks I was part of - we received a bunch of compliments on them, and many great questions from the audience. That said, I think we probably went too broad on the open licensing talk. It either needs to be narrower (only one license or class of licenses) or longer (time-wise) next year, if we make this subject an annual thing. But that is a quibble - overall, I’m pretty happy with the quality of my first impression.
I admit that I played buzzword bingo during the Board’s Q&A. I actually think it helped me pay attention to certain topics I might have zoned out a little bit on otherwise, which is good, but the fact that it seems to be played fairly widely may suggest something about the format. I’m not sure what I’d change, though - doing that sort of interaction really does seem like an important way to build trust in the board. (You can mark “social capital” off your Luis Blog Post Bingo card if you’ve read this far.)
The closing beach party was a lot of fun, but (with no slight intended to the HK organizers) the top for me will always be the various beach parties at GUADEC Vilanova. For those of you who weren’t there in Vilanova, imagine something like the WM party, but with the broadest beach I’ve ever seen in my whole life, the bar literally in the middle of the sand, and the bar open until 4am. Now that the bar has been raised, I look forward to London’s beach party! ;)
Real joy to meet Risker; reminder that these sorts of meetings really allow you to get context and build up a mental model of someone in a way that you just can’t do offline, which makes these soooo important.
Copyright reform was a constant and recurring theme of discussion. In six years, certain aspects of Mickey Mouse will start creeping into the public domain, and that means we’re going to have another copyright bill in that time period. I suspect that the as a movement have to be ready and prepared for that, shape and form To Be Determined.

Bottom line: I’m exhausted, and (as I hit my six-months-iversary) more glad than ever I took this plunge. :) See everyone in London!

Wikimania, Day 3

Fri, 09 Aug 2013 00:00:00 GMT

Soooo much. As with the first two days, these are fragmentary notes as much for my benefit as for anyone else’s, so take with bullet points of salt:

Ceremonia de inauguración, by Diego Delso, used under CC BY-SA-3.0, via Wikimedia Commons

The lion dance in the opening ceremony was exactly as advertised - a good way to wake up.
It was nice to hear the French issue called out in Jimmy’s talk, even if he didn’t call out LCA’s role in it :)
The session on the internet in China was informative, but frustratingly brief- needs a lot more detail. Key takeaway: the mainland Chinese Wikipedians appear to believe that turning off http access would be a bad idea. This is a frustrating tension, between access and surveillance.
The talk on how Swedish parliamentarians see Wikimedia was not perfect science (response rates were low-ish and skewed in a variety of ways) but the data was still fun and informative. Key takeaways: MPs in .se have pretty positive feelings about WP, and high usage, but assume their co-workers do not have a high opinion of it themselves. I would love to see data similar to this for American politicians, and perhaps as importantly for political staffs.
The friendly virtual space policy discussion was interesting, but I am having to recalibrate my timescales and expectations of progress, just because of the vastness and multi-faceted-ness of this community. (At the same time I hope not to become accepting of inaction.)
Mako and Aaron’s Wiki Ecology talk was hard to summarize, but very interesting. So much research to be done to understand how FOSS and wiki ticks; I’m glad Mako is doing it.
Not all talks are home runs, unfortunately; I like Foucault as much as the next guy (and am quite sympathetic to the notion that pervasive recording influences behavior) but if it comes up in your talk focus may be an issue :)
The government copyright talk was interesting, and mostly informative. Good reminder that we should think about if/how to support the state-level government code freeing being done by Carl Malamud.
Hallway conversations are great; not surprising.
(More?) importantly, for the first time tonight had the great, long, passionate, late night conversations that make you want to say “can’t wait to have a beer with you again next year”. Had a long enough night that I had that kind of conversation with quite a series of people, actually.

Random notes on Wikimania, Day 2

Thu, 08 Aug 2013 00:00:00 GMT

I’m pretty sure this is a cold, not jet lag. Not sure which would be better/worse browse this site. More notes:

Continue to hear Wikidata licensing concerns; need to work on communicating about that.
Multimedia round-table is well-attended (to the point of people sitting on the floor), even as someone points out that the day when “multimedia” was an exciting word was a long time ago.
Fabrice is a real pro at running a session – well-prepared and a great, positive guide to a topic; seemingly also getting solid, constructive feedback. The resulting discussion was quite high-quality for this sort of session.
Relatedly, I did not attend the session on preparation/constructive critique for speakers, but (1) it’s a really good idea and (2) maybe something similar could be done for panels? And of course should happen online before we come to the venue :)
Great to meet Jon Davies of WMUK, Dimitar, Niko, and a bunch of other interesting folks.
It is minor, but someone at the multimedia roundtable suggested that there should be a WordPress plugin to allow easy insertion and use of Common content into WordPress. To which I say: amen! It’s weird how often open projects neglect to promote their platform by building plugins for popular open content platforms (like WordPress) . [Later: apparently there is such a thing, but not updated in two years – too bad.]
I won’t call attribution in commons a minefield, exactly, but it’s extremely complex; was reminded of that today in the discussion of a media viewer that could show a more “black box” popup around images when viewing them. I’m adding it to my long-term radar…
Editor motivation is implicit in a lot of discussions, but can be hard to focus on or explicitly surface (or maybe more correctly, easy to lose track of when you’re focused on other things). I don’t mean this as a criticism, just an observation – I find myself also making the same mistake in conversations.
The EU-based chapters have a very interesting set of challenges around changing Brussels. Was interesting to discuss, and will be interesting to see how it goes.
Spent some time reviewing the schedule for the next few days to figure out what I’ll attend; it is more overwhelming than I’d even really realized.
Party was fun and views were insane. This HK factoid was pointed out and is also insane.

Notes on day 1 of my first Wikimania

Tue, 06 Aug 2013 00:00:00 GMT

Temple Street Night Food Restaurant by Marim68821, under CC-BY-SA-3.0, via Wikimedia Commons

Collected bullet points from day 1 of my first Wikimania:

Hong Kong is intense. I am used to, and like, big cities, but HK feels like a scale different even from, say, Cairo, New York, Delhi, or Bangalore. Had great fun last night walking around with a few friends, ended up at Temple Spice Crab (which was amazing in a vast number of ways) and along the waterfront.
Doing surprisingly well with jet lag, so far. We will see. (Late update: crashed pretty hard last night.)
This is such deja vu from GUADEC, in terms of watching reunions, seeing organization (or occasional lack thereof ;) seeing people just joyful to be in each other’s presence and working on shared practices/goals. I look forward to seeing more of the differences as the conference progresses.
First difference may be that there are a lot of structural committee meetings; not just board, but also AffCom, WCA, etc. Different from more specifically developer-oriented conferences. (I am mostly going to focus on the hacker days myself, but will also crash parts of WCA and others.)
Khmer wikipedia is represented in the meeting I am in as I write this. Khmer is not a terribly small language (16M) but I am still heartened to see it here.
First mention of merchandising came more than an hour into the WCA meeting. Not drawing any conclusions, just really the first legal thing. (Later they came thick and fast- so many interesting questions; some I could answer, some I couldn’t.)
Met another engineer-turned-lawyer, who appears to have (wisely) kept his engineering career viable while doing law school. Slightly jealous ;)
Need more stickers! Got wikidata on my tablet, at least.
Lots of fun meeting new people.
The map embedded here is amazing, showing not just geodata but historical change over time. Shame we’re not yet technically ready to make them more wide-spread.

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

Wed, 05 Jun 2013 00:00:00 GMT

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

At the Wikimedia Foundation (for, um, three months now)

Mon, 20 May 2013 00:00:00 GMT

Since it was founded 12 years ago this week, Wikipedia has become an indispensable part of the world’s information infrastructure. It’s a kind of public utility: You turn on the faucet and water comes out; you do an Internet search and Wikipedia answers your question. People don’t think much about who creates it, but you should. We do it for you, with love.

Wikimedia Foundation Executive Director Sue Gardner, from http://blog.wikimedia.org/2013/01/14/wikipedia-the-peoples-encyclopedia/

As Sue says, the people who create Wikipedia are terrific. I’m lucky enough to say that I’ve just wrapped up my first three months as their lawyer - as Deputy General Counsel at the Wikimedia Foundation. Consider this the personal announcement I should have made three months ago :)

Wikimania 2012 Group Photograph, by Helpameout, under CC-BY-SA 3.0.

Greenberg Traurig was terrific for me: Heather has a wealth of knowledge and experience about how to do deals (both open source and otherwise), and through her, I did a lot of interesting work for interesting clients. Giving up that diversity and experience was the hardest part of leaving private practice.

Based on the evidence of the first three months, though, I made a great choice - I’ve replaced diversity of clients with a vast diversity of work; replaced one experienced, thoughtful boss with one of equal skill but different background (so I’m learning new things); and replaced the resources (and distance) of a vast firm with a small but tight and energized team. All of these have been wins. And of course working on behalf of this movement is a great privilege, and (so far) a pleasure. (With no offense to GT, pleasure is rarely part of the package at a large firm.)

The new scope of the work is perhaps the biggest change. Where I previously focused primarily on technology licensing, I’m now an “internet lawyer” in the broadest sense of the word: I, my (great) team, and our various strong outside counsel work on topics from employment contracts, to privacy policies, to headline-grabbing speech issues, to patent/trademark/copyright questions - it is all over the place. This is both challenging, and great fun - I couldn’t ask for a better place to be at this point in my life. (And of course, being always on the side of the community is great too - though I did more of that at Greenberg than many people would assume.)

I don’t expect that this move will have a negative impact on my other work in the broader open source community. If anything, not focusing on licensing all day at work has given me more energy to work on OSI-related things when I get home, and I have more flexibility to travel and speak with and for various communities too. (I’m having great fun being on the mailing lists of literally every known open source license revision community, for example. :)

If you’d like to join us (as we work to get the next 1/2 billion users a month), there are a lot of opportunities open right now, including one working for me on my team, and some doing interesting work at the overlap between community, tech, and product management. Come on over - you won’t regret it :)

Information diet weekend

Sun, 05 May 2013 00:00:00 GMT

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 Diet ((capsule book review: great diagnosis of the problem, pretty poor recommendations for solutions)) 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. ((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.)) 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?

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

Sun, 21 Apr 2013 00:00:00 GMT

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. ((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.)) 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. RSS ((again, in the very broad sense of the word, including more modern open specifications that do basically the same thing)) 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 :)

One year on OSI's board (aka one year in OSI's licensing)

Sun, 17 Mar 2013 00:00:00 GMT

Since it has been roughly one year since Mozilla nominated me to sit on the OSI board, I thought I’d recap what I’ve done over the course of the year. It hasn’t been a perfect year by any stretch, but I’m pretty happy with what we’ve done and I think we’re pointed in the right direction. Because my primary public responsibility on the board has been chairing the license committee, this can also sort of double as a review of the last year in license-discuss/license-review (though there is lots of stuff done by other members of the community that doesn’t show up here yet).

Outside of licensing, my work has consisted mostly of cheerleading the hard work of others on the board (like Deb’s hard work on our upcoming DC meeting and the work of many people on our membership initiative) - I haven’t listed each instance of that here.

“Wikimedia Deutschland offices in Berlin, during the tour at the Chapters Meeting 2011”, by Mike Peel, under CC-BY-SA 2.5. (Mind you, CC is not actually OSI-certified ;)

Some things that got done:

Drafted and published a beta Code of Conduct for license-discuss/license-review. This was drafted with the intent that it will eventually be a CoC for all of OSI, but we’re still formally beta-testing it in the license committee community.
Revised the opensource.org/licenses landing page to make it more useful to visitors who are not familiar with open source. Also poked and prodded others to do various improvements to the FAQ, which now has categories and a few improved questions.
Revised OSI’s history page. The main changes were to update it to reflect the past 5-6 years, but also to make it more readable and more positive.
Oversaw a number of license submissions. I can’t take much credit for these- the community does most of the heavy lifting. But the group submitted in the past year include AROS, MOSL, “No Nonsense”, and CeCILL. The new EUPL is in the pipeline as well.
Engaged Greenberg Traurig as outside counsel to OSI, and organized and hosted a board face-to-face meeting at Greenberg’s San Francisco office space.
Helped keep lines of communication open (and hopefully improving!) with SPDX and OKFN.

Some projects are important, but incomplete:

Opened discussion of the status of licenses without patent grants in the modern licensing world, and how OSI could have a position on that without unduly undermining existing licenses.
Improving the presentation of existing licenses. A group of volunteers ran with my suggestion and removed comments that were confusing to visitors, but we haven’t quite gotten around to presenting plain text licenses, or updating the template BSD/MIT licenses. We’re also just getting started on other improvements - help still wanted!
Looked into objective analysis of license popularity, and a “license chooser” project. Both are huge projects. They do have some (quiet) momentum, but even if they are at all workable, they are still a long way out.

Some projects never really got off the ground:

I wanted to get GNOME to join OSI as an affiliate. This, very indirectly, spurred the history page revision mentioned above, but otherwise never really got anywhere.
I wanted to have OSI reach out to the authors of the CPOL and push them to improve it or adopt an existing license. That never happened.
I wanted to figure out how to encourage github to require a license for new projects, but got no traction.

I hope that this sounds like a pretty good year- it isn’t perfect but it felt like a good start to me, giving us some things we can build on for future years.

That said, it shouldn’t be up to just me - if you think this kind of thing sounds useful for the broader open source community, you can help :)

Join license-discuss, or, if you’re more sensitive to mail traffic, but still want to help with the committee’s most important work, join license-review, which focuses on approving/rejecting proposed new licenses.
Become a member! Easier than joining license-discuss ;) and provides both fiscal and moral support to the organization.

Younger developers reject licensing, risk chance for reform

Fri, 01 Feb 2013 00:00:00 GMT

Originally published at opensource.com.

Modern copyright law grants copyright automatically to any creative work, including simple things like blog posts – and small pieces of code on github. This default copyright creates an assumption that for someone to do anything further with someone else’s creative work requires permission from the author—what Lawrence Lessig calls “the permission culture.” The open license ecosystem often takes this permission culture for granted, rather than fighting back—and that may be contributing to the proliferation of unlicensed code.

#Post open source software

A few months back, James Governor (@monkchips) tweeted: “younger devs today are about POSS–Post open source software. f*ck the license and governance, just commit to github.” While the actual extent of “POSS” is debatable, there is definitely an increase in the amount of unlicensed code out there. A recent post by Max Jones Werner, Are GitHubbers taking open source seriously?, suggests that 20% or more of the most-watched github projects are unlicensed. (The previously dominant code sharing platforms, SourceForge and Google Code, required a license choice before publication, so their percentage was zero.) The pushback against licensing isn’t specific to software, either—at least some sharing musicians are deliberately spurning Creative Commons and Nina Paley has been obliquely making the same point about the licensing of her art as well.

This lack of licensing is a bad thing—it creates confusion for other developers, creates risk for authors, and is great for lawyers. So if all that is true—why are people still not doing it?

#Reasons for the licensing pushback

POSS might be more than just bad hygiene. It is easy to assume that the pushback against licenses (“post-open source”) is because licensing is confusing/time-consuming and people are lazy/busy. While I’m sure these are the primary reasons, I think that, for some people, the pushback against licenses often reflects a belief that “no copyright should mean no permission needed.” In other words, those people choose not to use a license because, on some level, they reject the permission culture. In this case, publishing without a license is in some way a political statement—“not every use should need permission.”

Another motive, that I won’t go into here but which also deserves serious discussion for license authors, is simply that the values encapsulated in our licenses are taken for granted by younger developers who have always had a plentiful, healthy free-as-in-beer code commons. Both the permissive and copyleft communities would do well to argue the case for their licenses (not just their overall philosophies) better than they currently do.

#Rejecting the permission culture

If some “no license” sharing is a quiet rejection of the permission culture, the lawyer’s solution (make everyone use a license, for their own good!) can be interpreted as active acceptance of the permission culture. Once an author uses a standard license, their immediate interests are protected—but the political content of not choosing a license is lost. Or to put it another way: if license authors get their wish and everyone uses a license for all content, then, to the casual observer, it looks like everyone accepts the permission culture. This could make it harder to change that culture—to change the defaults—in the long run.

To be clear, a license can’t actually change the defaults—those are baked into copyright law. The best it can do is register a protest against, and raise awareness of, the current state of things.

So how might we preserve the content of the political speech against the permission culture, while also allowing for use in that same, actually-existing permission culture? Or to put it more concisely: what would a “license” that actively rejects the permission culture look like?

A couple of off-the-wall options:

Permissive + political preamble license: The WTFPL license (“Do WTF you want”) has been floating around for ages, and using it makes the point that (1) you want people to use your code and (2) you’re irritated that they even have to ask. Adding a brief “I hate that I have to do this” preamble to a permissive license like CC-0 might serve a similar purpose, while providing more legal certainty than WTFPL. (And of course such a preamble could also be used with a strong copyleft, like copyleft-next.)
Fair Use: Fair use is the traditional safety valve for copyright, but it is hard to know if a particular use is “fair.” So a license could be written that it, instead of formally licensing under specific terms, instead aims to provide more certainty about fair use. Some ways this could be done would include broadly defining the fair use categories, explicitly accepting transformative use as a factor in the fair use analysis, or asking courts to interpret ambiguity in favor of the recipient instead of the author. It is also possible to imagine this as a supplement to the existing fair use clauses in modern licenses (CC-BY 3.0 Sec. 2, GPL v3 Sec. 2, MPL 2 Sec 2.6), laying out a strong vision of fair use to help guide and protect anyone relying on those clauses.
“What People Actually Think Copyright Is” license: most Americans think that personal use of copyrighted materials is legal under modern copyright law. (See research mentioned in Jessica Litman’s Digital Copyright.) So a license that focused on personal use might work better than the more nebulous “non-commercial.” As a bonus, since commercial interests will clearly be unable to use the content, getting it “right for lawyers” may be less of a concern.

Careful readers will note that the last two options are unlikely to be OSI-open or FSF-free. For the purposes of this exercise, that’s OK—the assumption that licensing is always a good thing is what I’d like to provoke people to think about here.

#A provocation

I don’t offer these license ideas as a comprehensive survey of what an anti-permission-culture license might look like, or even a good survey. Instead, take them as a provocation: are we— articularly authors and evaluators of open licenses—part of the problem of the permission culture? Are we actually responding to the people who use our licenses, if one of their desires is to push back against the need to license? Can we be more creative about expressing distaste for the permission culture, without gumming up the works of sharing too much? I think that, if we think critically, we can, and perhaps we should.

Pushing back against licensing and the permission culture

Sun, 27 Jan 2013 00:00:00 GMT

tl;dr: the open license ecosystem assumes that sharing can’t (or even shouldn’t) happen without explicit permission in the form of licenses. What if “post open source” is an implicit critique of that assumption - saying, in essence, “I reject the permission culture”? If so, license authors might want to consider creating options that enable people to express that opinion.

A few months back, James Governor said:

younger devs today are about POSS - Post open source software. fuck the license and governance, just commit to github.

— James Governor (@monkchips) September 17, 2012
While the actual extent of “POSS” is debatable, there is definitely an increase in the amount of unlicensed code out there. This post suggests 20+% of the most-watched github projects are unlicensed. The pushback against licensing isn’t specific to software, either - at least some sharing musicians are deliberately spurning Creative Commons (via Lucas) and Nina Paley has been obliquely making the same point about the licensing of her art as well.

A few months back, I pointed out that the lack of licensing led to confusion and so was great for lawyers. That post was accurate, but slightly glib. Here, I want to grapple more seriously with the rejection of licensing, and provoke the licensing community to think about what that means.

#A dab of history and context

In the US, prior to the 1976 Copyright Act, you had to take affirmative steps to get a protectable copyright. In other words, you could publish something and expect others to be able to legally reuse it, without slapping a license on it first.

Since the 1976 Act, you get copyright simply by creating the work in question. That means every blog post and every github commit is copyrighted. This restrictive default, combined with the weakness of fair use, leads to the “permission culture” - the pernicious assumption that you must always ask permission before doing anything with anyone’s work, because nothing is ever simply shared or legally usable. (This assumption is incorrect, but the cost of acting that way can be high if you make a mistake.)

Permission, by Nina Paley.

#”POSS” might be more than just bad hygiene

It is easy to assume that the pushback against licenses (“post-open source”) is because licensing is confusing/time-consuming and people are lazy/busy. While I’m sure these are the primary reasons, I think that, for some people, the pushback against licenses often reflects a belief that “no copyright should mean no permission needed”. In other words, those people choose not to use a license because, on some level, they reject the permission culture and want to go back to the pre-1976 defaults. In this case, publishing without a license is in some way a political statement - “not every use should need permission”. ((Another motive, that I won’t go into here but which also deserves serious discussion for license authors, is simply that the values encapsulated in our licenses are taken for granted by younger developers who have always had a plentiful, healthy free-as-in-beer code commons. Both the permissive and copyleft communities would do well to argue the case for their licenses (not just their overall philosophies) better than they currently do.))

#Fixing(?) the politics of our licenses

If some “no license” sharing is a quiet rejection of the permission culture, the lawyer’s solution (make everyone use a license, for their own good!) starts to look bad. This is because once an author has used a standard license, their immediate interests are protected - but the political content of not choosing a license is lost. Or to put it another way: if license authors get their wish, and everyone uses a license for all content, then, to the casual observer, it looks like everyone accepts the permission culture. This could make it harder to change that culture - to change the defaults - in the long run.

What would a “license” that actively rejects the permission culture look like?

A couple of off-the-wall options:

Permissive+political preamble license: The WTFPL license (“Do WTF you want”) has been floating around for ages, and using it makes the point that (1) you want people to use your code and (2) you’re irritated that they even have to ask. Adding a brief “I hate that I have to do this” preamble to a permissive license like CC-0 might serve a similar purpose, while providing more legal certainty than WTFPL. (And of course such a preamble could also be used with a strong copyleft, like copyleft-next.)
Fair Use supplement: Fair use is the traditional safety valve for copyright, but it is hard to know if a particular use is “fair.” So a “license” could be written that, instead of formally licensing under specific terms, instead aims to provide more certainty about fair use. Some ways this could be done would include broadly defining the fair use categories, explicitly accepting transformative use as a factor in the fair use analysis, or asking courts to interpret ambiguity in favor of the recipient instead of the author. It is also possible to imagine this as a supplement to the existing fair use clauses in modern licenses (CC-BY 3.0 Sec. 2, GPL v3 Sec. 2, MPL 2 Sec 2.6), laying out a strong vision of fair use to help guide and protect anyone relying on those clauses.
“What People Actually Think Copyright Is” license: most Americans ((per Jessica Littman, Digital Copyright, p. 117)) think that personal use of copyrighted materials is legal under modern copyright law. So a license that focused on personal use might work better than the more nebulous “non-commercial”. As a bonus, since commercial interests will clearly be unable to use the content, getting it “right for lawyers” may be less of a concern.

Careful readers will note that the last two options are unlikely to be OSI-open or FSF-free. For the purposes of this exercise, that’s OK- OSI, FSF, and CC’s iron-clad assumption that licensing is good is what I’d like to provoke people to think about here. ((If it wasn’t already obvious, this post is obviously not made with my OSI hat on - OSI continues to firmly endorse the Open Source Definition.))

#Conclusion, and provocation

I don’t offer these license ideas as a comprehensive survey of what an anti-permission-culture license might look like, or even a good survey. Instead, take them as a provocation: are we - particularly authors and evaluators of open licenses - part of the problem of the permission culture? Are we actually responding to the people who use our licenses, if one of their desires is to push back against the need to license? Can we be more creative about expressing distaste for the permission culture, without gumming up the works of sharing too much? I think that, if we think critically, we can, and perhaps we should.

A revised OSI "Open Source Licenses" page

Thu, 03 Jan 2013 00:00:00 GMT

When someone new to open source does a web search for “open source licenses”, the first page that comes up ((other than an ad for opensource.com, interestingly)) is opensource.org/licenses - making it one of the most important resources for newcomers to open source. ((Interesting research question/bleg: for a reasonably comprehensive set of important “open source + foo” terms, like collaboration, licensing, etc., where do search results point at? How many go to opensource.org? .com? other sites? Is there a tool that will do this sort of analysis automatically?))

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.

Don’t do a nano without them by mpclemens, used under CC-BY 2.0.

Here is what the revision does, in a nutshell:

gives context: what is an open source license? what does OSI-approved mean? These give a newcomer to the list a fighting chance of figuring out what the lists mean.
provides a less-overwhelming list of licenses: using the “popular, widely used, or have strong communities” list created by the 2006 Proliferation Report, it gives people pointers to several useful licenses immediately, while still providing access to the full lists.
works with OSI’s other resources: The new page links to OSI’s excellent FAQ and the annotated Open Source Definition, among other things. Again, these provide context, and help the page serve as a gateway for others.
is progress: OSI can be, and often should be, a very change-averse organization. But it is nice to score a small win here and there- I hope this will be the first of many while I chair the license committee.

And what it doesn’t do:

change the world: I’m blogging about this because it’s significant. But I also want to be clear that it is only a small win, and hopefully one that in 2-3 years OSI will look back on and have a good chuckle about.
change, update or revise the license categories: The original license proliferation committee license categories, from 2006, have been useful to many people, and were instrumental in slowing the pace of license proliferation. So they make sense to use as the (relatively neutral) basis for the list that is now prominent on /licenses/. But they’re showing their age- notably by including CDDL in “popular/widely used” but in other ways as well (primarily, by not categorizing a variety of new licenses). OSI’s licensing committee (aka the license-discuss list, with input from others) will be gradually investigating how to address this over the course of the next year or so. This process has already started, somewhat, with my calls for quantitative criteria for license analysis. I intend to continue to push the list (including hopefully new members!) to think through the issue and its implications.

If you’re interested in helping out with future changes, please join the list.

Licensing confusion is great! (for lawyers)

Mon, 03 Dec 2012 00:00:00 GMT

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 , 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! ((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

Mon, 12 Nov 2012 00:00:00 GMT

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.

AGPL is usually about free riding, not fragmentation or adoption

Tue, 09 Oct 2012 00:00:00 GMT

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

AGPL’s alleged benefit (the “problem that doesn’t exist”) is the prevention of fragmentation.
Permissive licenses are on the rise, so using a super-strong copyleft is counter-productive when you’re looking to attract developers.
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.

Urban Fragments, by APM Alex, used under CC-BY 2.0

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

Mon, 10 Sep 2012 00:00:00 GMT

Mark Pilgrim had a great post ((vanished since I originally drafted this, but link kept for reference)) 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.

Great-great-grandpa Lewis Hannum.

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 ((Which, for the record, was roughly 1,000 times better than Canon’s bundled scanning crapware.)), 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 ((which is sort of pathetic; how come we still don’t have a decent simple HTML editor?)).

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?

Speaking at Practicing Law Institute's Open Source/Free Software 2013

Tue, 04 Sep 2012 00:00:00 GMT

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

List of Open _______

Wed, 29 Aug 2012 00:00:00 GMT

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.

“Open”, by Monica’s Dad, used under CC-BY 2.0.

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?

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

Sun, 19 Aug 2012 00:00:00 GMT

[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 warranty ((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”)) 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. ((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.)) 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. :)

Joining the Open Source Initiative board of directors

Mon, 19 Mar 2012 00:00:00 GMT

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. ((Ask me how your organization can join!)) 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, ((Though obviously I expect we’ll be great :) )) 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.

On the Importance of Per-File License Information

Sat, 17 Mar 2012 00:00:00 GMT

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:

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

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

Thu, 02 Feb 2012 00:00:00 GMT

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

Personal MPL acknowledgments

Tue, 03 Jan 2012 00:00:00 GMT

This morning I hit publish on the announcement of MPL 2.0, finishing a two year process. The official announcement had a number of acknowledgements for the many people who helped out along the way, but I wanted to take to my personal blog to add a few personal notes.

“thank you note for every language,” by woodleywonderworks, used under CC-BY 2.0 .First, Gerv Markham. Gerv has in many ways been central to Mozilla’s open source mission for a while, and it would have been easy for him to feel threatened when I parachuted in and began working on the license. Instead, he’s been helpful, patient, and constructive- everything you’d want from a co-worker and team member.

Second, Brett Smith, of the FSF: Brett has brought a very professional, constructive approach to working with me on the license. Without his dedication and patience the new GPL compatibility approach would not have succeeded. Aaron Williamson and James Vasile at SFLC and Richard Fontana at Red Hat were also instrumental in this, and again gave freely of their time when they didn’t have to. They also kept a straight face when I suggested the new approach, which probably helped a great deal in getting it done. :)

Third, Karen Copenhaver and Heather Meeker were incredible pros in helping push out the critical betas- they helped me go through the important issues and get the language right, in a way only people with decades of experience can do. That they were willing to give their time to Mozilla and to me was incredibly generous- most partners at major law firms aren’t willing to take those steps. And I’m not just saying that because Heather is now my boss. ;)

Finally, and most importantly, Mitchell Baker and Harvey Anderson: Mitchell and Harvey took a gamble when they brought me on board this project- one they didn’t need to do. This has been their baby for the past ten years, and they could have done this work themselves, or just let the license continue to age gracefully (as it was doing). Not only did they give me this terrific opportunity, they then opened up their calendars and their minds to me. As a result, I’ve had a terrific educational experience, learning the nooks and crannies of the license as well as lots about how to draft a document that stands the test of time. (Rumor has it that Mitchell wrote the original in a month, which I still find mind-boggling, and I can confirm that the text is still burned into her brain in high resolution.) It has really been an honor and a privilege for me to be involved with them and in this process, so I’m deeply thankful for their encouragement and invitation to participate.

I’ll probably write more here soon about the license and the process, but thanking people was really at the top of my priority list.

A note on 2011

Thu, 29 Dec 2011 00:00:00 GMT

The best thing I did for myself in 2011 was to get back on a bicycle after not being on one for 15+ years, and after never actually being comfortable on one. I’m not going to be racing any time soon, but I now really look forward to a bike ride as part of the average weekend and even the average vacation.

Yesterday was a nice punctuation mark to that, featuring a long ride down to the ocean, a great view, and a very satisfying fish and chips.

I am definitely enjoying some time out of the office and looking forward to a great 2012- hope my friends are too. Now I just need to figure out what life improvement can trump “get back on a bike.” Suggestions welcome :)

MPL 2.0, copyleft, and license compatibility

Wed, 28 Sep 2011 00:00:00 GMT

Originally published at opensource.com.

In part one of my Mozilla Public License piece, I mentioned license compatibility as a major feature of MPL 2.0. In fact, it’s such a major - and complicated - issue that it warrants its own explanation.

#First, a disclaimer

Exactly what it means for two open source licenses to be compatible is a complicated topic; so complicated that the most sophisticated free and open source license wranglers often disagree on the nuances. This article can provide only an abbreviated overview, and will inevitably have some things that not everyone agrees with. Apologies in advance!

#So what is compatibility?

When talking about open source licenses, someone who says “compatible” generally means “one-way” compatibility, where code from a more permissive license can be used as part of a project whose overall license is more restrictive, but not vice versa. For example, if the Mozilla Project switches to MPL 2, Firefox may quickly contain Apache code (because the permissive Apache license will be compatible with Firefox’s overall MPL license), but your Apache webserver won’t have any Mozilla-licensed code any time soon (because MPL will still be more restrictive than the Apache Project’s overall Apache license.)

To be slightly more precise, one can say that permissive License P is one-way compatible with restrictive License R when:

Anyone who complies with all requirements of License R would also comply with all requirements of License P.
Everything permitted by License P is also permitted by License R.

In other words, License P and License R are compatible if, as long as you play by the more restrictive rules set by License R, you’ll also be playing by the rules set by the more permissive License P. So, making two licenses compatible is an exercise in making those rules align.

A good example of these subtle incompatibilities is between MPL 1.1 and Apache 2.0. In certain circumstances, a patent litigant could trigger Apache 2.0’s patent peace clause without triggering MPL 1.1’s similar (but slightly different) patent peace clause. This made the two licenses incompatible in the sense used here. Aligning these triggering conditions is what allowed us to be more comfortable that Apache 2.0 and MPL 2.0 are compatible. In other words, complying with MPL 2.0’s patent requirements will allow someone to be comfortable that they’ve also complied with the patent requirements of any Apache-licensed code contained within the MPL-licensed project.

#Why is compatibility between copyleft licenses hard?

Compatibility between copyleft licenses is tricky because a major reason (in some sense, the major reason) to use copyleft licenses is that new software based on the original software must also be available under the same copyleft license. This was originally intended to protect against proprietary licenses, but it also has the side-effect of “protecting” against other copyleft licenses. GPL does this by requiring that a user must convey the entire program’s source code “under the terms of this License.” Similarly, MPL 1.1 says modifications are “governed by the terms of this License.” These requirements are the central feature of these copyleft licenses,and they are contradictory - if the GPL (or a similar copyleft) requires all components of a program be distributed under the terms of the GPL, and the MPL requires all files under the MPL to remain under the MPL, then (at least under the most common interpretation of the GPL) you can’t put MPL files into a GPL program. The same problem will crop up with any two copyleft licenses whose scope overlaps, and this is the challenge that anyone who wants to make copyleft licenses compatible has to resolve.

#Can we do better than a dual-license?

The traditional solution for compatibility between copyleft licenses is to dual-license the code, allowing someone to use under either license as necessary. This approach obviously works, but it allows anyone to trivially create incompatible code by distributing changes under only one of the licenses, instead of both (or in the Mozilla case, all three) licenses. Once that happens, voila - whether intentionally or not, you’ve created code that the original project can’t use, defeating the whole point of the copyleft license and making it harder to use the new code. This can’t be completely avoided, but we wanted to find a different approach that would limit the circumstances where this could happen.

#So how does MPL 2 handle this?

Our solution was the second sentence of MPL 2.0 Section 3.3:

If the Larger Work is a combination of Covered Software with a work governed by a Secondary License, and the Covered Software is not Incompatible Software, You may additionally distribute such Covered Software under the terms of that Secondary License, so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or that Secondary License.

This clause permits someone to combine MPL and GPL (“Secondary License”) code, and distribute that combination (the “Larger Work”) under the other license, but with two key features that help keep code under the MPL for as long as possible:

First, the Larger Work must be “a combination of Covered Software with a work governed by a Secondary License.” So you can’t just say “I really prefer GPL” - you must combine with another, existing GPL work. Compare this to a traditional dual-license, which does not require you to combine - you can just roll out of bed and say “I’ve decided to be GPL-only.”
Second, you can “additionally distribute” under GPL. In other words, you must also comply with MPL, and must make available to your recipients under both MPL and GPL. Someone downstream from you can “at their option, further distribute” under GPL-only or MPL-only - as required by GPL - but you don’t have that option. This ensures that one distribution is done under both licenses, and those changes therefore have at least some opportunity to be merged back into the upstream release. Again, this is superior to the dual-license, which can’t guarantee any releases under a compatible license.

These clauses give us the best of both worlds. The interests of MPL users are protected by ensuring that it is only used when necessary, and that at least one initial distribution must be under the MPL - and therefore can be integrated back into the original project. At the same time, GPL users are protected by ensuring that there is still a useful path for reuse in GPL projects when that is necessary and makes sense.

#Why does all this matter?

MPL continues to grow as a license, and lots of MPL code has to do with technologies that are becoming increasingly interesting to free and open source developers - Javascript, network security, and so on. Making it easier for people across the free software community to use that code is a win for all of us. At the same time, lots of interesting work is being done under the Apache license as well, and making it easier for MPL users to incorporate that has the same benefit. With that in mind, this new compatibility is one of the biggest features of MPL 2.0, and one we hope will be widely understood - and widely used.

San Francisco Recommended Reading

Sun, 18 Sep 2011 00:00:00 GMT

Update: I’ve moved the most up-to-date version of this to this page. Leaving the original explanation below!

When I moved into San Francisco, I asked some folks about books I should read to get a sense of the history of the city. Here’s a sampling of the books that I’ve read since then, gathered in one place for the next time someone asks me the question. I’m still open to more suggestions, and suggestions need not be about the city as a whole- for example, my favorite book about New York was in large part about traffic and my favorite book about Boston was about the river.

Actually publishing this post, moons after writing it, is mostly in honor of today’s spectacular weather and my first ever bike ride across the Golden Gate. (And yes, the photo is cliched and I don’t care ;)

Why make a new open source software license? MPL 2.0 (part 3)

Wed, 14 Sep 2011 00:00:00 GMT

Originally published at opensource.com.

In my previous posts, I discussed the new features of the MPL and the new compatibility between MPL and other licenses. In this final post, I’ll summarize a few other small details about the new MPL that may be of interest to opensource.com readers.

#Why Does MPL Matter?

Whenever you consider writing a new license, there is an obvious question: why? Purely from the perspective of the MPL, the question is fairly easy: over the past ten years, how open source software is developed, how copyright licenses are interpreted and enforced, and the overall state of the art in free software licensing has changed. In light of these sorts of changes, it makes sense to reevaluate licenses on a regular basis and make sure that we’re still offering the best license we can. Of course, you can go overboard - no one wants to train lawyers and developers on a new license on a regular basis. The decade we waited seemed like a pretty good time period to us, and we hope that (barring significant changes in the law) this one will last another decade or two.

In the more general sense, it’s possible to ask “why do we need a mild copyleft license? Aren’t Apache or LGPL good enough?” The MPL’s mild copyleft strikes a balance that has worked well for Mozilla, and so Mozilla wanted to keep using it. That was a good enough reason to embark on the project. Over the course of the project, I also personally came to realize that there is an important place in the spectrum of free software licenses for a license that requires some sharing, but makes that sharing simple, clear, and without any strings attached. This is a common desire, but people aren’t always able to articulate it, and so they sometimes choose licenses that don’t do a good job of matching their needs. MPL has been that license in the past for a number of non-Mozilla projects and I hope that, with the new version, it will find even wider acceptance.

#What Took So Long?

Another common question has been “what took so long?” If you’re brilliant, like Mitchell, you can write one in a brilliant flurry of a few weeks, but for the rest of us, it takes time to get it right. Andrew Macgillivray of Twitter explained many aspects of the problem when discussing writing contracts:

[I]imagine the contract as a computer program. In each the object is to be able to interpret the words and have that interpretation drive a result. Now imagine that there is no compiler for your program and that you can’t run any tests. All debugging must be done only theoretically and in your head. … You and the other [coder] take turns editing the code but without a common coding environment or standard tools to figure out whether the other person (or you) goofed it up. Then imagine that the code you are writing has a high probability of only ever being “run” through two different interpreters with significantly conflicting points of view about desirable outcomes and you likely won’t get to see the result of any of these “runs.”

And Andrew was only describing a contract negotiated between two parties! In our case, all the factors he describes play into it, and many different constituencies had to be consulted. Each piece of their input had to be weighed carefully - both for the legal impact and to understand the possible motivations behind the suggestion. All of that without the equivalent of test-driven development.

Time constraints on a variety of the people involved also played a role, of course, but the generosity of my new boss both before and after I joined Greenberg Traurig helped deal with that, in a way that was more than most young lawyers have any right to expect.

#Open Source Tools

Three open source tools have been so helpful in our process that I’d like to give public thanks to their authors:

pandoc: The master document has been kept in the markdown format, and pandoc has been used to produce basically all versions of the document that you can see at mpl.mozilla.org (though some have been post-processed in a variety of ways). Responses to my occasional odd post to the mailing list have always been helpfully dealt with.
dwdiff: It’s important for lawyers to be able to see the difference between versions, but regular diff doesn’t cut it, because if you change one word, the entire paragraph shows up as changed. The solution was dwdiff. Not only has the tool filled an important gap for us, the author was kind enough to make some fixes in the code as well, making it easier for me to use.
co-ment: Besides traditional feedback tools like a mailing list and (gasp) the telephone, we’ve been using co-ment to gather comments and changes throughout the process. It’s been very valuable, and the comments collected there have led directly to changes in the MPL at each stage of the process, even from RC 1 to RC 2.

#Who Helped?

The list of people who helped with the new MPL is insanely long, so I’ll avoid a name-by-name review that will inevitably leave people out. That said, there are several classes of people who helped. The usual open source licensing suspects were all there: FSF, OSI contributors, and lawyers from major open source participants like Red Hat and Novell all read, reviewed, and had substantive comments. Major users of open source (some you’ve heard of like Intel and HP, and some you haven’t) also gave detailed and thoughtful analyses, particularly early in the process. Several independent lawyers (most notably members of the Freedom Task Force list) gave good feedback, particularly on European issues. A variety of Mozilla community members had thoughtful feedback, especially in explaining how and why MPL 1.1 had rough edges that needed to be identified and trimmed.

Finally, I’d particularly like to thank the great number of non-Mozilla, non-lawyers took the time to read the drafts carefully and give us feedback, whether through co-ment or other channels. This can’t have been fun; while MPL 1.1 was better than most legal documents, and MPL 2 (we hope) is even better, it’s still non-lawyers volunteering to slog through a legal document. That’s a big commitment to make, and many people did it anyway. Equally importantly, many of their suggestions bore fruit, both by giving us a sense of how the license is used in the real world and often by catching wording or language that was unclear and could be improved (that vs. which, for example). As a result, the final product was even better - and because of people who really probably had more fun things to do.

#Where Next?

We hope to finalize the license in the very near future, and with it, get OSI and FSF approval. In parallel, Mozilla (after some discussion) will adopt it for Mozilla products. After that? Well, I hope to be a great help to whoever writes MPL 3.0, and I hope that process happens in 2030 or thereabouts ;) See you then!

The Mozilla Public License - almost 2.0 (part 1)

Wed, 31 Aug 2011 00:00:00 GMT

Originally published at opensource.com.

Over the past 18 months, the Mozilla community has been revising the Mozilla Public License. See earlier post. We recently announced, in true community development fashion, a release candidate—the text that we hope will become MPL 2.0 after one last set of eyes review it. This piece is a brief backgrounder on what has changed in the new MPL, explaining why we’re proud of this work and we hope you’ll consider reviewing it - and maybe even using it for your next project.

#Clarity

One of the goals of the MPL has always been simplicity. For example, take the MPL’s copyleft. The rule is essentially a simple, bright-line test: does your file include part of an MPL-licensed file? If so, then the MPL governs; if not, then you can use the license of your choice for your code and the resulting binary. This is simpler and more straightforward than the tests for some other copyleft licenses.

With MPL 2.0, we’ve taken the focus on clarity and simplicity and extended it in two ways. First, and most obvious, we spent a lot of time carefully wordsmithing, even when we weren’t trying to change the meaning of the license. A good example of this was the language around “Initial Developers” in MPL 1.1. This language was originally intended to address important, but nuanced, issues around the timing of patent grants. After a lot of work, we were able to address the timing issue without using the “Initial Developer” concept - allowing us to make the license shorter and simpler.

Second, we worked to understand how the MPL was actually being used in practice, and simplify by bringing the license into line with that practice. Remember that when MPL 1.1 was written (starting in the late ’90s), large-scale community-driven software development was still relatively rare. It made sense to codify some rules and requirements in the license. Now that many of these community development practices are better understood, we could step back and see what we still needed to be specific about, and what we could be flexible about. For example, to the best of our knowledge, only one project ever used the LEGAL file discussed in MPL 1.1 Section 3.4(a). So we removed that requirement. (If you want to have such a file, the new Section 3.4 still ensures that it can’t be removed.) We also simplified the license header boilerplate - maybe the single most-requested change by Mozilla hackers.

#Internationalization

Mozilla has always tried to be a global project, but we were aware that the MPL had some clauses that made non-American users less comfortable with the license. One of these was the section on U.S. Government End Users. This was intended to protect the interests of all contributors to MPL-licensed projects, not just Americans, but to a non-lawyer (and even to many European lawyers) the meaning of the section was opaque. Our legal research, and the experience of the past 10 years, suggested it could be removed without impacting the U.S. government’s procurement process, and so we did so. Similarly, we’ve discussed every draft with FSF Europe’s European Legal Network, to help ensure that the new language works across jurisdictions, and brought the jurisdiction language into closer alignment with the practices of other open source licenses.

#Patents

In response to the changes in the patent landscape over the past decade, the patent language has been changed as well. In particular, suing someone over patents in MPL-licensed software will cause the litigant’s rights to that software to be terminated. This should help protect small contributors who don’t have patents, since copyrights - and other contributors’ patents - can now be used defensively. At the same time, the defensive clauses are now triggered only by a lawsuit over the MPL-licensed software, which should reduce uncertainty for some large companies.

#License Compatibility

At the request of our community, one of the focuses of MPL 2.0 was compatibility. We wanted MPL users to be able to use code from other permissively-licensed projects (particularly Apache-licensed code), and likewise to allow the broadest scope for reuse consistent with our copyleft. In short, we achieved that, but this issue is complex enough, and important enough, that I’ll write a post here at opensource.com about it in the near future.

#What’s Next

Because we published the release candidate in true community development fashion, we are also getting another typical part of the open source experience - people coming out of the woodwork with detailed observations close to the final release. This is great; it’s hard for laywers to to a .0.1 release, so the more eyes looking at our “code” the better. You can help too by reading the license.

Making HTML Legal Documents (Like MPL) Look Good

Mon, 22 Aug 2011 00:00:00 GMT

A few months ago I bought “Typography for Lawyers” (TFL), an excellent book that I would recommend to all lawyers. And since the biggest document I was working on at the time was, of course, published in HTML, I started spending a few minutes here and there on learning enough CSS to make the license look better. (Understandably, the book’s very pragmatic advice is focused on Word and Pages, not HTML.)

Fine Print by CJ Sorg, used under CC-BY 2.0 I’ve published the experiment (Compare with the plain-jane HTML MPL 1.1). [Update: the experiment is no longer available, but the official, final version of the license incorporates many lessons from it.] This is just an experiment and a personal hack, but I’m happy to hear more suggestions and improvements, and if the final result works, I’ll suggest we use it instead of the traditional plain HTML version. Some notes on the process, including links to the (abbreviated) blog posts at the TFL website (for much more thought and detail, buy the book):

Fonts: This was hard. The author of Typography for Lawyers is himself a former font designer, and (correctly, I think) a font snob. Given that I was not going to splurge for fancy webfonts just for this project, I spent a lot of time browsing and playing with Google Web Fonts. This is clearly not ideal (for example, it has only one monospace option for Exhibits A and B, and I’d like a slightly more subtle serif for the titles) but I think I found a decent combination of fonts – or at least an improvement on the system fonts. Presumably, if this became Official, some better font choices could be used.
Small Caps: I’d never given small caps much thought until reading TFL. The book is quite positive on them under certain circumstances, and that led me to experiment and eventually to use them as headers. Unfortunately, Google Web Fonts is limited here – none of the Google Web Fonts appear to have true small caps. TFL recommends strongly against fake smallcaps, but I think these look decent so I’ve used them; I’d be happy to replace with a better one if that was available.
Hyphenation and Justification: TFL does not necessarily recommend full justification, but demands hyphenation if you do fully justify. Since Mozilla just added support for hyphenation, I turned on hyphenation and justification, and I think it looks good (if you’re using a recent build.) In production, it would probably be better to either use something like hyphenator that works cross-browser, or use some sort of browser feature detection to turn off justification for browsers that don’t also support hyphenation.
Line length: TFL recommends something between 45 and 90 characters per line. (The Supreme Court’s well-designed documents are about 65 characters per line.) Unfortunately, as best as this CSS newbie can tell, there is no good way to do this simply in CSS. I ended up with a total hack, using the “alphabet trick” described in TFL to estimate the right width sildenafil tablets 100mg.
ALL CAPS: TFL IS AGAINST ALL CAPS FOR ENTIRE PARAGRAPHS. My experimental HTML version uses some gross CSS to create a highlighting box around the two traditionally all-caps blocks in the text.
“smart” quotes: We know that people copy and paste from the HTML version of the license into plain text files, even though (with MPL 2) we’re going to provide a very nicely formatted plain text version of the license. And of course, copying and pasting curly quotes into plain text gets… messy. And so, I am conflicted about this. The HTML linked above uses smart quotes, while the plain text uses straight quotes. Inevitably that will lead to some problems; suggestions on how best to fix (use javascript to modify what is copy-and-pasted if someone does that?) are welcome.

Of course, I’m still very bad with CSS and HTML, so I’m sure this document can be improved, and I’m happy to take suggestions and fixes. Regardless, it has been an educational experience for me and I’m glad I toyed with it!

Donated to the Ada Initiative

Wed, 22 Jun 2011 00:00:00 GMT

I’m excited to say that (with Krissa’s support and approval) I donated today to the Ada Initiative’s Seed 100 Campaign.

Free and open software and culture have been very good to me, and I’m glad that the Mary and Val (and hopefully soon a fleet of others) will be working to make it more accessible to women and girls. As big a force for change as this movement has been in the past two decades, things can only improve when we consciously work on being accessible to the 50% of the population that is currently all too often excluded.

looking for a programming analogy- if there is one

Sun, 17 Apr 2011 00:00:00 GMT

As I’ve mentioned before, there are a lot of analogies between programming and legal work.

I’m working on an upcoming post to explain a specific application of a legal concept. Unfortunately, I think this is one of those few concepts where there is not a ready programming analogy. I’d love for someone to prove me wrong, since the programming side of my brain is slowly going to pot. Here goes:

In law, there is the concept of “rules” and “standards.” Basically, rules are precise- they allow a judge to simply look at the facts, apply the rule, and voila- you know whether the rule was violated. An example would be “The speed limit is 55.” If you’re driving 56, you’re in violation- even if, say, you’re speeding to the hospital with your pregnant wife. Alternately, if you’re driving 54 you’re fine- even if it is pouring rain. Rules are good because they are easy for the public to understand (no need to consult with a lawyer) and because their application (should be) very evenhanded, but good, fair rules are very hard (in many cases essentially impossible) to write.

A standard, on the other hand, is more vague- something like “The speed limit is whatever speed is safe to drive at under the circumstances.” This might not allow you to go 56 to the hospital, but would definitely not allow 54 in the rain. These are bad in some ways because they are trickier, case-by-case, hard to predict the outcome of beforehand, and involves judgment on the part of all parties, but (arguably) produces better outcomes a lot of the time- assuming you can trust the parties doing the judging, and you can put up with the cost of taking the time to make the decision.

So… for those of you who have lasted this long: are there analogies to this in software? The closest thing I can think of is strong typing vs. weak typing, but generally, since computers are incapable of dealing with standards, there aren’t many examples I can think of. Am I missing/forgetting something?

Brilliant.

Fri, 01 Apr 2011 00:00:00 GMT

Saw this for the first time on my drive to work yesterday:

Congrats to all my friends on a very solid release and on reinvigorating their important message of public service.

MPL Beta 2- as FAQ

Thu, 31 Mar 2011 00:00:00 GMT

I’m still working, albeit sometimes slowly, on the new MPL. Two days ago we announced the release of Beta 2- you should go read it :)

Besides the usual (small tweaks to some language in a further attempt to get it Just Right; improvements to the GPL language; etc.) I also published a bit of an experiment: a draft of the license which replaces the traditional section headers with FAQ questions, like so:

Traditional:

2.2. Grants.

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: …

FAQ-style:

2. What rights are granted to me by this license? Who are these rights granted by?

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: …

The inspiration for this came from the apartment lease I signed in December, which was done in this style and (oddly) almost a pleasure to read.

This approach has two advantages. First, it helps you draft and organize things more clearly. Since every paragraph was the answer to a question, things were broken up into what normal human beings would consider more logical units, instead of the giant blocks of text legal documents sometimes sprawl into. Preparing the FAQified version of Beta 2 made us aware of some MPL sections that had this problem, and it helped us reorder and reorganize text as a result- something which you can see in (for example) the new Section 8 of MPL 2 Beta 2, which is part of the old Section 9 broken out so that it makes more sense independently. Because of this, these changes will help every reader of the license, even if we never publish another “FAQified” version.

Second, the questions clue a reader in to the key concepts of a section. It is important that people still read everything. We’ve tried to ensure that the questions do not change the meaning of the “answers;” i.e., the body of the text, both by ensuring that the “answer” or body text is the same between both versions and by disclaiming any changes in the license itself. In other words, this will help non-lawyers understand- but if for some reason, you need to be absolutely sure, you (and possibly your lawyer) need to read the whole thing carefully and without reference to the questions.

We’re looking forward to feedback on this, both from non-lawyers (does this help you understand?) and from lawyers (this is an unusual technique, and so suggestions on how to do it better are welcome). So download it, read it, and let us know what you think.

[postscript: The first comment reminds me that this is only one of the steps we’ve taken to simplify and clarify the license. Most notably, Beta 2 is almost exactly 1/2 the length of MPL 1.1, but we’ve also worked with Mozilla folks to simplify requirements where the old license was over-specific, and with lawyers with a reputation for good writing on how to simplify language and remove redundancy. But there is still time to make it even better, so please continue reading and giving feedback!]

Other Ways to Slice Revenue Pies

Sun, 27 Feb 2011 00:00:00 GMT

A large company with a distribution network, and a little guy with something nifty to distribute walk into a bar…

Step 18 / Rex Roof / CC BY 2.0

[NB: Nothing here is legal advice; just business advice. I do not represent either the GNOME Foundation or Canonical, and have not talked to either one of them about this, though I have had a brief email exchange with the Banshee guys.]

There are a lot of ways to figure out how to slice revenue pies, but you wouldn’t know it from watching people talk about Banshee and Canonical. The options discussed seem to be all, nothing, or some percentage in between. This post will discuss one alternative, and hopefully provide food for thought when people are making their own revenue arrangements.

We can start by taking a step back and looking at factors besides labor and power, which seems to be what lots of folks have tried to boil this particular situation down to. Each situation has unique issues, but two which I’ll talk about here are what the money involved means to the various parties, and where else value is being created.

On “what the money means”: sometimes money is just money. But more frequently money has different meanings to different groups, depending on how big they are, where they are in life (as a person or organization), etc. So $10K may mean very little to a big company, but it might mean the difference between college and no college for an individual coder, or between an event and no event for a small non-profit. On the flipside, the difference between $1M and $2M might not mean much to an individual (diminishing marginal utility ahoy!) but it might mean the difference between growth and layoffs for a small-to-medium company. I can’t speak with any certainty here, but my guess is that $10K can easily be a big deal (like a hackfest) for GNOME, and … well, I really hope for their sake that $10K doesn’t make much difference to Canonical :) On the flip side, $1M might be more money than GNOME is ready to handle, while $1M would likely be a significant help to Canonical as it seeks to become a stable, sustainable business.

On “where the value is being created”: This is not a simple question. But when you’re talking about people who distribute a good, it is usually fair to consider not just what they are doing to distribute the good (which might be minimal, particularly if the good is digital) but what they’ve done to build their distribution network and make it popular with consumers (which might represent a lot of work.) At the same time, creators haven’t just created something- they’ve also passed up other opportunities and taken risks to do whatever it is they do. By that token, it is safe to say that without the Banshee team there would be no Banshee to distribute. No one has anything if they didn’t do that work. At the same time, Ubuntu multiplies the value they did create by working to increase the number of people who use desktop Linux- and therefore who can use Banshee. So both of them have created some value here- maybe that balance isn’t 75-25, but it isn’t 100-0 like some folks seem to be suggesting either. ((If you don’t like this, I suggest channeling your energy into writing a true cross-distro Linux build and installation process.))

So how do these factors affect the deal itself? The critical point to take away from the examples above is that one number doesn’t fit all- what might be the right percentage for the first dollar might not be the right percentage of the millionth dollar. A sliding scale for revenue sharing can address this by giving one party a lot of the early, smaller revenue, and the other party a lot of the later, larger revenue. In this example, you could set it up so that of the first ____ dollars, Banshee/GNOME gets the (vast?) majority; they split the next ____, and then anything past that- the big bucks that result at least in part from Ubuntu’s big audience- Canonical gets the lion’s share.

Take your pick for the exact numbers, of course- the point being that this more flexible framework, instead of a straight 25-75 split, might leave all parties with a better chance of meeting their goals. While the money is small, GNOME gets what to it is important revenue, while Canonical loses out, but only on (probably) pocket change. If the money involved ends up being really large, GNOME still benefits a lot (having gotten a large share of the early money), but Canonical gets a revenue stream that will help it build a sustainable business. This kind of split also better reflects where value is being created- the Banshee guys get lots of immediate revenue for having created great software, and (if a huge number of people use it to buy music) then Ubuntu gets value for having done the hard work to make the platform as a whole accessible to those huge numbers of people.

Again, I haven’t really talked to the parties involved, so take this with a grain of salt- it might not fit this example, and it almost certainly won’t fit your situation without more thinking, tweaking, and perhaps use of a different tool for splitting revenue. But as more FOSS projects and the companies that deal with them start to have these sorts of revenue streams, it will be increasingly important to get creative about how to distribute that money. I hope this post can help remind people to think beyond a simplistic X/Y split, because being creative about this sort of thing can help everyone build sustainable models that help finance good software for more people.

publicly thanking dwdiff

Wed, 25 Aug 2010 00:00:00 GMT

High on the list of things I really enjoy doing is thanking people who contribute to free software. Also high on the list is using software that works well.

So I just wanted to combine the two and say a public thanks to GP Halkes, for writing and maintaing dwdiff. I’ve been using dwdiff since early on in the MPL process, and thanks to two recent changes GP made at my request, it now works even better for my needs (and hopefully better for most people’s needs.) Thanks, GP!

Notes on Diaspora Talk

Fri, 20 Aug 2010 00:00:00 GMT

Diaspora came to lunch at Mozilla today. Some notes.

They gave me a nice shoutout. ;)
They’re doing pair-programming and test-driven development this summer, which I think is great. Sounds like they’re getting some great guidance from Pivotal Labs.
Very explicitly trying to focus on things everyone can use, rather than something for geeks.
Are trying to do micro-networks, rather than ‘everyone on the same plane’; I’m curious to see where that goes.
They’ll have single-user ‘seeds’ or multi-user ‘pods’ for servers. Push-driven, like email.
They’re doing Rails and Mongo, and even Websockets; they’re having problems between Websockets and Rails.
Planning on doing a code release by ‘flipping the github bit’ on September 15th, but will continue hacking after that, since they have a ‘low burn rate.’
Seem a bit worried about the community management problem once they go live.
Have a slide describing feature set for beta; focus on easy group management for you and close friends; private broadcasting to those friends; full data exportability.
Longer term: work with ostatus/other stuff to work closely with other distributed technologies; plugin and application infrastructure; build community and focus on design.
Anonymity is not currently a design goal, but still thinking about basic crypto and heavy focus on privacy (including privacy expectations-setting.)
In the move to california, they appear to have abandoned arepas for tacos. Bad news.
I admit I’m troubled that there is lots of talk about technology, and not much talk about UI/HCI/design, but in response to my question they say they mostly didn’t talk about it because it is still very much in flux. They’re talking with others about the problem, which is good to hear.

Anyway, interesting stuff- I continue to wish them well.

The Libre Web Application Stack (A Code Story)

Mon, 09 Aug 2010 00:00:00 GMT

[This was originally published at autonomo.us- comments over there.]

[Disclaimer: since my last post at autonomo.us, I have become an employee of the Mozilla Corporation. I don’t feel this has tainted my views, but feel free to weigh that information as part of your analysis of this article. Relatedly, I do not speak for that employer when writing here; my words and ideas here are my own.]

tl;dr version: We shouldn’t throw the baby out with the bathwater. The bathwater is the ethical problems with software hosted on someone else’s server; the baby is the strength of the libre web application development stack- which may actually be the best platform for building autonomy-preserving user-oriented software.

Put yourself in 1995. I’m going to tell the you of 1995 that in 2010, there will be a software platform with the following properties:

The widget toolkit for this platform will have two independent, competitive, Libre implementations; one of those implementations will be the most widely used consumer-facing piece of free software ever, and the other one will have the support of the second and third largest software companies on earth.
Tens of millions of dollars a year in engineering time will go into improving those free implementations of the standard; in fact, Microsoft will spend lots of money and PR time saying ‘we’ve caught up to the libre implementations.’
This widget toolkit will have no vendor gatekeepers or tolls; in fact, all the biggest software vendors on earth will have attempted to disclaim patent claims against it, making it not only no-cost but also perhaps the safest free software toolkit available from an IP perspective. New additions to the toolkit will be free by default; there will be some exceptions to this but those exceptions will be bitterly contested, sometimes with huge proprietary software companies weighing in on the side of free implementations.
The major implementations of the widget toolkits will be extensible using a simple scripting language, making them much easier for users to customize than most (non-emacs) toolkits.
Free software written for this platform can be made trivially available not just to users of free operating systems but also to people on other platforms, potentially helping grow the community of free software developers and users.
This widget toolkit will be available on every computing platform on earth; not just PCs but also many phones and soon on TVs. If your hardware supports this widget toolkit, it immediately has enough applications that it is considered commercially viable, leading to an unprecedented blossoming of operating systems platforms (unlike the situation in 1995, where new platforms have no apps and so find it impossible to compete with Win3.1/95.)
The logic and data storage systems backing this widget framework will also be varied- there will be proprietary implementations, but there will be dozens if not hundreds of free frameworks as well, in essentially every programming language you can imagine. It is taken for granted that these frameworks run on Linux first. Among many others, the White House will use such a free framework to deliver software.
At the same time, because of elegant design, it is easy to swap out backends, so if you want to write backends in different ways, you can do that; in fact, people are taking advantage of this every day to write completely new frameworks with a variety of different properties.
A function called ‘view source’ is viewed as a key competitive differentiator in this platform; it is actually hard to close the source describing widget layout and behavior (though easy to close the backend.)
Millions of high school kids are taught (at least part of) this framework; millions more will have taught it to themselves using view source!
This platform will have been so successful that virtually every single first-world computer user will use it (in some way) every day.

At this point, 1995-you says ‘This sounds too good to be true. There must be a catch.’ ((This is true whether 1995-you is a free software fan or not; if you’re a free software fan, you’re particularly excited, but if you’re a die-hard silicon valley capitalist you should also be pretty excited by the potential of this platform.))

There are two major catches, the second a consequence of the first. ((There are plenty of minor catches too; performance isn’t great; the widget toolkit does not have the vast variety of widgets that more mature toolkits have. But these have been improving consistently for years, and (more importantly) they’ve been improving much faster than traditional toolkits have improved.))

The first catch is that the default data storage architecture is distributed, and the default licensing is effectively permissive, making it expected (though not mandatory) that users are separated from both the code they run and their data. In other words, developers who use this stack are perhaps more free than they’ve ever been in the history of computing (and not surprisingly they’ve adopted it in droves)- but users often have even less control than they had when they were using traditional proprietary desktop applications.

The you from 1995 would probably think that freedom-lovers would have reacted to this unfreedom by rewriting the thinlayer of proprietary code sandwiched between gigantic gobs of free code, and/or by working to make the platform more amenable to local or distributed use. You might expect that they would even have embraced and extended the platform to make it even better for freedom.

Instead, the second catch is that fans of freedom have largely thrown the baby out with the bathwater, ignoring (or at best failing to embrace) this rich, free platform. Instead, in a story straight out of the Innovator’s Dilemma, they’ve continued to focus on traditional widget toolkits and interfaces which lack all the benefits I’ve just listed out.

It should be obvious by this point that the platform I’m talking about is HTML and the many, many application frameworks that can be used to generate it. This platform- what I’ll call the libre web application stack- is not perfect, but it has the potential to be hugely freedom-enhancing, and free software advocates should carefully consider it when thinking about developing their next app, or when planning to extend traditional software platforms to make them more free. Just because most web apps are not free does not mean the stack itself should be disregarded.

Notes on Arthur Bestor's 'Backwoods Utopias'

Thu, 05 Aug 2010 00:00:00 GMT

A few months ago I finished reading Arthur Bestor’s ‘Backwoods Utopias‘, a book on the Utopian social-communitarian movements of the pre-Civil War US. Some belated notes on the book’s themes follow.

The average high school US history textbook gives a thumbnail sketch of these movements, but for those who didn’t get that or don’t remember it, the gist is that, from very shortly after Europeans reached North America until right around the Civil War, groups of people regularly launched themselves into the North American wilderness, trying to found new communities organized around communitarian and egalitarian principles. They met with some success, but eventually the movements petered out, with none of them truly surviving into the modern age.

Robert Owen (untitled) by BinaryApe, used under CC-BY

The tie from this book to my own interests should be clear, but if not, I should make them explicit: free and open source software often thinks of itself as being sui generis, but in fact it is part of a history (in this country) of retreat from established economic structures with the intent of creating parallel systems that would eventually compete with or replace those established structures with something simultaneously individually empowering and socially just. (See also.) I’m both personally and professionally curious about gleaning lessons from such past experiments- so I picked up the book. If any of this blog’s readers have suggestions either of more histories of this movement, or of histories of other similar movements (watch this space for a post on the local food movement soon), please do let me know in email or comments.

Unfortunately, Bestor’s intended follow-up book (covering the 1840s to the end of the movement) was never completed, which limits the lessons that can be drawn about the decline of the movement. Nevertheless, some observations and themes from the book:

The movement had a broad spectrum of motivations and philosophies- some were heavily religious, while others were overtly anti-religious; some had (or were intended to have) quite complex governance systems, while others were nearly anarchist, and indeed Marx condemned them in strong terms because (to over-simplify) they were not dedicated to fighting the good fight in the cities. Interestingly, while the community focus of these groups was typically very strong, in modern terms we might also call them libertarian (or what Erik Olin Wright calls ‘interstitial’ revolutionaries): they all believed that they had the right and the ability to make a better world by striking off on their own, rather than working within or against established structures.
Religion was initially a major motivating force; this faded over time, but Bestor does not make it clear why later groups tended to be non-religious. Interestingly, American critics of later movements like Owenism apparently tended to focus on this non-religious aspect, rather than the practical/anti-capitalist issues modern critics might focus on.
As with every movement, looking at who left is often as important as understanding who stayed. In particular, Bestor mentions that when pragmatists became frustrated and left New Harmony (perhaps the highest profile of the various communities), those left behind were a combination of those too lazy to leave and those too fanatic to leave. This was a huge problem for the morale of the remaining pragmatists, who resented the free-riders and were driven nuts by the fanatics, and so they repeated the cycle.
Relatedly, Bestor argues that the repeated talk of ‘everyone will live in our miraculous new society any day now’ meant that many newcomers were not prepared for the long haul; that may have disillusioned some people and contributed to a sense of lack of momentum. To paraphrase Bestor, ‘a new society cannot be built on excuses.’
When the movement started, it was actually pretty easy to get a community going- lots of land was effectively empty, and the median community size in the US was in the low hundreds, making it quite easy to form a community that had all the ‘comforts’ (such as they were) of traditionally organized communities. As time progressed, two things began to work against this: first, more and more ‘normal’ landowners migrated to the midwest, causing land to become more scarce, and second, even the smallest villages became larger as the country’s overall population grew. This meant that finding enough space for a ‘basic’ community became a much more capital intensive process over time. Not coincidentally, later communities tended to have wealthy patrons- with all the plusses and minuses that brings.
As economic complexity increased (more machinery, more specialists) it became harder to create a self-sustaining village, especially if your human capital stocks were limited to ‘believers.’ For example, when the movement started in the late 1600s/early 1700s, having a self-sustaining community required very little specialization, while by the mid-1800s, it was understood that you needed machinists and manufacturers who would trade with other areas. Bestor says that New Harmony was bitten by this, as the land they bought for the town had the hardware for extensive wool manufacture, but lacked the people familiar with the machines, killing an expected source of financial sustainability.
Over time, some of the social goals of early communitarians became more broadly accepted or supplied by other organizations. For example, public education was a significant goal of New Harmony, but over the course of the 1800s, that became more common in non-utopian communities. New Harmony also had a concept of mandatory social insurance; unions started providing similar services in the late 1800s. This again made recruitment harder.
As for most world-changers, the gap between theory and practice was often large. Robert Owen, the wealthy patron of New Harmony, created an elaborate philosophical scheme intended to encompass everything from the individual to the nation-state, but he was bad at creating practical schemes, which led to constant reorganizations at New Harmony. This may reflect the extreme difficulty of organizing a full society; capitalism has the advantage of being simple and direct in general scheme relative to a centrally planned society like Owen’s.

I’ll refrain from drawing any direct conclusions for free and open source software here, in part because many of them will be obvious to many of my readers, and also because my reading of the book (especially several months after the fact) is inevitably heavily biased by my own thinking about social movements like this one, so I’m not sure whether any ‘lessons’ would reflect actual history or just my interpretation (compounded with Bestor’s.) With or without direct applicability, though, the book was an interesting read for a history nut, and left me with a lot of food for thought.

100 Words for my Friends Taking the Bar Exam

Thu, 15 Jul 2010 00:00:00 GMT

Things I did to myself before the bar:

Did only a fraction of the practice I should have.
Felt underprepared and terrified, just like you feel now.

Things that happened to me during the bar:

Day before the exam, while studying poolside at the hotel: got a sunburn.
First day of exam: stung by a bee.
Last day of exam: computer crash, requiring me to handwrite the last section of the exam. Haven’t hand-written for three hours straight since college.

And I still passed. Even got invited to be a grader.

So: moral of the story: don’t panic; you’re not as underprepared, and it isn’t as hard, as you think it is. You rock. You’ll pass.

Some Followup Thoughts on Bilski

Wed, 30 Jun 2010 00:00:00 GMT

Some Third-Party Thoughts

A friend summarized Bilski this way: “Shorter #Bilski: Federal Circuit, your rule was too straightforward and didn’t add enough uncertainty to an already volatile field.”

I don’t think that was actually the court’s intent, but certainly that will be the short-term outcome. Long-term the court and the PTO will have to find new rules. Patently-o has some thoughts on how that process might play out, and the PTO has issued the following guidance to patent examiners on the topic. The PTO memo, while preliminary, is a great simple summary of the ruling, and contains the following critical passage:

If a claimed method does not meet the machine-or-transformation test, the examiner should reject the claim under section 101 unless there is a clear indication that the method is not directed to an abstract idea.

In other words, the PTO has reverted to the pre-business-methods ‘machine-or-transformation’ test as a default, with the burden of proof shifted to the patent filer to show a ‘clear indication’ that their non-machine/non-transformation is not an ‘abstract idea.’ It will be interesting to see in coming months what the PTO accepts as a ‘clear indication’; I would expect that this won’t be a high bar to clear, but it will probably cut out some of the most egregious applications.

For an optimistic take on the whole thing, check out Rob Tiller’s piece at opensource.com.

Comments on the Concurrences

Yesterday’s train ride focused on the majority opinion. However, as I noted then, the voting patterns here are complex; complex enough that there is some important law to be found in the two concurrences. The patently-o post I linked above makes a particularly astute observation in this regard. So today’s train ride I’ll try to read and share some thoughts on the concurrences, particularly the ‘swing’ concurrence from Breyer and Scalia.

The first thing to note is that the Breyer/Scalia concurrence opens with a strong support of Stevens’ opinion that business method patents are not patentable, but that this part is… only signed by Breyer. So it does not tell us much. The rest of it focuses on four (really three) points which Breyer and Scalia feel the entire court agrees on. If you read only one part of the opinion, read this part- it is short, sweet, and to the point, and because at least five (possibly nine) members of the court agree here, it will likely be the jumping off point for the next round of patentability litigation. These points are:

There are many things which are unpatentable. This seems uncontroversial (the court was quite explicit about it in 1989’s Bonito Boats case), but after the Federal Circuit’s expansion of patentability through the 80s and 90s, it was perhaps not as clear as it should have been. This concurrence makes it very clear (once again) that there is a line, even as it simultaneously announces that no one knows where the line is. It could also be interpreted as a subtle hint to the Federal Circuit that they should set to finding that line. (Gottschalk v. Benson, which held that algorithms are unpatentable, is cited approvingly here; as I mentioned yesterday, Gottschalk and Flook may have been given some second wind by Bilski; possibly the best thing that anti-software patent crusaders can salvage from this.)
Transformation of a thing to a different state is a “very good clue” (point two), but not the only clue (point three), as to whether or not non-machine things are patentable. The Federal Circuit’s Bilski ruling had essentially declared this ‘machine or transformation’ test to be the only test, which was what made business methods unpatentable under that ruling. Again, Flook is cited approvingly (when saying that it is a strong test) but unfortunately Gottschalk is cited to show that it is not the only test- which is exactly the loophole that State Street (the case that allowed business methods) drove through.
The ‘useful, concrete, and tangible result’ test that the Federal Circuit put forth in State Street- i.e., the case that allowed business patents- is not a good test, sometimes producing patents that range from ‘the somewhat ridiculous to the truly absurd.’ In other words, something can be ‘useful, concrete, and tangible’ but still not be patentable. This last point was highlighted by Patently-O yesterday as being fairly important.

If you’d told anti-software patent/anti-business-method patent folks on Sunday that the court’s Monday ruling would have five justices (or maybe nine) justices agreeing that the ‘useful, concrete, tangible result’ rule was bogus, they’d have been pleased. Of course, they’d have expected the court to enunciate a new, replacement rule- which has not happened. It is that gap which has caused so much consternation, not just for patent critics but also for patent supporters.

It will be up to the Federal Circuit to try and find a new rule, somewhere between ‘machine or transformation’ and ‘useful, concrete, tangible’- and this almost certainly means that we’ll be back at the Supreme Court arguing similar issues within a few years, asking the court to ratify- or reject- the next Federal Circuit attempt.

In trying to figure out what Scalia actually agreed to, I’ve now read sections II.B.2 and II.C.2 (which Scalia did not sign on to) a couple of times. They are, like much of the decision, a little rambly; long on vague assertions about the current state of things (lots of talk about the ‘Information Age’) and not very strong on details or particular policy conclusions. If I had to guess (and I should stress that this is just a guess) Scalia is really reacting to the mechanisms used to reach these vague conclusions, which tend to be very divorced from the actual statutory text that the main body of the decision relies on. So probably not worth reading much into that.

The Stevens concurrence… that will have to wait for another train ride. Suffice to say for now that it is a thorough researching of a difficult question. It is certainly not perfect, but is the kind of dedicated textual and historical reading that many members of the court pay lip service to but do not consistently practice.

First thoughts on Bilski

Mon, 28 Jun 2010 00:00:00 GMT

Some very preliminary thoughts on Bilski, written in the course of one train-ride to work. This does not represent the viewpoint of my employer and should not be taken as legal advice; merely observations on one ruling.

In the lower court (Federal Circuit) ruling on this case, the Federal Circuit was very aggressive in trying to limit business method patents by applying an old rule very, very broadly. The Supreme Court here reached the same conclusion about the specific patent at issue (holding it not patentable) but chastised the Federal Circuit for their aggressiveness in going from step 1 (invalidate this particular patent) to step 2 (invalidate all business method patents). At the highest level, this is not good for opponents of software patents- this is the most change-averse patent opinion the Supreme Court has issued in recent years, and it will leave the Federal Circuit very reluctant to broadly attack entire classes of patents in the near future. But the court did not completely bar such attempts, and it also strengthened some older anti-software-patent rulings, so it is not a complete loss for opponents of business method and software patents.
This was a very splintered decision- while every judge agreed in the outcome, no part of the opinion got more than five votes, and many parts got only four. This probably explains why it took so long, and why Stevens was not (as widely anticipated) the author of the majority opinion- one or more judges probably were swinging between the two opinions until very late in the process. The addition of the probably pro-business Judge Kagan to replace the (effectively) pro-technology Judge Stevens could make future cases along these lines more conservative. And the court itself basically admits in their first section that this is hard; saying of the Federal Circuit’s ruling in the case that “Students of patent law would be well advised to study these scholarly opinions.”
The court punts on the most difficult questions, quite explicitly: “This [Information] Age puts the possibility of innovation in the hands of more people and raises new difficulties for the patent law. With ever more people trying to innovate and thus seeking patent protections for their inventions, the patent law faces a great challenge in striking the balance between protecting inventors and not granting monopolies over procedures that others would discover by independent, creative application of general principles. Nothing in this opinion should be read to take a position on where that balance ought to be struck.” [emphasis mine.] Unfortunately, this buys into the rhetoric that all inventors are patenters, but otherwise makes it explicit that the court is staying out of the deeper policy question to the greatest extent it can.
Core of the decision is to set up a very conflicting set of tests: business methods can in some circumstances be ‘processes’, which are patentable, but they may also be abstract ideas, which are not patentable. (The lower court had said that business methods are never processes and therefore a court did not need to ask ‘is this an idea?’ before ruling that it was unpatentable.) So future seekers of business method patents (and presumably software patents as well) will have to thread the needle, showing that they are a process (probably not difficult after this ruling) but also that they are not an abstract idea (may be hard, not clear yet.)
Needless to say, this kind of gap is the kind of thing that sophisticated lawyers love to drive trucks through, and which will continue to create lots of uncertainty for small innovators for whom even the threat of a patent suit is enough to stop innovation.
When deciding that the patent is an idea, and hence unpatentable, the court has kind things to say about Benson and Flook, two older case which spoke against patenting algorithms but which were then sort of ignored. This may signal to lower courts that they should take these cases more seriously when looking at software and business method patents, which would be a good thing for anyone who is seriously interested in the quality of software patents and not the worst possible outcome for those who believe that all software patents should be banned- these could become potent weapons against some of the most outrageous patents on algorithms.
At the same time, the court also speaks well of Diehr, another older case. This case has generally been interpreted to stand for the idea that a combination of software with hardware (originally, use of software to control a rubber curing machine) is patentable, but the court here seems to read it more broadly, arguing that Diehr should be interpreted to mean that algorithms combined with any new processes (whether mechanical or otherwise) might still be patentable.
The court specifically tells the Federal Circuit that the method of restriction it had been using is barred or weakened (not great for those who dislike software patents) but also specifically says that the Court can and should explore new methods of limitation as long as they are consistent with the text of the patent act; seemingly implicitly stating that the pre-Bilski situation (where business method patents ran rampant) was untenable. This suggests to me that we’ll see a period of several years of experimentation in the Federal Circuit, where the Federal Circuit attempts to find new ways to limit business method patents on something other than a case-by-case ‘I know it is an idea when I see it’ rule of thumb.
The court specifically says that they did not want to create uncertainty for software patents, citing the pro-software-patent amicus briefs, but then goes ahead to create such uncertainty by allowing the Federal Circuit to find new, narrower tests. However, these two sections of the majority holding got only four votes; Scalia did not join this part of the otherwise majority opinion- presumably because it seems to give the Federal Circuit very wide interpretive powers.
The Stevens opinion, at a glance (remember, brief train ride) would have been much more amenable to the anti-software-patent crowd, but I imagine that it is exactly this quality that made it the minority opinion.

I’m afraid that at the end of this brief train ride, my only firm conclusion can be that the real winners here are patent lawyers- this decision creates no new certainties, only uncertainties, which will encourage patenters to spend more money patenting things, and the rest of us to waste time and energy worrying about the problem- time and energy that should have been spent on innovating. But this is a long, multi-layered ruling, and will require a lot of time for the full implications to be truly understood, so take this one-train-ride blog post with a large grain of salt :) Hopefully more writing tonight/tomorrow.

some data points on facebook

Fri, 14 May 2010 00:00:00 GMT

My boss has written a blog post that tries to bring together some recent data points from across the privacy spectrum; it is worth a read. I’ve been noting a few (much smaller, more trivial) things myself over the past few days that suggest to me that privacy concerns in general, but facebook-related privacy concerns in particular, may be reaching a bit of a critical mass.

No Facebook by avlxyz used under CC-BY-SA.

Some anecdata:

A graphical interpretation of Facebook’s default privacy settings. Putting aside the content and cool presentation, I’ve been seeing this all over the place the past week- it seems to be resonating with a surprising (to me) number of people.
Danny Sullivan notices that searching ‘how do I’ on Google… automatically suggests ‘delete my facebook account.’ Again, not hard proof of anything, but suggestive that this is of trending interest. (Note that the trend is particularly trendy in… NYC and LA?)
I would have expected that Diaspora would have a hard time getting to their $10K goal; instead they’ve raised $136K (and >$27K of it from donations >$350.) I raise this not to say that they will succeed, but to point out that their fundraising totals suggest that there is a pent-up interest in this area.
James Kwak, a finance blogger (albeit an ex-technologist) blogging about deleting his facebook account. I’ve seen plenty of technologists of various stripes talking about deleting facebook accounts for a while now, but this is the first time I’ve seen someone talking about it in a vaguely more mainstream setting. It is hitting the mainstream media too.

These are just anecdotes, and not real data, but to me this feels vaguely different from the ‘rebellion’ in 2006. At that time I said ‘people adjust and things blow over sometimes.‘ This one feels different to me, but that is just a vague feeling; it may stem as much from my own facebook fatigue as from any concrete reality. It will be interesting to watch, at any rate.

responding to joindiaspora

Sat, 08 May 2010 00:00:00 GMT

The joindiaspora guys, in a generally good response to my questions, conclude by asking:

[W]hat would be un-pragmatic about giving four excited dudes who spent their last semester of school thinking about a problem you are “worried-about-but-can’t-deal-with-now,” twenty bucks so they can take an honest crack at solving it? :)

Lots of people asked some variant on ‘it is just $20’ or whatever. First, I tend to be one of these people who don’t give token amounts to charity- I prefer to give larger amounts to a small number of projects that have very high impact (or very high odds of success if they aren’t having an impact yet.) But the money is secondary. The important thing is that there are already a fairly good number of projects in this space, with a fairly small amount of users, developers, testers, and attention to spread between them. And to be blunt, I don’t want someone coming in with more web design and marketing sense than actual hacking chops and using up all the oxygen in the room. I think DiSo did this to some extent, frankly. So yes, giving a little bit of money to someone can be quite counterproductive and unpragmatic- and I wanted to reassure myself that I wouldn’t be contributing to that problem again. Given that it looks like they’re going to be doing this crazy thing ($13K raised of their $10K target) that concern is now irrelevant.

(untitled) by Môsieur J. [version 3.0b], used under CC-BY.

So some thoughts on the rest of the responses, again in hopes that they are supportive and constructive:

We plan to “build less.”

Hooray! Most of these questions don’t have right answers, but this one did. And the followup priorities seem reasonable- those probably are the right minimum bits necessary. That said, where people have already built things, consider building less than less by working with other projects. Status.net comes screamingly to mind for the message passing component, but I’m sure there are others. Don’t just build shared specs- where possible, build shared code.

We see all of this communication happening between two Diaspora servers, rather than strictly between peers.

This seems like the very pragmatic solution to me; all the talk of real peer-to-peer is terrific but that is a very hard slog- both technically (getting it working) and socially (getting users to install it.) With regards to DiSo, the response had one set of great things, and one part that was very ambiguous to me:

It seems to us that all of the previous attempts at solving the problem are trying to create the perfect solution in the first version.

I think this is right, and I’m heartened to hear the talk about building answers that satisfy rather than perfect. These are all signs of excellent taste (not just this sentence, but many of the things both in this specific answer and in the entire blog post.) Ambiguously:

[DiSo] tried to add on to Wordpress, a project which was not designed from the ground up to be a distributed network.

I’d love to hear more elaboration about ‘designed from the ground up to be a distributed network.’ Wordpress has proven to be a very flexible platform for a lot of things, and it both publishes and consumes structured data very well to that distributed network we call the internet (particularly that subset of the distributed network that consists of Atom/RSS publishers and consumers- I subscribe successfully to many friend’s wordpress blogs in something that looks very much to me like a distributed network.) In addition, things have improved since DiSo started, since there is now PuSH, possibly webfinger, etc. So which features are you looking for in a ‘designed from the ground up’ distributed network that wordpress doesn’t have? I’m not saying that wordpress is the solution, but I’m curious to hear more about what it specifically lacks. With regards to Mugshot… I wish the Red Hat folks had posted a good post-mortem on that; to the best of my recollection I never saw one. My own sense is that: (1) it was very difficult for others to set up, so it never got an outside development community, and no one looked to it as a distributed solution to the problem. (2) The community it attracted was heavily tech-y, so the community that built on it looked to outsiders (frankly) like it was a bunch of nerds, which made it hard to expand into a more broad-based audience. (e.g., it was a great source of community for linux distributions, not so much for sports. Identica has the same problem relative to twitter; compare a search for lebron on twitter to a search for lebron on identica some time. Ditto Bieber or Gaga. This is very related to Pick The Right Customers.) Both are problems worth being aware of. Solid answers on specs and services, including a couple projects I hadn’t been aware of- usually a good sign (even if one of them appears to be completely insane :)

We will be constantly sharing our ideas, and 100% of our code at the end of the summer.

I’m still not clear on why no code until the end of the summer. Care to elaborate? I’m not an absolutist on this- mostly for reasons related to bikeshedding and design- but it does seem like an odd default choice.

We think in the future (after the summer), we will work on an easy installation…

Only clearly wrong answer of the whole thing. Easy installation should be baked-in from day one- adding it afterwards is hard. As a bonus, it helps you write automated tests (since automated deployment is easy) and easy installation helps you choose the right customers by helping you attract users who are interesting in talking to other people rather than playing with software.

#What are your three favorite books on software development? three favorite essays? what about on design?

Is this one of the questions where if I don’t say “Kernighan and Ritchie,” “Getting Real”, “Mythical Man-Month,” “Don’t Make Me Think!” or something like that, you will disapprove? :)

Yeah, sort of. But ‘Getting Real’ was the right answer. ;) (I sort of wish I had the time to write a mashup of Getting Real and Producing OSS, maybe with a dash of The Poignant Guide.) I also highly recommend Rework and Designing From Both Sides of the Screen. Blog-wise, you might find this list interesting, though not necessarily pertinent to this discussion. Finally:

We bought him some arepas. They were delicious.

I’m sort of bitter that you live near that particular deliciousness. Also that you called me an old dude. But mostly because I miss those arepas. And the yo-yos. Enjoy one or two for me during your hacking breaks. :)

Questions for the Diaspora

Tue, 27 Apr 2010 00:00:00 GMT

So lots of friends were tweeting this morning about Diaspora, a project to raise funds to get a summer’s worth of hacking done on a distributed, Libre social network. A distributed, Libre social network would be a terrific thing to have; I’d love to support it. And I love the eager energy I’m seeing around Diaspora.

Questioned Proposal, by Eleaf, used under CC-BY

But I’m also keenly aware that distributed social networks are hard, and so I’d only give of my money (or my time) to someone who looks like they have what it takes to take a serious stab at the problem. They’re hard:

as a design question: how do you make a social network whose UI doesn’t suck?
as a technical question: the code involved is complex, particularly if you want to interoperate robustly with other platforms, and doubly so if you want to do that with proprietary platforms.
as a social question: getting users to migrate is not easy.

So here are some questions for Diaspora, or really for anyone working in this space. These are not questions with right answers, necessarily. But anyone serious about solving this problem probably has at least some answers for them, so showing that you’ve given them some thought will go a long way towards convincing people that you’re serious about attacking the problem. If you haven’t given them thought yet, I could think of worse places to start. :)

What do you think are the most important features a social network should have? How would you prioritize them? Do you plan to Build Less or go big? If building less, what is the minimal set of features you can get away with?
DiSo is now two-plus years old. Any ideas why it didn’t get off the ground? Bonus points: same question for Mugshot.
What standards, if any, do you plan to work with/build on? (just to throw out a couple, all of which have strengths and flaws to consider: webfinger, oauth, xauth, the buzz APIs.)
What other services, if any, do you want to interoperate with? why? how will you prioritize?
Any other Libre code bases in the same space you’d like to work with? GNU Social? StatusNet? What ones are you aware of, and why will you/won’t you build on/work with those?
Would a smarter client (like Mozilla Contacts) be useful to you? If so, how?
What is the strategy to get to a critical mass of users (or avoid having to get a critical mass?)
What are your three favorite books on software development? three favorite essays? what about on design?

I don’t mean to ask these questions to piss on anyone’s parade; I deeply want to believe. Heck, what I want to do is fly to New York, sit down in a room, and help you brainstorm and plan. But unfortunately I’m a pragmatist with a day job. I can’t directly help out. So instead I offer these questions. Answer these ((or questions like these- you’ll note I skipped some hard ones like ‘business model?’)) and you’ll begin convincing people that you are also pragmatists: that you’ve thought hard about the questions at hand and you are worth investing in. And I’ll be first in line to do that. (I should note that unlike some I don’t need code; I think code that is created without much thinking is all too common and frequently damaging. But if you don’t have code, I suggest doing planning- and talking about it- before doing a PR week. :)

a quick vent about the structure of online agreements

Tue, 13 Apr 2010 00:00:00 GMT

I completely understand why many startups have terms of service with terrible content- providing terms of service whose content is fair to the user is incredibly risky and/or expensive (though it isn’t unheard of).

But there is just no excuse for terms of service with terrible organization, especially when you’re trying to sell services to real companies who might (gasp) actually have someone read the damn things. Having a well written document doesn’t cost you anything. If it should be two separate documents, make it two separate documents, and not one (which is what set me off on this rant). If it should be five documents… wait, it should never be five documents.

So please, think of the lawyers. Write your terms of service in a comprehensible, sane structure today.

This has been a public service announcement; we now return you to your regularly scheduled kvetching.

over at opensource.com...

Mon, 29 Mar 2010 00:00:00 GMT

I’ve written a brief piece on the open source law community over at opensource.com. May be of interest for those hackers who wonder if they have any lawyer/guardian angels, and if so, do they ever talk to each other?

More Patent 101, and some Patent Licensing 201 (advanced class ;)

Fri, 26 Mar 2010 00:00:00 GMT

More patent lessons- first on submarine patents (basics!) and then on how patent pools are licensed. I don’t really want to continue this series, but the past few days have been a good reminder that there is a lot of misinformation out there around patents.

To start with, OSNews wants to claim that there are no such thing as submarine patents anymore, relying on a very specialized, nuanced definition of submarine patents. Their definition is… well, it is internally consistent, but I’ve never heard the term ‘submarine patents’ used that way before, and if you define it that way you run the risk of thinking that submarine patents are no longer a problem. This is sadly not the case.

Most people define submarine patents not as patents which are unknowable (because of the PTO’s process), but as patents which are unknowable or effectively unknown and therefore can’t be dealt with effectively.

The problem here - with software patents in particular- is that they are so numerous, so broadly worded, and so inconsistently worded, that searching for them is like searching for a submarine in the ocean. It is incredibly difficult, incredibly expensive, and very frequently ineffective to look for the ones that could torpedo your software product. And so most of the industry doesn’t bother- they just cross their fingers and hope. ((One of the many, many ways in which software patents are broooooooken.))

Patent pools like MPEG-LA’s are an attempt to avoid this problem, not by searching the ocean, but by bribing the submarines to surface and getting them to agree not to use their torpedoes. So they do reduce the risk of submarine patents, but they definitely don’t eliminate them- each company will still have to do their own risk analysis when they sign into a patent pool, to make sure they are comfortable with the risk from patents outside the pool.

It is worth noting here that patent rights are like copyrights, and not like trademarks: you can let them sit as long as you want without enforcing them (generally speaking.) This is another part of what makes submarine patents messy- merely using the technology in a very public way (like many companies do with MPEG) does not necessarily guarantee that there are no risks; it only means that if there are risks, they haven’t surfaced yet.

So, bottom line: if the OSNews article made you more comfortable about submarine patents, get nervous again. Using their technical definition, the risks are zero, but using the more common (and more reasonable) definition the risks are usually low but they definitely aren’t zero.

On the other point: Gruber said yesterday that Google, as an MPEG-LA licensee, would be protected if Ogg violates an MPEG-LA patent. This is possibly correct, but highly unlikely. Companies who give their patents to patent pools don’t actually give them up completely- they typically only promise not to use them against very specifically described technologies. If you’re not that specifically described technology, the patent owner is completely within their rights to track you down on their own.

In the case of MPEG-LA, the patent license is almost certainly for implementations of MPEG codecs, not for implementations of any random video codec you want (like ogg.) So Google probably has some other reason they feel safe about ogg- it may be that they’ve done thorough research on the codec, or it may be that they have other cross-licensing agreements outside of MPEG-LA, or they may just be unusually tolerant of risk. Unfortunately, we can’t know, and they’d be crazy to tell us.

Again, like yesterday, I haven’t seen the MPEG-LA licensing terms; it is possible that they do in fact cover implementations of any random codec. But that would be very unusual.

patent 101

Thu, 25 Mar 2010 00:00:00 GMT

[Disclaimer: I’m not saying this on behalf of my employer, I have no exposure to MPEG-LA’s licensing agreements, and I’m not making a broader claim about the h264/ogg debate; I just want to clarify one specific point of law.]

“If some patent troll decides H.264 violates a patent, they must go to court with MPEG LA, not individual licensees.” — John Gruber, Daring Fireball

Let this be a friendly public service announcement: patent law says that anyone who uses a patent, not just the manufacturer or licensor of the patent-infringing good, can potentially be dragged into court on a charge of patent infringement. (This is not the first installment of this reminder.) This misunderstanding of how patent law functions gives people a false sense of security- they think they are safe because they are ‘just’ using, when in fact patent trolls are known to go around to small individual consumers of ‘infringing’ software and extort settlements from them in order to build their war chests for later, larger suits. Or in other, more specific words: there is certainly nothing in patent law that says that an H264 patent troll ‘must’ go after MPEG-LA and can’t go after individual licensees.

Of course, going after users is rare. Furthermore, it is certainly possible that MPEG-LA might (for political reasons) try to enter into a court fight on the side of someone being attacked by an H264-related troll; it is even possible that the licensing agreement requires such entry if the defendant is an MPEG-LA licensee. (If the latter is what Gruber was getting at, that would be interesting to know.) Even entry by MPEG-LA on your sideis not likely to completely protect you; even if they were to promise to cover all costs and settlements, the engineers and businessfolks who made the decision would still likely be hauled into court to testify as to whether the infringement was done on purpose, how it was done, etc. Bottom line: there may be contractual obligations at play here, and if so, I’d love to hear clarification, but as far as statute goes, what Gruber says about who can sue whom is mistaken.

Mailing lists are parties. Or they should be.

Wed, 17 Mar 2010 00:00:00 GMT

I can’t go to bed because Mairin is right on the internet and so I want to (1) say she’s awesome and (2) add two cents on mailing lists and using the power of a web interface to make them better. Bear with me; maybe this is completely off-base (probably I should just stick to law), but it has been bouncing around in my head for years and maybe me writing it down will help the lightbulb go off for someone who can actually implement it :)

Here is the thing: I think mailing lists are almost like parties in a lot of ways, and so we can steal ideas from parties to help write better mailing list software. I know this sounds silly, but bear with me.

First, the similarities. At most parties, like most mailing lists, most people want to have interesting conversations, and they understand the shared social standards and interests of the other people at the party. And at most parties and most mailing lists there are a handful of people are boors who probably don’t want to spoil the party, but who violate those shared norms- some in very mild ways (boring, talking too loud, posting too much), or maybe some less mild (the guy who doesn’t think he’s a racist, but really is.) ((There are only a small number who are actively malign and I’ll ignore them for the purposes of this post- if you have too many of them on a list, you have problems software can’t solve. That said, the analogy may have some use in dealing with trolls too.)) If you’ve got similar mixes of people, why then do parties usually handle boors well, while mailing lists often fail and flame out?

At a party, one thing that helps keep conversations functional is that people who lack social graces or are uninteresting get social cues which encourage behavioral change. Sometimes these cues are very explicit- someone saying out loud ‘you’re not interesting, I’m leaving.’ But those direct cues are a pain to send- they are usually considered ‘rude,’ they require a lot of emotional energy, and they often mean more interaction with the boor- which is the last thing anyone wants. And blatant signals are often counter-productive too, since they make well-intentioned people defensive instead of giving them a face-saving way to learn they have a problem. Since direct signals are a pain, at parties we’ve evolved a range of more subtle cues to use- people cough and shuffle their feet, or quietly move to another part of the room, or say ‘how about the weather?’ And this actually works pretty well- worst case, people walk away from the boor and have good conversations elsewhere; best case the boor gets the message, changes their behavior, and becomes more fun to be around.

Mailing lists have no low-cost equivalents to coughing and walking away. There is only silence, or confrontation. Mairin’s mockup excites me since, if implemented, it could provide those more subtle, less confrontational cues by allowing ‘-1’ digg-style votes on posts. You could imagine making the cues even more subtle and non-confrontational than she suggests, perhaps by sending positive cues to everyone but negative cues anonymously and only directly/privately to the boor.

Another way that parties and mailing lists aren’t enough alike: in a party, if you are part of a boring conversation, you just walk away. Besides giving the social cues already discussed, this also has the awesome effect of allowing you not to hear that conversation anymore. In contrast, a mailing list is like a party where you can’t walk away from a conversation. You hear every single conversation whether you like it or not. Some of the best email software allows killing entire threads, but that doesn’t give the social cue to the boor. They think everyone is paying attention and so they keep talking. And for people with less good email clients (most of us), the options are to just tolerate the boors or leave the list altogether. Imagine if you had to leave every party that had even a single boring conversation. You wouldn’t go to many parties. That is what most mailing lists are like, though.

We can fix that. You can easily imagine mailing list software that allows you to tell the server ‘don’t send me this thread anymore.’ As a side-effect, if enough people ignored a thread, you could tell people posting in the thread that ‘X people have walked away from this conversation- maybe you should take this off-list?’ These would probably both require a fair bit of hacking, but it seems like the upside is a more party-like list.

On the more positive side (Mairin said she liked to focus on the positive!), at a party it is easy to find the good conversations. Just wander around the room at any decent-sized party; you’ll see a tight knot of people and hear they are talking excitedly. Can’t do that with a mailing list; you’ve got to at least start reading every thread. Once you know which threads people like (maybe via a ‘like’ link in the footer?) you can offer a party-like ‘subscribe only to threads that already have a crowd.’ Twitter/identica sort of do this through the idea of retweets/repeats; you don’t have to follow everyone on earth- some people will just pass the cool stuff along- and that seems like it could be pretty useful for mailing lists.

Note that virtually none of these behaviors require browsing the email through a web interface or a specialized mail interface. All of them could be implemented by ‘click here to mod up/click here to mod down’ links in the footer of each email, so people who live in their mail clients could still participate and benefit, which I think is a must.

Bottom line: Software can’t save a mailing list full of people who actively dislike each other. Maybe I’m crazy, though, but it seems like software that helped mailing lists function more like parties could really help mailing lists cope better with anti-social people.

Updating the MPL

Thu, 11 Mar 2010 00:00:00 GMT

Yesterday Mozilla announced that we will be updating the MPL, with the aim of making the license simpler, easier to use, and more robust. Mitchell’s post captures what we want to do in more depth; if you’re interested in the process, you should go read it and our full website at mpl.mozilla.org. I have the privilege of being heavily involved in this project. I use the word ‘privilege’ because, since right around the time I went to law school, my home page has said something to the effect of ‘Luis’s goal is to help innovators do their thing with minimal interference from and maximum assistance from lawyers.’ ‘Helping innovators do their thing’ is exactly what this project is all about, so I’m excited to be part of the process.

Firefox Cupcake, by M i x y, used under CC-BY

We’re looking to involve the Mozilla community, of course, and we’re also looking to involve people who aren’t normally part of the Mozilla community, like licensing lawyers. So the process will involve a lot of very smart, experienced, and often opinionated people, some of whom will have been working with the license for a decade. I will get the luxury of being the project manager/cat-herder: working on this much of the day, encouraging involvement, organizing feedback, sifting it for gems, and collating all of it into the starting points we’ll use for further discussion and improvement. I’m just the organizer, though- Mitchell (as original author and tentative module owner) has the final say on the text, and the voice of the community will be the community themselves- we’re looking for broad involvement from anyone who has something valuable to say about the license or their experiences with it. If you’re interested in helping out in any way, check out our participate page for more information. The day-to-day work that this huge community of volunteers does to produce software actively chosen by 100 million people is much more important than the legalese that binds them. But the legalese does matter- it communicates our values and helps structure how we work with each other. So improving this legalese is important for the community, and a great opportunity for me to help out, and I’m excited to get started on it.

Digging up my old Red Hat/e-voting posts

Tue, 09 Mar 2010 00:00:00 GMT

The DOJ is breaking up ES&S, the country’s largest provider of voting machinery, the OSDV project seems to be gaining some attention, and RHAT stock recently hit a five-year high. This seems like as good a time as any to dig up my ‘Red Hat should be in electronic voting’ post and followup. Take the gamble, Raleigh! Buy the ES&S assets at bargain prices and get into the game.

Wikis and law school

Wed, 24 Feb 2010 00:00:00 GMT

The excellent Eric Goldman had a good post Tuesday about giving students grades for wikipedia content. This reminded me that ages ago I’d written that two of my classes were going to use wikis, but never followed up on it.

picture: UC Berkeley Law School Quote, by ingridtaylar, used under CC-BY

The classes I used wikis for were different than Eric’s- he actually assigned students to create Wikipedia articles, whereas the four classes I ended up taking with wikis all used school-hosted wikis for a wide variety of purposes:

Three designated note-takers taking notes into the wiki, allowing the banning of laptops for other students.
Note-taking rotating among all students, with wiki gnoming being (if I recall correctly) an ill-defined grade component, but no non-note-taking articles assigned.
Creation of articles in a class wiki being the primary grade for the class, and with some interaction with other student’s work expected, but with no significant intent that the articles written would become a permanent resource for the public. Essays were capped at 1,000 words- which drove many students nuts but led to some fine writing.
Creation of articles in a class wiki being the primary grade, with the intent that the class website would build up over the course of repeated class offerings to become an authoritative web asset for the scholarly community working in that area. ((This separate class wiki had a lot of benefits, most notably being that student articles are never targeted for deletion as irrelevant, but obviously the segregation from the main wiki community has drawbacks too. Maybe the equivalent of the class prize for best essay should be that the best article is ‘promoted’ to main wikipedia… ))

(All of these classes except the last were in technology-related courses.) Despite these widely different set of approaches, several pieces of Eric’s commentary rang very true for me. First, basic wiki concepts were tough. Partially, this reflects poor technology- the average wiki is needlessly hard to use. ((I think real-time wiki/wysiwyg tools like Wave and Etherpad will help fix this once they mature.)) Eric saw this in his students (“it took students a substantial amount of time to format their entries into Wikipedia’s format”) and I think it was true in my classmates as well. But it isn’t just about the technology. Eric says “[m]ost students did not intuitively understand how to approach writing an encyclopedic treatment of a topic.” That does not ring perfectly true for me- lots of my classmates read enough of wikipedia that the format was relatively familiar- but it isn’t insane, especially given the very wide variability in the treatment of legal topics in wikipedia. It would almost certainly help to provide a sort of ‘model’ article, much like the model memos used in writing classes. Since most of the cases will be about specific statutes or cases writing two model/template articles should suffice for many classes. Other wiki concepts, like extensive linking, or publishing drafts to the world in wiki-style, were apparently even more strange to most of my classmates. None of the four class wikis were deeply interlinked or cross-referenced, outside of what was necessary to create a table of contents and occasional outlinks to wikipedia. Similarly, few students were willing to post works-in-progress to the wiki and refine them there- most students preferred to work privately and then put a final text into the wiki. I’m not sure that law school is the right place to teach wiki nature, and indeed Prof. Goldman seems nervous about publishing student work while it is still a work-in-progress ((It might make sense to ‘incubate’ student posts in a separate wiki, so that their classmates can see and participate in each other’s work, before publishing it to Wikipedia.)), but still- I was surprised so few of my classmates appeared to be into the wiki way of creating iteratively edited, interlinked content. ((Tangentially, focusing on linking may also provide the solution to Prof. Goldman’s problem that the school requires seminar papers to be 20 pages long- one article is unlikely to be of equivalent length, but an interlinked network of articles on related cases, statutes, and topics could easily grow to that size.)) Collaboration was another angle that was difficult. Prof. Goldman says “I gave students the option of working together on a topic, but none ended up pursuing that.” This is not surprising- law schools are essentially designed to teach anti-collaboration- but it is a shame, since collaboration is a (the?) crucial skill in legal practice. Some mandatory wiki collaboration (every student required to substantively edit and fact-check another student’s work, as well as their own writing?) might be a small step in the right direction- and might also help alleviate Eric’s concern about the amount of time he spent editing and fact-checking. As a bonus, the wiki nature of the project should make it easy to grade this student editing- the edits will all be right there ((One could imagine giving 40% credit for the article and 10% credit for the quantity and quality of edits made to other students articles, if you had an incubator wiki)). All these issues make it hard to write good informative wiki-articles in a class context, but surprisingly, they also made the class-notes-in-wiki strategy fall far short of its potential. I would have thought that the lower barrier to entry (no need for perfection) and the stronger incentive for students to delve into them (so that they’d be prepared for exams) would have encouraged these wikis to become ongoing demonstrations in improvement. But instead people just had other things to do, so they tended to languish, untended, until right before exams. I think some ‘live’ wiki technologies like Wave, Etherpad, etc., will help improve that in the future (by allowing more than one editor while the class is actually happening) but until them I’m afraid wiki class notes might not get very far. In the one class I had that was truly article-oriented, the professor provided a set of suggested questions to research and address. Prof. Goldman seems to regret not doing this from the start, but unfortunately this seems like an inevitable requirement. At the time you want students to start researching and writing they just can’t know the subject area well enough to know what is ‘missing’ from the wiki, so you almost certainly have to provide pointers for all but the most driven students. Note here that this class was in a purely scholarly area (no one was going to treat our work on English property law of the 1300s as legal advice) so we did not have some of the constraints that he felt he had with regards to making sure it was right before it was published. It would be interesting to delve into this question more- given that articles do not identify their authors as lawyers, and given that people come to wikipedia with an expectation that it is imperfect, I wonder if students can be encouraged to publish more work in earlier forms than they might otherwise. Prof. Goldman concludes that “[i]t is unrealistic to expect that most law students can produce useful entries without supervision.” I’m not sure I’d be so harsh; I think most of my classmates were capable of doing this if prodded to, and it seems like most of Eric’s were too (after more supervision than he expected, admittedly.) But if he is right, this is a pretty sad statement to make. We’re a profession which is necessarily grounded in our ability to communicate, and we should be a profession grounded in our ability to communicate clearly and concisely to a legally unsophisticated public- that is to say, to our clients. If our students can’t write a simple encyclopedia entry, we’re in trouble. Despite this pessimism, I think the piece gets the most important part exactly right:

I think a wiki entry might be a useful alternative to the traditional seminar paper. I have never been a huge fan of requiring students to write law review-style seminar paper in a semester-long course. Ultimately I think it’s nearly impossible for a novice to come up with a good topic and write a coherent and well-researched paper in a 4 month semester from a cold start. (I expand on that point a little here). As a result, in practice, many student seminar papers devolve into quasi-encyclopedic treatments of a topic with a paragraph of student commentary tacked onto the end. Instead of going through that charade, the professor could channel the student’s research and writing effort into an expressly encyclopedic treatment. This would reduce the pressure students feel to come up with a novel topic, and it would allow the world at large to benefit from the student’s work rather than the effort going into a desk drawer (or worse, the circular file) at the semester’s end.

In my experience, wiki writing- whether the goal is inclusion in Wikipedia or not- really should be part of the law school curriculum. It is better than traditional papers for teaching basic research and scholarship, and if done well, can also teach collaboration, editing, and other writing skills. There is still a lot to learn about the ‘done well’ part, but I hope Prof. Goldman and others continue to experiment with it. They’re doing the right thing even if their students don’t realize it yet :)

what writing a contract feels like

Tue, 23 Feb 2010 00:00:00 GMT

Alex Macgillivray, late of google and now of twitter, has a good post just now that might help hackers understand what transactional attorneys (aka corporate attorneys, aka ‘the people who write contracts rather than sue over contracts’, aka ‘me right now’) actually do on a day to day basis:

To put it in computer terms, imagine the contract as a computer program. In each the object is to be able to interpret the words and have that interpretation drive a result. Now imagine that there is no compiler for your program and that you can’t run any tests. All debugging must be done only theoretically and in your head. Imagine that you are coding with another person that is likely to be trying to develop a program that does something significantly different from what you want it to do. You and the other programmer may have different time constraints and, even though you are trying to do different things, you have to be on good terms with the other person because she could just as easily decide to stop working on your project. You and the other person take turns editing the code but without a common coding environment or standard tools to figure out whether the other person (or you) goofed it up. Then imagine that the code you are writing has a high probability of only ever being “run” through two different interpreters with significantly conflicting points of view about desirable outcomes and you likely won’t get to see the result of any of these “runs.” … Include a small chance that your code will be “run” by a relatively unbiased interpreter but the outcome of that one interpretation will be at extremely high stakes, often millions of dollars. Finally, know that you will likely get little credit for writing good code but will be crucified if the one time your code is run it doesn’t work flawlessly. Now you are beginning to understand how hard the job of a good transactional attorney is.

But as they say, read the whole thing.

Credit where credit is due (more Google tea leaves to read)

Tue, 12 Jan 2010 00:00:00 GMT

One of the very first things that made me skeptical about Google was their approach to censorship in China, which I thought deeply compromised their supposed ‘don’t be evil’ approach to the world. It struck me that their position- summarized as “the benefits of increased access to information for people in China and a more open Internet outweighed our discomfort in agreeing to censor some results” bespoke a fair amount of arrogance about the value of Google and a discounting of the value of uncensored information. I didn’t mention that issue in my recent post about Google and reading their tea leaves, but it certainly is one of the big tea leaves to be read.

And so they’ve added another layer to the tea leaves with this announcement that Google will be backing out of censorship in China and possibly abandoning China altogether. Go read it.

It is hard to imagine any other American company having the cojones to make a public statement like it, and I have to applaud them for it. Google is different; anyone who tells you otherwise doesn’t understand them very well. The question we must continually ask is ‘how different, and for how long will they remain different?’ Schmidt’s quotes the other day suggest they are becoming more like others, and that is troubling, and worth writing about and reflecting on (not least by people within Google.) But to even post this is a reminder that they are still very different from most of their peer large corporations. I suppose for those of us who continue to read the tea leaves the followthrough after this post will say a lot as well.

job satisfaction

Tue, 05 Jan 2010 00:00:00 GMT

Some of the legal stuff I do at Mozilla ((really, much of the legal work most lawyers do)) is fairly dull, painstaking contract work. What makes it worthwhile (besides the paycheck) is seeing that something good came out of it. So it was nice to see this blog post - I only played a small part in getting the new data center up and running (at most a couple workdays rather than months of my life), but it still gives me a nice warm fuzzy feeling inside to know I helped out.

google is your butler- the tension between utility and privacy

Tue, 15 Dec 2009 00:00:00 GMT

I’ve often defended Google’s thirst to know things about people with a butler analogy. Good software should, like a butler, try hard to understand your preferences and act on them for you without you even realizing they are there. That means learning and remembering things you’ve done in the past, and using that to base recommendations on. When you tell your butler ‘bring me desert, please’, he should remember that you usually like chocolate, and that all this week you’ve been experimenting with different cakes, and therefore bring you another variant on chocolate cake. If he suddenly forgot you liked chocolate and you’ve been having cake all week, you’d be irritated when he asked you those things again, or if he just brought you a canoli out of the blue.

Ideally you want your butler to know at least something about what your friends and co-workers are doing too- if I say ‘bring me a shirt’, and the butler knows I’m going out with the cool kids tonight, then I want my trendiest shirt based on what my friends think is trendy. But if I am going to the office and say ‘bring me a shirt’, I want the butler to know that my workplace is casual, but not too casual, and so on. I could of course tell him all these things every time he brought me a shirt, but it is easier for everyone if he just remembers, and perhaps does some outside research on his own.

Like a butler, you want your tools to work intelligently based on context and history, and Google is without doubt one of those tools- for many of us, the most important single tool in our computing lives. The problem, of course, is that your butler has a lot of incentives to keep your private information private. Surely the butler can be bribed, but therefore you pay him well and treat him like a human being, and you try to avoid these sorts of problems. Google’s incentives run at least partially the other way- they have strong incentives to mine that data extensively, to share it with others, and to collect well more than most people might think is useful, in the name of being the ultimate butler. And these incentives lead to risks- incentives to share with third parties that you might not trust; risks that things might be subpoenaed; risks that they might leak to Google employees or even outside Google; risks that effective advertising might use such information to manipulate your political views. On balance, most of us are going to look at these issues and decide that we’re OK with Google knowing these things, because the risks are remote and the benefits tangible. So we acknowledge there is a tension between privacy and functionality, and move on.

I wish that at this point I could announce some deep new insight about the balance between these two competing forces. I can’t; most of what there is to be said has been said already. The thing that makes me write about it right now is, of course, Eric Schmidt’s recent comment. The thing that bugs me about it is that he doesn’t seem to realize there is a tension. These words don’t speak of ‘we’re wrestling hard with this question every day’ (a reasonable compromise position) or ‘we’re doing everything we can to collect as little data as possible’ (the pragmatic civil libertarian perspective). They speak of a company (or at least a CEO) which doesn’t realize or doesn’t care that there are balances and compromises to be struck and continuously re-considered. And that, to me, is very, very troubling; more troubling than any particular policy position could be.

So I’m experimenting this week with other search engines, and once I finish moving I’ll be looking again at other mail and rss readers. I really don’t ask much of Google in return for trusting them; I’m not an absolutist, I just need to know that they are continuing to treat privacy as a difficult, multi-faceted issue that constantly has to be evaluated and considered. And if Schmidt is any indication, that isn’t what Google is doing right now.

starting fresh with mozilla

Thu, 10 Dec 2009 00:00:00 GMT

After some bumps in the road which delayed my start by a week, I started today in the legal department at Mozilla. Last night I lost a little sleep worrying if this was the right thing for me, but after a day around the office (during an all-hands meeting, no less) I’m pretty much glowing. The projects I’ve already been charged with are interesting and important (more on those very soon, I expect); the other things going on are relevant (as someone said ‘we get to change the world every day, though some days more than others’); and the energy and enthusiasm are infectious. And of course it doesn’t hurt to be able to work with old friends.

Also, there are reports that my boss wrestled an albino alligator after dinner; reports were conflicting over whether he bested the beast with his bare hands or if he merely threatened to subpoena it. So yeah… things are interesting.

Weird moment of the day: get introduced at a meeting. Guy across table: ‘wait, are you the Luis Villa?’ me: ‘probably?’ Meeting then starts immediately. Turns out a sure-fire way to make a meeting seem very long is to leave a statement like that unexplained and hanging over your head the whole meeting… :) Led to a great conversation later, though, as did basically everything else all day.

software freedom rainmaking

Mon, 30 Nov 2009 00:00:00 GMT

A little over a year ago, I formally introduced John Resig of jquery fame to Brad Kuhn of the Software Freedom Conservancy. I was therefore very pleased to see today that jquery has joined the Conservancy.

Rain Making on me and Krissa in Tongariro

Sadly no one gives me a partnership cut of this rainmaking but I will feel very good about it tonight nevertheless.

state of the art for bounties?

Wed, 12 Aug 2009 00:00:00 GMT

Is there a state of the art for free software project bounties? I’m sort of curious, because I’ve become a heavy user of a project which has an overworked maintainer and no particularly vibrant community. I also have no time/ability/desire to dive into that codebase, but I have two features that I’m pretty sure upstream would accept if someone coded them up. So I’m sort of curious about the options for situations like that, but realize I haven’t looked at the problem in ages and don’t know what the state of the art is, or if any one is even experimenting with it anymore. Anyone? Bueller?

thanks, friends

Mon, 10 Aug 2009 00:00:00 GMT

A few days before the bar I got a ‘wish you were here’ postcard from Gran Canaria. I promise I only choked up a little bit. :) It meant a lot to me.

Thanks to everyone who signed it- I miss you guys (and gals) too :)

10th bugiversary

Tue, 23 Jun 2009 00:00:00 GMT

Some part of me will always be a QA guy, so it is nice to note that today is the tenth anniversary of my first formal bug filing (and first formal participation in Mozilla, I believe): mozilla bugzilla bug 8749, nested

tags don’t display properly. Happy bugday to me, happy bugday to me… :)

STLR Vol. X published- as Open Access

Fri, 05 Jun 2009 00:00:00 GMT

Early this week I published Columbia Science and Technology Law Review Volume 10, completing my responsibilities as Editor-in-Chief.

We have some interesting articles that I’m glad to have worked on - particularly, I think, the very interesting (and readable!) article on what is known in contract law as the ‘mailbox rule’- and how it is obsolete in the internet age.

Of perhaps more personal pride to me is the letter from the EIC that I was able to write, explaining that the journal is going Open Access and complying with the Durham Statement on Open Access, recently published by the librarians of several leading law schools. In practical terms, this was not a huge change for us- we already published online and in pdf. However, moving to library servers is important for our permanence, and it is an important symbolic change as well. Frankly, I expect that the economic hit many law schools are taking right now, combined with new accreditation standards that are likely to reduce or eliminate mandatory journal purchases by libraries, is going to push a lot of journals away from expensive paper publication and towards online publication, and my hope is that we’re ahead of the trend here- showing others that you can still do good scholarship this way.

We’ve got a variety of news coverage out of it, most notably from Open Access News and Berkman.

I can’t say I’m completely thrilled with the process; specifically, we decided to go with the more conservative non-commercial no-derivatives Creative Commons license, when I would have preferred a more open share-alike policy. But we’re talking baby steps here, and I think even this restrictive license is good for our authors (open access increases citation counts) and good for law as a whole.

And with that I’m done with STLR, and really with Columbia. Thanks to my entire staff; you were great under all circumstances (pleasant and otherwise) and to Krissa for putting up with me for another year. :)

a good graduation day

Mon, 25 May 2009 00:00:00 GMT

Besides actually graduating, it turns out that the faculty named me, along with Alex Middleton (below, the one without the beard ;) as winners of the Carroll Harper prize for excellence in intellectual property studies. A pleasant way to go out, and nice to have my family there for it.

LWN interview on Stormy and other subjects

Tue, 12 May 2009 00:00:00 GMT

This weekend Linux Weekly News interviewed me on a variety of topics, but primarily on Stormy and GNOME’s finances. It has now been posted. It is behind the LWN paywall for now, but will be available more generally in the future. (I urge everyone to subscribe to LWN; it is an excellent publication.) In the meantime, perhaps the best summary of the important part can be extracted from the comments, lightly edited for coherency (commenter in bold/italic, me in blockquote):

Why don’t you take a look at how KDE e.V. is run? AFAIK, they don’t pay in 6 figures to anyone and still manage to get the job done in terms of sponsorships and are not looking for a bailout.

We’ve been operating in a manner similar to KDE e.V. since our last Executive Director left, so we’re familiar with the part-time administrative assistant model of doing things. Some things work fairly well when you’re organized that way; others do not.

Goes to show the mindset of the upper echelons of the GNOME project.

I agree completely. It shows that our mindset is that we were unwilling to sit still and tread water. Our mindset was that we wanted to move aggressively forward and change how GNOME related to the outside world. I hope I was clear in the interview of all the various ways in which Stormy helps us do that.

Now, you can certainly question and say bad things about the timing and judgment of those steps. We did expect this to be financially challenging, but we misjudged how badly it would challenge us.

But I think if you want to question the mindset either I didn’t explain our proactive mindset very well in the interview (possible) or you have a very limited vision of what something like the Foundation can do for our community. Certainly I’m very proud of standing for that active, aggressive view of what the Foundation can achieve, and I think most GNOME Foundation members agree with that (though I completely understand if they are chagrined at the financial situation.)

The Plan, for now

Sun, 03 May 2009 00:00:00 GMT

Lots and lots of friends gave me good feedback on my ‘free time’ post of a couple months ago, so I thought it would make sense to say something now that I actually have some semblance of a plan :) Specifically, among other options, Orrick oferred me a stipend to work on legal issues at a non-profit from Jan. ‘10 to Jan. ‘11, and then return to Orrick at the end of that period ((assuming Orrick is still functional, economy on rebound by then, etc., etc. I see no reason to believe otherwise, but then again the economy is unusual.)).

I’ve decided to take Orrick up on that offer, and I’m very excited that the non-profit I’m going to work with is Mozilla. I’ll be working with Moz’s general counsel, Harvey Anderson, on a variety of issues; some of them of broad interest (which I’ll discuss more here once appropriate) but some (hopefully) of the nitty-gritty unpleasant type that all lawyers are expected to handle, and which I’d like to get some experience doing. Hopefully it’ll leave me some time on the side to write and publish a bit, and maybe even read some fiction for fun, which I’ve done damnably little of since August 2006.

Since I won’t start until December, there will still be some time to travel and get married in there- plans for that are still up in the air but will probably involve some hiking and camping in Canada pre-wedding and (maybe?) Asia post-wedding.

Thanks again to all of my friends who gave suggestions and advice on what to do next; it was all very appreciated and considered at great length.

thoughtlessness in open source

Thu, 30 Apr 2009 00:00:00 GMT

I think professionalism is usually bullshit, and I like it when people have a thick skin. Making people uncomfortable can even be useful if it helps shock people into looking at problems in a new way. I’ve been fairly consistently against behavior codes in open source projects, and I know I’ve on occasion even been the one making people uncomfortable (though I hope that is rare.) But some lines should absolutely never be crossed, like making 50% of the population uncomfortable about who they are - physical characteristics that they can’t change - rather than what they believe.

STOP sexism by Casey West. License:

If you’re not clear why I’m drawing that line today, go read this post on a recent rails conference. Fun all the way around. Some people don’t get it; I think I’m with this comment on why’s post in addressing that problem:

Unless you’ve walked into a professional meeting and had conversation stop while everyone looked at you like “what you you doing here?” it’s probably hard to imagine the impact.

When an entire community has background assumptions about you based on your physical characteristics, even if they aren’t overtly racist or sexist, bad things can happen. This isn’t particular to code; it happens elsewhere too- anywhere where even very well-intentioned people don’t stop to think about what impact their words and actions are having on other people. Those small, unintentional things can easily add up to an uncomfortable or even hostile environment. Not that the communities I’m involved with tend to have this problem in a particularly bad way, but it does happen, I think this is the right overall response, and I’m on board:

I want the […] open source […] communities [I participate in] to be a dignified, respectful, inclusive, and welcoming place. … We’ve all been witnesses to off-color jokes, misogynistic back channel chatter, questionable imagery and unnecessary, trolling comments. I pledge to do better to stand up and call this behavior out when I see it in conferences, online and other public settings. I don’t expect it to go away but I’m not going to tacitly condone it any longer.

Well said. I will help stop thoughtlessness and make people more conscious of what they’re doing and how it is being perceived by others.

the world needs more lawyers like this

Thu, 09 Apr 2009 00:00:00 GMT

The world needs more lawyers like this:

I often explain to businesses that the main reward for a great, original product is a succesful business based on that product, and that intellectual property notwithstanding, the best way to protect most great ideas is by consistently excellent execution, high quality, responsive customer service, continued innovation and overall staying ahead of the competition by delivering more value.

Fender, according to the record in this opinion, understood this well for decades… Only in the feverish IP-crazy atmosphere of our current century did the company deem it “necessary” to spend a fortune that could have been used on product development, marketing or any darned thing on a quixotic quest for a trademark it never believed in itself. That is more than in impossible dream — it’s a crying shame.

I remember telling a room full of execs in 2002 (in the context of a discussion of Lego’s threatened use of trademark to restrict legOS) that the correct response to criticism of their product of the internet was to build better products. They looked at me like I was a naive child. And I suppose it was in part naive; there are going to be crazy people who criticize no matter what, which I’m not sure I understood at the time. But overall I’m glad to see that others (even lawyers!) still think I’m not completely nuts. (See also Matt Haughey recently on a basically related topic.)

deliberative nirvana and software design myopia, Mar. 2009 edition

Sat, 28 Mar 2009 00:00:00 GMT

Ages ago, I tried to write a senior thesis about the potentials and pitfalls of bringing deliberative democracy to the internet. The thesis failed, badly. There were a lot of reasons for that failure ((Krissa moved to Africa; my advisor was not technically savvy; it was a fallback topic; etc.)) but in the end the biggest reason was that I let the perfect be the enemy of the good. When, at some point during the year, I realized that the internet was (gasp) not going to create a deliberative utopia, I quit altogether- it never once crossed my mind that it might be worthwhile to examine how the internet could fall short of an ideal but still be better than the offline world. In fact, it took until last year- in the midst of the election campaign- for me to have that ‘ah-ha’ moment. And so now in the back of my mind I keep toting up the little examples of ‘so close, so far’ that keep cropping up. There are tons of them, because to their great credit, the Obama campaign and administration seem determined to push the edges of the possible in this area ((see, e.g., http://www.aaronsw.com/weblog/rssstimulus )). But I do wish that more people had an idea of the issues and values involved, and how merely naively asking questions on the internet can greatly diverge from the nominally democratic values people are trying to advance. The example that finally spurred me to blog a bit, and try to get some ideas written down, was a post on the google public policy blog titled ‘Citizen participation that scales: a call to action’. It’s a fine little post, noting that the recent Obama ‘Open For Questions’ was driven by Google’s ‘Moderator’ tool, which (being a Google product) is built to scale virtually infinitely, or at least to happily cope with the 3M+ votes and 100K+ questions. Google pats itself on the back for this:

We think technology can be a force for greater accountability and access between citizens and their elected officials. We’re excited that the White House has chosen to use the power of cloud-based applications like Google Moderator and App Engine to scale the president’s direct dialogue with the American people.

And Google should pat itself on the back for this. This is a big step forward from the insanely skewed filters of the traditional media- it’s impressive to compare the (mostly) substantive nature of the questions being asked by this group with the ‘gotcha’/news cycle driven questions that often make up the average White House press conference. Of course, Google’s focus on ‘scale’ makes it sound like the only problem here is an engineering problem about how many people can use the system before it bogs down:

[T]hanks to the scale that App Engine provides, this application can now support tens of thousands of people at once. This gives everyone the chance to be heard in a way that gives priority to the issues that matter most to the broader group.

Tens of thousands of people can vote, ergo, we get issues that matter most to the broader group! Technology- specifically, server scaling technology- has solved the problem. No thought given to user interfaces; no thought given to what values those interfaces are expressing. Not surprisingly the resulting questions have some issues. Most predictably, almost half of the most popular questions (in techpresident’s accounting) were substantive… about marijuana legalization. Now, don’t get me wrong- marijuana legalization is actually a reasonable question to ask the president. ((Even those who (like me) don’t smoke should be very concerned about the cost of imprisonment, drug violence, and lost potential tax revenues; the president’s dismissive answer reflects poorly on him.)) But does anyone seriously think that the huge number of votes for marijuana-related questions (top three vote-getters in budget, for example) actually represents American public opinion in any reasonable way? In fact, the huge number of marijuana questions actually represents a transparent attempt to game the system. That the system was gamed did not come as a surprise to anyone who has thought about the problems of democracy online. Treating the problem as merely an exercise in scaling up a very simple question tool designed for well-intentioned, very homogenous users - Google engineers - was a recipe for a mess in the much more complicated real world, where anti-gaming and moderation techniques are a must have. ((Though careful they don’t get too complicated, or else they’ll scare off non-technical people and lead to accusations of non-transparency. Yes, I’m talking about you, slashdot.)) Even if, miraculously, no one choose to game the system like NORML and others apparently did, there are all kinds of other potential design issues with software built for democracy-scaled online deliberation. Most notably, unlike the small, homogenous group of Google employees for which this tool was first built, American politically engaged computer users are not at all representative of America as a whole. ((Almost certainly more representative than newspaper editors or TV network owners, but still, not representative.)) For example, we are extremely, extremely unlikely to have had friends killed by the police, so one important perspective in the discussion over criminal justice reform is unlikely to ever get reasonable representation in a forum like Open For Questions, no matter how much scale the backend can provide. Biases of this sort- who has more access to technology? who is more likey to use it? who is more likely to use it effectively? who will game it and how?- are of course impossible to eliminate merely with software design, but the google post (and virtually all other coverage of the Open For Questions experiment) have been shockingly devoid of skepticism of the design of the software. They all seem to blithely assume that you can just throw up a polling tool on the web, and voila, democracy. Again, I don’t mean to be completely negative here- my thesis was torpedoed by that. Like Carolus and the early TV innovators, Google, the Drupal team, and others are doing valuable work, and this technology improves a great deal on letters to the editor and other ancestors which were also badly gameable. We shouldn’t throw this baby out with the bathwater. At the same time, it is very easy ((particularly for engineers, but also for non-engineers who don’t fully grasp the implications and limitations of technology)) to ignore the deeper, less obvious ramifications on democracy of the design of the code that we use- who participates? under what conditions? how does UI design affect those things? We should all be sensitive to these limitations and constantly demand better of the technology that (more and more) is going to significantly control how we relate to our government and to each other.

five months unasked for 'free time'- suggestions?

Tue, 03 Mar 2009 00:00:00 GMT

It looks like the job I thought I was starting in September 2009 is actually not going to start until January 2010, or maybe March.

[Edit later: actually very late March; so basically nine months from end of bar exam to start of job. Additionally, I am definitely not assuming that the job will actually be there in nine months, so more long-term suggestions/offers/etc. are also welcome.]

I’m definitely not whining here, or asking for sympathy. I’m very conscious that I’m waaaay better off than a lot of folks- I sincerely wish good luck in finding what comes next to all those who really get laid off today and tomorrow. The economy really is bad, so I understand why the firm did it, and lots of people have it much worse off than me, so I’m grateful for where I am.

Because of the stipend, Krissa’s job, and because I’ve got some money put away, I’ve got some flexibility, and this might be the last time in a long time I’ve got five or more months that I can use outside the traditional regimen of a job. So I’m looking for advice from friends on what to do. There are some obvious options, but I’d like to make sure we investigate everything we can.

Some current options I have on the table, from most conservative to least:

most conservative: We stay in NYC (though moving to a smaller place), Krissa stays in her job as long as makes sense, I work at some pro bono task- presumably SFLC but other worthy causes are welcome to make themselves known :)
I work a full year at some sort of pro bono firm on a stipend from my firm, if that is an option- not clear yet. ((This is less conservative because of a common presumption that despite making this an option, the firm will look on this as a sign of lack of gumption/interest/etc. Partners who wish to reassure me that this is not the case know where to find me. :) ))
we move someplace cheap where we live on our savings, but isn’t pure vacation because we have some purpose that will be useful later in life- for example Costa Rica (Krissa learns Spanish, I polish mine) or maybe some place where she can learn more about small-scale farming (WWOOF?) or I can learn more about technology use in education or the developing world?
least conservative: we say ‘screw it’, pack our beloved Eagle Creek backpacks, find cheap around the world tickets, and hit the road for five months.

So I’m wondering if my (creative, insane, what have you) friends have any better ideas with what I can do with my time. Got an idea? email me, put it in the comments, whatever.

"grandpa, where were you when Obama was sworn in?"

Thu, 22 Jan 2009 00:00:00 GMT

“Grandpa, where were you when Obama was sworn in?” I was fulfilling my civic duty, listening to a closing summation by a defense attorney. We could hear the screams of joy from the street through the courtroom windows on the 15th floor. If I had to miss the moment, I’m glad this was why; it felt appropriate to be doing service. Still wish I hadn’t had to miss the moment, though.

We had to do the hardest thing a jury can do- vote not guilty on a serious charge, knowing that it was very, very likely that he’d done it, but also knowing that the DAs had failed to prove the charges beyond a reasonable doubt. Was pleased to see in the paper this morning that he’ll likely be sentenced to 20 or more years on the other charges, which we were able to reach a verdict on without any problems.

Now… back to class. Urgh. :/

vicious legal-ese

Fri, 12 Dec 2008 00:00:00 GMT

From the Vermont corporations statute:

(26) “Meeting” means any structured communications conducted by participants in person or through the use of electronic or telecommunications medium permitting simultaneous or sequentially structured communications for the purpose of reaching a collective agreement.

It scares me that not only is this now comprehensible to me, but that I can understand the basic thought process that led to it being written that way. Doesn’t mean I like it, though, except on the odd chance that some day I’ll be able to torture my enemies with it.

what the Berkman Center got right

Wed, 03 Dec 2008 00:00:00 GMT

Of late, I’ve been reading my friend Dave’s regular Berkman Lunch transcripts with a certain wistfulness. Ironically, his last lunch post was about a Columbia law prof. ((According to my email archives, Heller has spoken on campus only once since I’ve been here, and that at a series of faculty lectures with ‘limited seats available for students.’)) I’ve always cited the lunches as the best part of Berkman, but the further I get from it, the more I realize that the lunches were just one exemplary facet of what made Berkman a great place.

First, a note on what Berkman didn’t succeed at. When a well-meaning Columbia prof asked me (early in my second year here) what Berkman did well, my answer focused on the negative- what Berkman didn’t do. In particular, I focused on the difficulty of translating great ideas into practice at Berkman. This is, I imagine, still a difficult problem, and there are a lot of reasons for it. Certainly while I was there I was part of the problem; I didn’t have quite the right skill sets and my short tenure created problems. In addition, the reality is that all faculty are not by nature product oriented people- they tend to think in terms of ‘what theory are we implementing’ rather than ‘what problem are we solving for real users’, which not surprisingly leads to lame products sometimes. ((This experience colors my interpretation of the Obama nominating process; I’m utterly thrilled that he’s generally picking hard-nosed operators who know how to get things done rather than ideologues, even when I agree with the policy positions of the ideologues.))

I think in the past few weeks I’ve finally been able to snap out of a focus on that negative aspect and come to a better understanding of what really makes Berkman so great.

First is critical mass. There isn’t just one faculty member, there are a throng. So they are always talking and throwing out ideas. And as a result of money from the Berkman family, and their physical concentration in one place, they can act on those ideas. And that snowballs. Lunch exemplifies this because the food is free and the conference room large. I doubt speakers are given honoraria, but I guess some are flown in. These things are all obvious, though- smart people + money + a building usually = fun. What else is there? What can you do if you don’t have space?

The second thing is the faculty’s focus on Berkman as an institution. For a variety of idiosyncratic reasons, the Berkman faculty are very committed to Berkman-as-Berkman. For perfectly understandable reasons (mostly tenure), most faculty are committed to their own publications first, the law school second, and then whatever else a distant third. For the current Berkman faculty, these three things tend to be on roughly the same priority level, and are also always intertwined- if you publish, you think about how publication will turn into a Berkman project; if you think about the law school, you think about how to help it by getting students more involved in Berkman; etc. As a result, Berkman always has things going on- projects, events, stimulation of some sort. Outside commitments occasionally block individual events or projects, but those commitments never systematically prevent or reduce involvement in Berkman events. That is invaluable- it is faculty commitment that makes anything on a university campus go, and Berkman has that commitment in spades. (Tie to lunch? Faculty actually show up, pretty much every week.)

The third thing is Berkman’s openness. Contrary to Harvard’s reputation that the only smart people on earth live in 02138, Berkman deeply believes that there are lots of smart people out there that aren’t at Berkman, and the instinctive response is to invite them to swing by. Hence Dave’s lunch summary. There is always someone interesting, on a weekly basis, being invited to join the discussion. (And they are discussions, not lectures, as you can see from the extensive Q&A that accompanies every lunch transcript.) And the discussions are open to everyone- you can literally walk in off the street if you want; lots of the participants are students or fellows (who often aren’t academics, but come from other walks of life.) As a result of this openness Berkman is always getting new ideas, and being challenged to think about the old ones- it isn’t just the handful of ideas of the faculty that are getting recycled.

The last thing is the commitment to real world impact. As already mentioned, this commitment has limits that stem from the structure of the place (Harvard is the ivoriest of ivory towers, after all), but the constant commitment to trying new things- despite the daunting odds of failure- is really admirable. The core theory goes like this- a faculty member writes a paper; then they write a book for the popular press based on the paper; and in tandem with those, they start thinking about projects that will bring the core ideas of book and paper to the world in some tangible sense. H2O was an outgrowth of Zittrain’s ideas about pedagogy, Stopbadware an outgrowth of his ideas about generativity and the ‘net, the music project I worked on an outgrowth of Terry Fisher’s ideas on the future of music licensing, and I presume much of John Palfrey’s work as law school Dean of Libraries will be an outgrowth of his book Born Digital. (Berkman likes to take credit for Creative Commons as one of these ideas->books->real world projects as well, though that is more tenuous ;) Are any of these projects world-shakers yet? Not really, and many won’t be because a law school is a difficult place to make product focused, as I already said. But the attempt is noble.

So all in all… yeah, I’m a little nostalgic. All things considered, I’m pretty happy at Columbia, but Berkman is a unique place that other institutions would do well to consider and emulate.

when news and law collide, puffery edition

Wed, 03 Dec 2008 00:00:00 GMT

Lots of the tech news sites are up in arms this morning about this Wired story, (1)(2), reporting that ‘Apple says you’re a fool to believe our ads’ (to paraphrase the title.) While not strictly incorrect, this post really deserves some context.

First, Apple made this claim in an answer to a complaint. The complaint ((in the American system- your national mileage may vary)) is a very comprehensive, but vague, document saying ‘here are all of my potential arguments in court.’ If the court doesn’t like the plaintiff’s complaint, the court can say ‘go away’; if the court doesn’t like the defendant’s response, he can say ‘lock them up.’ If both sides persuade the court that there are serious, important points where reasonable people can disagree, then you start on the road to a trial, where details are added and arguments fleshed out. So you want to throw the kitchen sink in there if you’ve got it, and this defense is one of those kitchen sinks. It isn’t unreasonable to think that this system is a little weird- Germans, for example, would ask a court to filter this kind of claim more aggressively- but it is the system we’ve got.

Second, and more importantly, this particular kitchen sink claim (‘no one would believe that’) is a very standard defense against claims of advertising fraud, called ‘puffery.’ The idea behind puffery is that some ads are inevitably a little outlandish (‘best X ever’), and that reasonable people should be able to tell the difference between those kinds of claims (the ‘puffery’) and the serious claims that we’re supposed to base our purchasing decisions on. We use juries to figure out what is ‘reasonable’ in this situation- does everyone on the jury think that ‘twice as fast’ was just bluff, or does the jury think that this was a Serious Claim that was intended to deceive? Admittedly it seems a bit stretched to this non-expert to call this particular ad ‘puffery’, but it isn’t insane, particularly at this early phase of litigation, when both parties are prone to outlandish claims to make sure that they get their day in court.

There is one other thing about this article that is worth mentioning, and which particularly irritates me- the reporter clearly only barely read the pleading. Wired quotes a paragraph, but ignores the title of that paragraph- ‘puffing’. If the author knew what puffing was, they wouldn’t have written this piece, or at least not in this way. If they didn’t know what puffing was, a simple google search would have lead (first link!) to a definition explaining the basics, and it isn’t far from there to understanding it. So file this under ‘sloppy, lazy ‘journalism.”

dinosaurs+mice, HPUX+Linux, OOo+google office, aka the Innovator's Dilemma

Tue, 18 Nov 2008 00:00:00 GMT

Almost every time I see authors of traditional desktop office suites talking about web-based office suites, it is patently obvious that they haven’t read The Innovator’s Dilemma. (It isn’t just Michael; he just happens to be the latest example.) If you’re interested in innovation at all, do yourself a favor and read the book. No matter what you do in ‘innovation’ (create, manage, market, whatever) you’ll never look at your product or your competitors the same way again.

If you’re a Linux developer, the nutshell version of Innovator’s Dilemma should be familiar- the incumbent saying ‘this upstart is too immature/is too niche/doesn’t have enough features/isn’t ‘enterprisey’ enough so they’ll never take over our market’. And then the incumbent wakes up one morning with all the very immature mice feasting on its dinosaur carcass, as those mice have evolved much more quickly and gained a nimbleness and power the dinosaur could not possibly have imagined. It isn’t just coincidence; there are good structural reasons why this happens repeatedly, and the book explains them well. (Wikipedia has a good list of mice and dinosaurs, many of which are discussed in more detail in the book.)

This isn’t to say there are any guarantees about web-based suites taking over the market; web-based office suites have merely most (not all) of the the signs of disruptive innovation. But the core signs are there. So if you’re in the space, and you haven’t read the book, go do it before you write anything else on the subject. Not only will you be more competent next time you write publicly about it, you might just get some ideas that will help stop the mice who are merrily nipping at your dinosaur feet.

[Hint: it isn’t just for office suites… if you’re writing a desktop app or desktop development platform of any sort, you should be reading Innovator’s Dilemma and figuring out exactly what you’re bringing to the table against web apps and the web app platform- how are you going to stop yourself from being disrupted by them? If you can’t answer that question, you might want to think twice before writing more desktop apps or another desktop platform; if you can answer that question and can act on the answer, then you’re better positioned than most of your competitors- congrats.]

I may have to become a deletionist, and other 'me' news

Fri, 31 Oct 2008 00:00:00 GMT

This is a little ridiculous. Flattering, but ridiculous. :) (Seriously, a good example of the rationale behind the deletionist position- some articles just don’t get enough ‘eyes’ to fix their errors. I think I’m still an inclusionist, on balance, but I can see the rationale.)

In other ‘me’ news, the guys at Deep Fried Bytes have posted a podcast I did with them a few weeks ago. We rambled all over the place, and had a fun enough time doing it that it ended up being two podcast episodes; second part not posted yet. Beware: I say nice things about Office 2007; if that disturbs you, might not want to listen. (I also dump all over OpenOffice, but that is mostly old news.)

I’ve also posted a slightly edited version of my slides from my visit to Duke. ODF only until OOo 3.0’s export mechanisms get better, I’m afraid. ((For the record: notes are necessary to comprehend these slides. The PDF export with notes enabled is unreadable (the slides become black text on black background); the SWF export, while cool, contains no notes; and the HTML export is just plain not working as far as I can tell.)) I did promise to answer more questions on the blog, but real life has intervened. I will try to get to it soon, though.

Durham, higher education, and me

Fri, 17 Oct 2008 00:00:00 GMT

I’ll be in Durham this weekend; I’m not sure how much time I have free, but drop me a note if you’d like to grab a meal or beverage of choice.

The formal reason I’ll be in Durham is to give a guest appearance at CompSci 82, Technical and Social Foundations of the Internet. I have been involved in academia previously (TAing a couple times, lecturing at the Sloan School of Business at MIT, and moderating a panel at Harvard Law School) but I’m pretty sure this is the first time anyone has been quizzed on the content of my blog. I am terrified at what this indicates for the future of our civilization. :)

Before anyone asks, I don’t know whether guests are welcome to sit in, and I also don’t actually know the time and location of the class. But if I figure those out, I’ll post here.

(Informally, I have tickets to blue/white and the football game and extensive eating plans. But really, the class appearance was scheduled first.)

freedom to tinker on hacking self-drivingcars

Fri, 17 Oct 2008 00:00:00 GMT

Not quite as Deep and Serious as my other pieces over there, this is a fun one on whether or not you should be able to legally hack the Self Driving Car Of The Future. Turns out it is a slightly more complicated question than it seems on the surface, and one we’ve got very poor tools to deal with.

FTK: clouds, hype, and freedom

Tue, 14 Oct 2008 00:00:00 GMT

I’ve written another post (really micro-essay) at Freedom To Tinker. This one is about ‘the cloud’, partially in response to Richard’s mini-interview, but really mostly in response to my continued frustration at the terribly meaningless phrase ‘the cloud’, and how it tends to confuse and obfuscate discussion of critical issues. Go forth and read!

what I have been up to

Mon, 13 Oct 2008 00:00:00 GMT

Lots of people I saw in Boston were asking ‘what have you been up to’ instead of the usual ‘sounds like things are good from your blog’ :) I guess I’ve been a little quiet here about me, personally. So some updates:

School is generally good; the first two years ended up being very successful (low honors first year; high honors last year.) This year I planned to throttle back to have more time for outside projects, so I am taking fewer credits than ever. Unfortunately, I seem to have chosen those credits poorly so I am doing more work than ever. Hence, not much time for outside projects :/
Will spend the summer studying for the bar; location TBD (since Columbia throws me out of housing a few days after graduation.) Yes, the bar is hard. Not that hard- Columbia alums pass the California bar at a 90+% rate. But obviously no one wants to be in that 6-8% so of course everyone studies like crazy. That will be me.
Have accepted a job at Orrick Herrington Sutcliffe starting early fall ‘09 in their Silicon Valley office. I look forward to it- excellent firm, excellent people, probably will not implode in the next year. :) Current plan is to work about 50-50 on startups and technology licensing, but obviously the economy may dictate a different balance. Silver lining of the economy may be more time for pro bono projects, of which I obviously have a long list I’d like to work on.
Am not getting married at GUADEC. ;) Probably a low-key family-only affair followed by big, fun parties in Miami and Boston (or New York?)
Krissa and I are trying to enjoy NY as much as possible before leaving, which includes lots of live performances (Jazz at Lincoln Center, ‘In The Heights’, Deblois, Nutcracker), lots of eating (Caracas Arepas, dinner at a not-so-expensive place with Steve Martin and a guy who looked a lot like Paul Simon at the next table), and lots of family visits and East Coast travel (I’m in week two of a six week stretch with family or travel every weekend- all four-plus parents, Summit, and a lecture at Duke.)
Krissa is good- loving her job still; enjoying NY; looking forward to going home to California. Currently in Turkey biking with her mom, else she’d have been in Boston and in Durham next weekend.

So yeah, life is good. Crazy, but good. Not sure I’d have it any other way.

Apologies to everyone who I said I’d see this morning at Summit; unfortunately I had to change my train to a pretty early train and overslept, so pretty much ran from hotel to train. Next year…

what these guys need is... a trademark license!

Wed, 17 Sep 2008 00:00:00 GMT

Most screaming case for a community mark license I’ve seen in a while is the utterly cool PARK(ing) Day. Basically, they’ve got a very cool idea (probably patentable, not copyrightable) and have registered a mark (PARK(ing) Day, protected but not under copyright.) And they’ve put the thing (or tried to put it) under a CC-BY-NC-SA license, which is (say it with me, kids) a copyright license. And hence doesn’t accomplish what they want to accomplish, legally-speaking.

This isn’t really their fault; as far as I know no one has creatively addressed their needs ((just as no one has creatively addressed the need of the spec writers)). Still, frustrating to see. If only there were 30 hours in the day…

creative commons picture script request?

Wed, 03 Sep 2008 00:00:00 GMT

I’m doing a lot of slide show work of late, so I was wondering if any of my readers knew of an in-image equivalent of the gfwa script I use on the blog? Basically, I’d love to know of (or have written?) a script that, given an image, a license, attribution strings, etc., would spit out the image plus an unobtrusive overlay containing the proper attribution information, so that I could put the image into the slide and preserve the requisite licensing information.

Something like adding the following in the lower righthand corner of this:

but less ugly (and more license-compliant; any CC-expert readers might want to weigh in in comments on the state of the art for citation in non-web-y formats like pictures/slide-decks.)

To be really kick-ass the script would probably need to take a font color and corner (upper left, upper-right, etc.) but I’ll settle for having that hard-coded for now.

Lessig handles this by including a list of attributions, links, etc., on the final slide, which may be appropriate for particularly image-dense presentations, but I’d like to experiment with this for now- it feels more appropriate anyway, especially if it can be done in a low impact, aesthetically pleasing way.

Thanks…

quick thought on blizzard's thoughts on google chrome

Mon, 01 Sep 2008 00:00:00 GMT

“The fact that Google believes that they can launch a browser based on new technology means that the market is alive.” —Blizzard

monopoly-e-commerce by Daniel Broche. License:

It is a pretty bizarre “market” where the major participants are, in market share order:

a repeatedly convicted monopolist that makes no money off its product in this market
a non-profit that makes no money (directly) off its product in this market, only indirectly off ads ((almost all by way of the new #5))
a company that makes no money off its product in this market
a company that actually makes money ((really!)) off its product in this market
(probably up to 3 or 4 soon) a company that sells a lot of ads, in large part through #2, but which won’t make any money off its product in this market

So, yes, it is a market, given a very, very broad definition of ‘market’. But a very unusual one. This is not necessarily a bad thing- the same standard that makes it difficult to make a differentiated, profitable browser also makes for more innovation at the web app and operating system levels ((chance that Linux or Apple are viable desktop OS platforms right now if the web is not based on open standards is effectively zero)). But as google hinted in their intro comic, getting innovation to happen at the same layer as the standard is hard. (Some related thoughts here.) Will be interesting, as always, to see where this goes from here.

journaling in internet time?

Sat, 14 Jun 2008 00:00:00 GMT

Given that virtually all journal articles are published on SSRN, and read and discussed, before they hit actual journals, could journals seek to substantially shorten the amount of time between submission and publication, so that authors feel that journals are active contributors while the article is ‘hot’, rather than feeling that they are the finishing polishers of an already-cooling project? In particular, is journal work ‘parallelizable’? In other words, if you put four times as many people on it, would it get done four times as fast? Columbia Law Review publishes on the order of 40 pieces a year, and takes around 12 weeks off for summer break. So it averages out to a piece a week, but it is lumped together into eight issues. Could they be publishing one piece a week, and turning pieces around in 1-2 weeks, instead of every 5 weeks or so, turning them around in longer than that? I think that might be a bit ambitious- some parts of the publishing process do not get faster the more people you put on them- but it might not be. I’m curious if any journal is trying this model.

Speed by José Juan Figueroa. License:

I also have some thoughts on journaling at internet attention span (which pre-date, but are similar to, Berkman’s Publius Project) but they aren’t quite ready for prime time yet. (Caveat: they aren’t really my thoughts; something a friend shared with me instead, but I love them.)

interesting research on 'conditional cooperation'

Sat, 10 May 2008 00:00:00 GMT

Interspecies cooperation by Barry Rogge. License:

For those interested in some of my previous writings on intrinsic motivation, this survey paper by Simon Gächter may be of interest. Key sentence:

[W]e find strong evidence that many people’s attitude toward voluntary cooperation is conditional on other people’s cooperation… Moreover, the fact that many people contribute more the more others contribute also speaks against pure altruism explanations, because they predict that people reduce their own contributions when informed that others already contribute to the public good.

Basically, the paper argues (and justifies through a survey of experimental evidence) that a majority of people are ‘conditional cooperators’ who cooperate in community projects (voting, paying taxes, charity work, etc.) if and only if other people cooperate. If they think others are ‘defecting’ (i.e., not cooperating) then they will stop cooperating as well. The paper also has some more detailed observations that come out of the experimental work; among them that voluntary cooperation is fragile; group composition matters (i.e., groups with more conditional cooperators will be healthier); and that ‘belief management’ maters- i.e., if people think that they are in a group with more conditional cooperators, that group will be more robust. None of these will come as a huge surprise to anyone who has been involved with volunteer communities, but still interesting to see it experimentally confirmed. I’ve always suspected that something like this is the case, and that it explains in part why the GPL is so successful, since it uses copyright to force cooperation and penalize defection, and (importantly) makes a clear public statement that that is the case, which serves a signaling function (everyone in the community knows these are the ground rules) and a filtering function (people who aren’t interested in collaborating don’t join as much as they join other groups.) The paper is only 25 pages and fairly readable; if you’re interested in the dynamics of volunteerism I recommend it. Those of you who aren’t into economists and their fancy ‘measurements’ may also want to look at this related early paper, which is somewhat dated (the concept of low and high authoritarians is sort of discredited at this point) but still possibly of interest in explaining some of the psychological mechanisms at work here. (Came to this by way of this paper on tax evasion, which looks to have many other interesting citations that I should investigate once exams are done. Only Telecoms left…)

sometimes a number hits you like a baseball bat to the head

Sun, 27 Apr 2008 00:00:00 GMT

Televisions from days gone by by Neil Anderson. License:

Clay Shirky on how small wikipedia is, relative to the way we’ve spent our culture’s free time for the past fifty years:

So if you take Wikipedia as a kind of unit, all of Wikipedia, the whole project—every page, every edit, every talk page, every line of code, in every language that Wikipedia exists in—that represents something like the cumulation of 100 million hours of human thought. I worked this out with Martin Wattenberg at IBM; it’s a back-of-the-envelope calculation, but it’s the right order of magnitude, about 100 million hours of thought.

And television watching? Two hundred billion hours, in the U.S. alone, every year. Put another way, now that we have a unit, that’s 2,000 Wikipedia projects a year spent watching television. Or put still another way, in the U.S., we spend 100 million hours every weekend, just watching the ads. This is a pretty big surplus. People asking, “Where do they find the time?” when they’re looking at things like Wikipedia don’t understand how tiny that entire project is, as a carve-out of this asset that’s finally being dragged into what Tim calls an architecture of participation.

The whole thing is worth reading, but that particular bit just jumped out at me like a lightning bolt.

On that note, back to my cave to work on passing Corporations and E-Commerce exams.

second worst dialog I saw during a recent Ubuntu upgrade

Fri, 11 Apr 2008 00:00:00 GMT

This dialog gets points for being graphical, and loses many, many, many points for presenting no information that any reasonable user could possibly get any use from unless they already previously understand (1) what FUSE is (2) how to get FUSE plugins (3) who the ‘first user’ is (4) what the ‘fuse group’ is and (5) how to add users to the ‘fuse group.’ And if you know all those things, you didn’t need the dialog, so kudos for being both useless and intimidating.

The worst dialog was actually a terminal wrapped in the upgrader GUI which stalled my entire upgrade in order to ask me what my terminal encoding was, helpfully presenting a list of 28 possible encodings, of which UTF-8 was 27th and the default was some obscure encoding I’d never previously heard of. (The other times the upgrader stalled the upgrade to ask for input it told me I’d modified config files I’d never previously heard of, much less modified, but at least those had basically the same useful-ish debian config file dialog I’ve been used to for ages.)

Linux has come a long way (the upgrader helpfully offered to do a partial upgrade instead of complaining and dying like previous debian/ubuntu upgrades), but still has a long way to go too.

(These weren’t the only problems I saw; Gerv has a good list of some of the other ones, though I didn’t see all of the ones he did.)

brief "CC-licensed specification" rant

Thu, 27 Mar 2008 00:00:00 GMT

The next time I hear “we’ve licensed the specification under Creative Commons so anyone can implement the spec”, I’m going to scream at someone. ((Yes, someone from MS did it today, but I don’t blame them- this is all confusing and they were trying hard to do the right thing.))

To take a list from a Microsoft license I read yesterday, implementing a spec may require (among other things) licensing of “pending utility and design patent claims, copyrights, trade dress and trademark rights.” Putting a specification under a CC license gives you a copyright license to the text of the specification; it does not give license to the necessary trademarks, or to the patents, and depending on the license chosen, may not even give you the right to make a derivative work of the license (aka, the implementation.)

So, creative commons folks: could you please, please scream for me? Or better yet, work with SFLC to create a good license for specifications (since they aren’t happy with the OSP), and then ask people who’ve ‘cc licensed’ specifications to use that instead? KTHXBYE. :)

Clarification later:

I said, poorly: “Putting a specification under a CC license… depending on the license chosen, may not even give you the right to make a derivative work of the license (aka, the implementation.)” This was confusing, because I deliberately cut out (in order to be brief) any discussion of what a derivative of the CC-licensed work would be.

What I should have said was something like: “CC licenses, used this way, definitely give you a right to edit and redistribute and change the text of the specification. However, probably 99 out of 100 lawyers would tell you that a CC license on the spec does not actually say anything at all about whether or not you can implement the specification. The remaining 1 out of 100 lawyers would say that the license gives you permission because the implementation is a derivative of the specification. If that is the case, and the implementation is a derivative, then the CC license gave you the permissions to implement- but they come with the standard CC restrictions as well! So either way the licensor probably doesn’t get what they really wanted.”

self-explanatory

Tue, 26 Feb 2008 00:00:00 GMT

Now I am 30! by Dan Morelle. License:

Trying not to be too reflective today. Ungodly drilling noise in apartment below mine is helping with that. :) Thanks to everyone who made the last 30 years so interesting and fun; hope for more of the same in the next 30.

shaver asks some interesting questions about Microsoft and legal liability

Mon, 25 Feb 2008 00:00:00 GMT

First off, I Am Not A Lawyer And This Is Not Legal Advice. If you go to Microsoft (or to anyone) and say ‘but this law student on a blog told me so’ then you will be laughed out of the room, or sued, or both, and you’ll deserve it. :)

Mike Shaver blogged early this month about Microsoft’s new tactics in the HTML5 discussion- basically, that ‘we can’t do that because our customers will sue us for not being backwards compatible.’

I should start by saying this is not completely implausible. If your sales guys told your customers ‘this will always be compatible until the end of time’, or your sales contract said the same, then yes, you could possibly be sued for violating the terms of the contract under either circumstance. And of course (especially with large customers) contracts may not be the standard ones we’re used to seeing- months or years of salesmanship and legal work can go into such deals, with extensive custom promises and clauses involved. Without knowing exactly what was said, and/or exactly what contracts were signed to, it is impossible to know whether or not Microsoft’s claims have merit- reading their standard EULA terms would be insufficient.

Note that Mike asks specifically about EULAs; I’ve specifically mentioned sales guys as well as EULAs/contract because in some cases/states/jurisdictions/etc., verbal commitments not reflected in the contract can be interpreted as part of the contract. This is generally not the case, and in fact a well-written contract will go to great pains to ensure that this is not the case. But despite such efforts, sometimes those verbal terms can make their way into court- which makes answering a question like this with a simple ‘yes or no’ even more difficult.

Of course, if your sales guys said that, or your lawyers wrote it into the contract, probably someone should be fired for gross incompetence. It certainly shouldn’t be in the standard contract- opening yourself up to liability to millions of people would be insane. It might make it way into a custom contract, but unless your competitors are so dumb as to make the same promise, and hence force you to write a custom clause promising such a thing, then there is no good reason to promise such a thing. This is software, and backwards compatibility breaks, even at Microsoft. Lawyers and/or sales guys who make such promises are creating liability where there shouldn’t be any, and that is a cardinal sin. Microsoft may be many things, but they aren’t incompetent, particularly on the legal side. So- it isn’t impossible they could have created such liability for themselves (particularly in a deal with their biggest customers) but it is unlikely.

Outside of what Microsoft may have done to themselves with their contracts or actions, it is possible a court system could write such a term into a contract. This is basically how minimum warranties of product quality are created by governments- the government says ‘but of course you’re liable for X, regardless of what the contract says’, and then boom- you’re liable. But in the US the trend is to allow contracts to ‘opt out’ of such terms, and even where that is not the case, it seems unlikely (given the presumption that software is not compatible) that a court or a legislature would create such a huge responsibility- no matter how reasonable the idea might be, any court that tried would quickly have the entire software industry weighing in on the other side.

Finally, keep in mind that Microsoft has every incentive to fight this legally. If a customer of theirs goes to court to say ‘we are owed money because this product was not backwards compatible’, Microsoft would fight it utterly and completely tooth and nail- any court which read that term into a Microsoft contract would create huge liability for Microsoft for every succeeding product release they ever did. So the incentives cut strongly in favor of Microsoft fighting this tooth and nail (unless the liability comes from a custom-written contract which is so specific that it wouldn’t extend to other customers.)

Now, Microsoft certainly has a hard-earned reputation for backwards-compat, and they have every reason, from a marketing perspective, to fight to keep that reputation. But to answer your question, Mike, it seems possible but highly, highly unlikely that there is legal liability.

[Ed. later: see also my response to Mike in comments, on the question of whether or not this type of liability is something Mozilla should be worried about.]

considering Lessig

Thu, 21 Feb 2008 00:00:00 GMT

So Lessig isn’t saying no to Congress quite yet. This really should excite me; to call Lessig one of my heroes is not a stretch at all.

Lawrence Lessig 1 by Mario Carvajal. License:

My initial response was, I think, pretty solid: Lessig would make a very good Congressman. He’s proven in his Creative Commons work that he can build coalitions, work multiple sides of an issue, and (perhaps most importantly) build a winning staff. He’d have a better grasp than almost anyone in Congress on the critical issues of technology and the Constitution. And he’s right that imbalanced influence is one of the core problems in American political life, and that this is clearly a change election where issues like this can be discussed in ways they normally can’t. But watching the video, I can’t help but think that this is not yet the right time for Lessig’s version of this message. He spent years refining the framing around free culture and Creative Commons, and it paid off. With his finely tuned message he was able to persuade not just tech geeks in the US but creators, lawyers, and policymakers around the world. In contrast, by the time of these elections, he’ll have spent only about a year working publicly on the ‘corruption’ issue. And this lack of time shows- the message is too unpolished, and the substance isn’t there yet. I badly want his latest video to inspire me- but it doesn’t. First, the message. If you’ve got one key word you’ve chosen to discuss the issue at hand (corruption), it doesn’t bode well when you have to redefine it almost immediately when you use it. To paraphrase, the video says basically ‘well, there is corruption, but I don’t mean corruption like that.’ The maddening ineffectiveness of this tactic will be familar to anyone who has had to explain the difference between free and free over the years. It may be that I’m just too sensitive, but to me this and similar linguistic/framing/messaging problems make the quasi announcement possibly the least persuasive Lessig video I’ve ever watched- there may some day be a polished message there, but it isn’t here yet. I’m not incredibly inspired by the substance either. The solutions (no PAC/lobbyist money, no earmarks, public financing) are good as far as they go, but they are not terribly new, and they are very top down- focusing on what should be prevented rather than what should be enabled. Part of the genius of Creative Commons was the bottom-up approach- using the motivations of large numbers of individals to counter systemic problems. Similarly, Obama refuses PAC/lobbyist money, but his campaign puts even bigger emphasis on bringing nearly a million people into the system. I’d love to see Lessig (and/or ChangeCongress.org) put emphasis on bottom-up factors like transparency, so that people outside of DC can analyze, diagnose, and mobilize to highlight and resolve problems, or perhaps on issues like broadband access, so that a greater number of people can become not just speakers but also publishers. These aren’t necessarily great suggestions, but Lessig’s don’t seem to be either right now- I’d like to see him apply his talent to improving them before he puts them so forcefully to the public. Even the great ones need time to solve difficult problems like this. So what’s the bottom line? I’d support Lessig if he decides to run, and if he’s elected, I’ll be thrilled that he’ll be my representative when I arrive in California in ‘09. ((Ed. later: I though the district covered all of southern San Francisco, but it actually covers only southwest San Francisco, and because of the location of the train station I’ll probably be in southeast San Fran when I move there. So he won’t be my rep. Oh well.)) But I really hope that he reconsiders and instead spends more time refining and strengthening his critically important message. It would be great to see, in two or four years, dozens or hundreds of candidates powerfully wielding the sharpened, focused message I know he can produce, instead of having him rush out alone this year, wielding the more blunt tool he’s created to date.

Sara White Welsh, 1911-2008

Tue, 19 Feb 2008 00:00:00 GMT

We’ll miss you, Aunt Sara. I’d say ‘Rest in Peace’, but I hope you’re dancing or driving fast, not resting…

why the writers demands shares of revenues instead of profits

Sat, 16 Feb 2008 00:00:00 GMT

After I casually mentioned my support of the writer’s strike, a good friend told me that he thought that the strike was bad, in part because the writers should be getting a share of the profits and not of revenue (and since there were no profits in internet video yet, they should be getting nothing in the internet yet, hence, no good reason for the strike.)

The response to that, of course, is that you can’t trust the studios to report their profits at all accurately- even if they were going to be honest with their writers (unlikely), they have plenty of other incentives (including tax rules) that make them distort their profit reports. Revenues are much more easily auditable, so one of the things you get taught even in first year contracts is that rational participants in the process key their payments off revenue instead of profit.

Two reminders of this came across today that I thought might be instructive for people interested in the issue but unfamiliar with how Hollywood functions. In one, the folks who did the Lord of the Rings movies have been failing to pay the royalties owed to the Tolkien family. Oops. Six billion dollars in revenue, and apparently no payment to the writer. (Of course, they didn’t pay Peter Jackson either.) And it happens in lower profile cases too; the LA Times has a good writeup of ‘Hollywood accounting’ today too, completely outside of the high-profile Tolkien/Jackson cases.

Hopefully I’m not the only one who finds this fascinating ;)

Evangelia's thesis available online

Thu, 14 Feb 2008 00:00:00 GMT

I got an email today from Evangelia Berdou, who came to a couple guadecs to meet, greet, and pick GNOME-y brains. Turns out she’s published the fruits of her GNOME research- her PhD thesis. I haven’t had time to read it yet, but I’m sure it is interesting- she had a habit of asking very perceptive questions :) And it won an award for best thesis, so presumably there is something there- at least the academics liked it :)

in market for new feed reader

Sat, 09 Feb 2008 00:00:00 GMT

Mis suscripciones RSS by torchondo. License:

I’ve finally gotten fed up with my feed reader. Most of the time I don’t really care if my feeds are updated in a timely manner, but when I want it timely I want it timely. Like, on election day, I want my politics feeds to update more often (and more predictably) than every 3-6 hours. Really bizarre that Google hasn’t figured that out. (It isn’t like I’m the first person to complain about that.) And of course I’d like to improve my software autonomy, as usual, which I’m not doing right now. Anyway, so- anyone have any recommendations that meet the following criteria? MUST HAVE:

river of news view: nothing but the feeds; no controls, no nothing.
‘starred’ or ‘flagged’: must be able to mark a post for later investigation/publication/etc.
keynav: must be able to do next/prev feed and flag/star for later reading with a single keystroke.
fonts: must be easy to blow up feed text to very large fonts- much larger than other application fonts. Any gnome-based app that relies on the system font setting is out, for example, since I’m not going to switch the system font sizes every time I open the feed reader.
OPML import: if it doesn’t have functional OPML import, I can’t use it.
subscribe from browser: I’m getting too old to subscribe to feeds by editing a config file; I want to be able to click on the RSS link in my browser and have the Right Thing happen.

NICE BUT NOT MANDATORY:

libre: would be nice, but am currently using a gratis-proprietary web service, so another gratis-proprietary app is a wash.
- if proprietary: must have functional OPML export as well as import.
- if libre: must have functional development team/model. I can’t put up a web service that I can’t trust to be secure, and that means active development. (As far as I can tell this rules out the otherwise interesting-looking gregarius- 18 months without release.) And must have low maintenance and fairly easy install**.** Think wordpress as the target here.
web-based: unless it has a great mobile-phone mode, I’d effectively use it only as a desktop app anyway, so web-based is nice but not huge.
remembers read/unread: I think this is optional (that is how I used to use things on planet, for example) but it might be mandatory, given my current reading style. This is definitely a big strike against planetplanet, for example, but if the other problems with planet were fixed (no starring, etc.) I might be able to live with it.

BONUS KILLER FEATURE:

feature I haven’t seen anywhere ((except planet, but last time I checked planet lacked must haves like starred and subscribe from browser; it also doesn’t clean up after itself so I had hundreds of megs of log files sitting around, which sucked.)) : I want to be able to mark a feed as a ‘meme source’, and not read it directly, but have the URLs it links to tracked, and if multiple meme sources start linking to the same URL, I want to see that URL. Sort of like techmeme, but with a personalized source list.

So, lazyweb: does such a thing exist? If it doesn’t, any web developers want to give a shot at building it? :)

"why should a customer care about IP assurance?"

Sun, 03 Feb 2008 00:00:00 GMT

Matt Asay asks “Why should a customer care about IP assurance?” He and Savio Rodrigues both make what appears to be the same error: comparing IP to “environmental rules or workplace safety regulations”. There is a critical difference, of course: if the EPA or comes after Microsoft, and I use Microsoft products, I can’t be sued. If a patent holder comes after Microsoft, and I use Microsoft products, I can be sued, since patent law allows penalties both for manufacture and use of infringing products. (Joe Shaw correctly cites the relevant law here.) That’s fundamentally different from most other forms of law, where customers typically aren’t liable for the sins of the vendor.

Is the risk of getting sued for use very small? Absolutely. Is that risk overblown by hostile organizations who have used it to scare customers away from competitors, or to ‘tax’ those competitors? Yup. (And in a world with a more competent antitrust enforcer, there would be antitrust concerns about this behavior.) But the risk to the customer, however small, is non-zero. So competent lawyers from large organizations must advise their clients that there is a risk, and most organizations are just too risk averse to ignore that. Hence, customers care.

Savio has another way to argue that the risk really is basically zero:

You know, I’d actually love to see Microsoft sue a customer because of IP issues. Exactly how much would they sue for to offset the millions of dollars worth of negative publicity and brand destruction?

I’d love to think that this can be used as a security blanket, but I’m not sure that’s actually the case. The damage could easily be small- just as a vast majority of Americans think ‘well, it’s OK that they tapped his phones without a warrant- he’s a criminal, and I’m not’ or, historically, have thought ‘it is OK that they restricted his first amendment rights, he’s a communist, and I’m not’, I have a nagging feeling that a majority of software buyers would think ‘it is OK that they went after him for patent violations- he’s a patent violator, and I’m not’. Never underestimate the ability of people to rationalize away those sorts of things when they think they don’t apply to them. And besides- what are they going to do if they are angry? Stop buying Exchange? Windows? Office? Seems unlikely. So I don’t think this particular security blanket works- organizations still have to assume that the risk is real, even if it is small and hence perhaps discountable.

[Edit later: Matt has a comment worth reading in response. I think he and I mostly agree on the causes of the problem; I did want to clarify, though, that patent law is substantively different from the other areas of law he and Savio cited, and think that was worth doing.]

i don't even know what this means

Sun, 20 Jan 2008 00:00:00 GMT

Objectivist phenomenology? (Seen on a mail drop box in lower manhattan.)

DiSo.

Thu, 06 Dec 2007 00:00:00 GMT

OpenID blossoming into something really, really interesting. Yummy.

(Just this summer, when I was talking with identity people about identity in open/principled services, the openID <-> social network thing was purely hypothetical. DiSo is only barely past hypothetical, but… still, very interesting.)

Voting With Your Feet and Other Freedoms

Thu, 06 Dec 2007 00:00:00 GMT

This Post In A Nutshell (aka, the Murray Version)

No one should be surprised that social network users can’t ‘vote with their feet,’ because most users give up a portion of their autonomy when they choose to use web services. This post will suggest that protecting autonomy is desirable and should be designed in to software, and outline five qualities that such software would have.

[The rest of the post will not be brief; it is in part a draft of an essay for my class in ‘Law in the Internet Society’.]

Voting With Your Feet and Other Freedoms

From my ‘Law in the Internet Society’ class mailing list, in a discussion of Facebook’s ‘Beacon’:

The ironic thing is that while some genuinely concerned users are trying to oppose facebook’s policies, the best idea they came up with was to create a facebook group.

It does seem a little odd, doesn’t it? We take for granted that a boycott is the most effective way to protest the actions of a commercial entity- so even the most ardent Facebook fans realize that something is not quite right when this sort of thing happens.

So Why Don’t You Leave?

The standard conservative retort to Americans who complain about the US is ‘well why don’t you leave?’ Answering this question proves illuminating when discussing web services. Liberals don’t generally move to Canada (even during the last seven years) because their friends, families, and jobs are in the US. That makes it difficult to “vote with your feet”, but significantly weakens protests. This is not a critique of those who use didn’t move to Canada during the 60s, or those who use Word to criticize Microsoft ((Hi, Berkman!)), or even those who use Facebook to protest Facebook. The ties that bind us can be strong, and it isn’t necessarily a sign of weakness that so few of us are willing to pay the high costs that come with breaking them. But thinking about protest this way highlights an important problem- that the services we choose can drastically reduce our freedom to make choices- our autonomy. ((This essay necessarily simplifies autonomy- for a more nuanced background, see the Stanford Encyclopedia of Philosophy.)) Autonomy is never complete; we have no choice of the place and culture we grew up in, and as social animals our ties to friends and families are somewhat hardwired. But technology can - and should - do better.

Technology and Autonomy Technology is easily fungible, so we can implement and use autonomy-protecting software. This is presumably philosophically desirable, but could also improve markets and lead to better products by increasing user choice. Unfortunately, very few people design technology with autonomy protection in mind, since an autonomous user is a user who can choose to pay someone else. Designing modern, network-centric software this way is also difficult, since users expect frequent updates, reliable communication with large groups, and global accessibility, all of which are easier when designs are centralized. ((See, e.g., this or this.))

Free Software Is a Good Start…

Free Software is a great step towards autonomy-protecting software. By ensuring that users have the rights to modify their own software or pay others to modify it for them, Free Software ensures significant scope for user autonomy. And in practice, users exercise this autonomy all the time, helping to make the Linux market vibrant and competitive. ((It isn’t a terribly profitable market, but that is a feature of highly competitive markets, not a problem.))

… but it isn’t enough any more

The right to modify and run source code is now frequently insufficient to fully protect user autonomy.

Think about what it would take to leave Facebook, for protest or any other reason. If the software was open source, you or your friends could pay someone to modify it (or learn to modify it yourselves) and remove the offending features. You’d end up with OpenFacebook.com. And then…?

You’d still lack the basic information about your social network that enables protesting on Facebook- you’d have to rebuild your addressbook from scratch. You’d have lost the things your friends posted on your wall, as well. And if your friends who were still in facebook wanted to see how you were doing, they’d check your facebook page- which at best would be badly out of date and at worst might not even exist anymore.

Are you actually prevented from leaving under these conditions? No. But your autonomy- in part, the right to vote with your feet - is certainly constrained.

so what is enough?

A Free Software Definition for the next decade should focus on the user’s overall autonomy- their ability not just to use and modify a particular piece of software, but their ability to bring their data and identity with them to new, modified software.

Such a definition would need to contain something like the following minimal principles:

data should be available to the users who created it without legal restrictions or technological difficulty.
any data tied to a particular user should be available to that user without technological difficulty, and available for redistribution under legal terms no more restrictive than the original terms.
source code which can meaningfully manipulate the data provided under 1 and 2 should be freely available.
if the service provider intends to cease providing data in a manner compliant with the first three terms, they should notify the user of this intent and provide a mechanism for users to obtain the data.
a user’s identity should be transparent; that is, where the software exposes a user’s identity to other users, the software should allow forwarding to new or replacement identities hosted by other software.

Traditional free software deliberately follows principle #3, and typically provides the other factors, but only as unintentional side-effects of being locally installed and managed software.

From Free Software to Services with Autonomy

To protect user autonomy while the pendulum swings back between centralized and decentralized services, services will have to be designed nearly from the ground up with these principles in mind. That will require a lot of work- not just technical design, but new licenses, terms of service, evangelism, and perhaps organizational models. Hopefully, though, these principles can serve as guideposts which can focus and guide those who want to give users their autonomy- one facet of which, among others, is the right, to vote with their feet.

the Live Journal sale as something more than corporate transaction

Wed, 05 Dec 2007 00:00:00 GMT

A former co-worker of mine writes about the Live Journal sale; in particular, she has raised concerns in the past about content censorship on LJ and the impact that has on LJ users as citizens. Worth noting (from the comments) that LJ is free software, but that that only partially protects anyone- my friend’s network of friends and content is still tied up in LJ.com.

Heated Debate, by MrIcon, used under the CC BY-SA license (found by a flickr search for “russia you”)

This is just another example of a recurrent theme from our future: what happens when essentially amoral corporations own, and can sell, what amounts to significant part of our identities? Say what you will about Microsoft, but they can’t sell Office to someone and then retroactively turn over all your documents to the new KGB. (Or at least, we don’t think they can ;) In the very long term, the answer may well be transparent protocols and self-hosted services (like we can choose for email already), but in the medium-term, we’re going to have to figure out something which doesn’t require people to host their own services, but still protects their data and their identities.

"technology shouldn't be such a laughing matter"

Sun, 02 Dec 2007 00:00:00 GMT

From the Washington Post:

In fact, technology shouldn’t be such a laughing matter. As a nation, we wouldn’t tolerate such ignorance about any other area of policymaking. Would we be amused if it came out that Joe Biden, as chairman of the Senate Foreign Relations Committee, wasn’t clear about the difference between Shiites and Sunnis or couldn’t find Sudan on a map? How about if Chris Dodd, the chairman of the Senate banking committee, wasn’t entirely sure what the term “subprime mortgage” meant? You can be sure that if Susan Collins, the ranking Republican on the Senate homeland security committee, fumbled over what a “dirty bomb” is, pundits and pols on both sides of the aisle would have her head. So why is it so funny that the octogenarian Stevens, the top Republican senator on the committee that regulates the Web, doesn’t know the difference between the Internet and an e-mail? (Some of this stuff is technical, but really now.)

We may not expect that all of our politicians understand technology, but we should at least expect them to be embarassed by not understanding. (HT: TLF.)

hehehe

Fri, 23 Nov 2007 00:00:00 GMT

Murray:

Luis, you still need to reduce the verbosity that pads your insights. Try to be better than the professional bloggers who name drop you, so you outlive them.

What’s scary is that (I think) law school has helped me get more concise. Still a long way to go, clearly. :)

kindle, take 2

Tue, 20 Nov 2007 00:00:00 GMT

After some discussion with friends, a couple clarifications on Kindle:

I think it will fail, ((for certain versions of fail- someone compared it to a Zune- might sell a few hundred thousand, but won’t change the industry. That sounds about right to me.)) because it is too expensive a device to buy with little to no free content. Many people were happy spending several hundred dollars on mp3 players, because once they bought the device, they could put all the music they already possessed on the device for free. No such luck here- can’t put on your existing books on it, can’t reliably put pdfs on it, etc., which means you have to make a substantial additional investment, above and beyond $400, before it has value.

I would like for it to fail because I’d prefer to see a device succeed that wasn’t tied to a particular book-providing service (yay competition and choice), and that allowed me to use books I’ve paid for like books I own instead of like strictly controlled rentals. Unfortunately, it is exactly these compromises that give Amazon excellent access to the publishing industry and what looks like a very polished, integrated user experience, so I don’t expect these to actually cause failure for a long time, if ever.

kindle

Mon, 19 Nov 2007 00:00:00 GMT

Robert: I think more than the open source crowd will care about openness, at least in the sense of data formats. iPod was successful not because of iTMS, but because it was cheap and easy to rip all your existing music into your new iPod. Once you bought the iPod, the initial load of content (which is what provides the actual value, after all) was ~ free. Here, no such luck- not only would it be difficult and time-consuming to rip your ‘to be read’ shelf, without pdf support, have fun getting it onto the device. That is a critical and huge distinction for virtually all customers, not just openness bigots.

That said, it may well have enough extra value that it will be successful anyway. It will be interesting to see, at any rate- like Robert, I’d really love to have this instead of my typical pile of magazines, books, or textbooks next time I’m in an airport.

[And ditto on the ugly. Does no one at Amazon own an ipod? At least they seem to have an innovative and interesting solution to page flipping. I look forward to Mr. Love’s review of that piece of physical UI.]

[Edit later: The Amazon page for the product does not mention pdf (does mention .doc and graphics formats) but this engadget article does say the magic word- pdf. If it is confirmed to support pdf, I may well have one delivered ASAP.]

[Addenda: Mark Pilgrim points out in comments that there is apparently pdf support, but that the conversion will be poor. He also notes that this is a physical device- with a terms of service. Welcome to the brave new world, where everyone is a contract expert!]

reminder: doing the right thing with CC licensed images in blog posts

Sun, 11 Nov 2007 00:00:00 GMT

I’ve been using a fair number of CC-licensed images in blog posts lately; I’ve had a lot of fun doing it- looking through and finding the pictures is often a blast. I’ve noticed others are doing more of this lately as well.

CC, by Franz Patzig, used under the CC-BY license.

Note that in all of the pictures I use, I include the title, the creator, and the license, plus links for each of those. It is my pleasure to give credit to the generous artists who let me use their work. But let this post serve as a quick reminder: the Creative Commons licenses also require that when using the licensed work, you must also include the URI of the license, the name or pseudonym of the author, and the title and URI of the work. These requirements are fairly loose (they need only be appropriate to the medium) but they are there, and they should be respected. Tangentially: some CC fan should update this flickr greasemonkey script (or a similar one) to include proper licensing information. That would make this whole blogging thing so much easier :)

RH to host in EC2- does it blend?^W^W^Wis it open?

Thu, 08 Nov 2007 00:00:00 GMT

endlich himmelblau by extranoise, used under CC-BY license

So Red Hat is going to sell hosted servers in EC2. (see also) With my recent focus, this prompts an obvious question. Given that EC2 is basically hosted Xen (a defacto open standard), so that you can apparently fairly trivially move a VM from your machine to EC2 to some other Xen-running server, and that you can apparently access (both upload and download) your VMs trivially via a robust API, does that make EC2 an open service? I’m not completely sure what the answer to the question is, but I’ll at least say that this appears to be meaningfully different than most hosted services. I can get my data in and out, use the data on a Free operating system with minimal modification, and I can maintain my identity by easily ‘hiding’ EC2 usage behind my own URLs. That may not be ideal but it goes a long, long way, or so it seems to me. Some other perhaps-relevant details:

obviously, source is not available. Not clear it would be of any use to mere mortals anyway, and we do have the Xen source. Still, not satisfactory to everyone. Obvious question: are Amazon’s services so complex, their hardware so expensive, and their skill so deep, that they could maintain competitive advantage without proprietary source code?
Amazon’s paid services give you 15 days before a changed TOS becomes binding. This is nice, given that the standard is ‘we change it and voila, it is binding.’
they actually promise to maintain your data for certain periods if for some reason the service is suspended or terminated. Again, the standard is ‘we can nuke your data whereever, whenever.’ However, a casual read of the TOS suggests that they reserve the right not to give your data back to you even if they don’t delete it immediately. Odd. (I’d prefer to see a guarantee that data retrieval services will be available as long as they hold the data, even if all other services are suspended/terminated.)
uses language I wish I saw more often: “we will endeavor to do ___ but shall have no liability for the manner in which we may do so or if we fail to do so.” Not that I’m a huge fan of empty promises (which this is) but it is surprising how many TOSs refuse to even go this far.
explicitly notes that the user retains all rights in their own data and software which is uploaded.

so Luis uses gmail. So what?

Tue, 06 Nov 2007 00:00:00 GMT

The lesson of this last post is not about gmail in particular; it is that web-based software, provided as a service, isn’t going away. If anything, it will keep expanding, because the user benefits are of a sort that traditional, user-managed software will have an extremely hard time matching.

It isn’t just that web-delivered software can be very flexible (especially once greasemonkey is involved), or as powerful as all but the most powerful rich client software, or that it can be really convenient to have access to your data at any time and any place, or that it is nice to be social and trivially share things with friends. All those things are very nice, but none of them are particularly exclusive to the software as a service, and traditional software either already does better or can catch up if it wants to. If these were the only questions, I’d put my money on locally managed software.

But these relatively shallow software features aren’t the only issues. The problem here for any provider of locally-managed software, be it the Free Software Foundation or Microsoft, is that software as a service is a different architecture; an architecture which provides features which go outside of pure software. Most importantly, this architecture abstracts away the most hated and unreliable parts of the self-managed software ecosystem- hardware, support, security, and maintenance. Those are someone else’s problems- all you have to do is log in and use the software. In Jesse’s words, ‘I no longer have to worry.’

In the locally-managed software world, those issues can be truly resolved only with redundant hardware in redundant locations, reliable bandwidth, complex mirroring setups, and the application of lots of manpower, both to set things up and to minister to them when they go wrong. You can improve every part of the system, but the need for time, maintenance, and redundancy will never be completely eliminated. Hardware and software will always require maintenance, and time and skill will be needed to resolve the inevitable failures. The million dollar question is whose responsibility these things are. Hosted software promises to make that responsibility go away, so that you can focus on other things and sleep easily at night.

In an age where everyone has gigabytes of data to back up, hundreds of pieces of software to keep up to date, and so on, this ability to sleep easily at night - to not worry - to put the responsibility on someone else’s shoulders - is not to be undervalued. People will make many compromises, in functionality and in other freedoms, in order to reduce that worry and get that security. Of course, the security provided by some (all?) of the hosted service providers is to some extent illusory. Hosted service providers can be subpoenaed, or fail, or decide to hold your data for ransom. But people strongly believe (with some reason) that software and hardware are even more likely to fail, and at high cost given the centrality of our data to our lives. So until that expectation changes (either because service providers get worse, or because self-managed software gets radically better) software as a service will only become more common.

The implications of this for personal freedom will be the subject of an upcoming post; suffice it to say right now that we need to start thinking about principled services now so that we can design and implement them.

why I use gmail (or, the list of daily worries of a self-hoster)

Tue, 06 Nov 2007 00:00:00 GMT

In class Thursday, during a discussion of privacy and security, Prof. Moglen asked me how I do email; I told him gmail. I was going to write a long post explaining why (which will probably form part of an essay in the near future) but Jesse nails a fair number of them in one sentence:

Now, I no longer have to think about keeping spam stuff up to date, no longer have to worry about that next security vuln …, no longer have to worry about having a decent interface for getting mail from mobile devices, etc…

I’d add no longer have to worry about storage space (at least not for future emails); not have to worry about data backup; not have to worry about hardware failure and reliability; not have to worry that I can’t leave (since I mostly ‘hide’ @gmail behind @tieguy.org).

Jesse and I are not alone in this- gmail is the most popular user-agent at gmane.org, and an lkml admin tells me that over half of current lkml subscribers are @gmail.com. (This bleg was unsuccessful in getting Debian data, but I imagine their numbers are similar.)

Prof. Moglen is right to worry about privacy and security, but for the vast, vast majority of us those are very irregular problems. If they have non-trivial impact, that impact is once or twice in a lifetime. The problems I’ve listed here are all daily problems with self-hosted email. (You can take steps to reduce some of the worry, but you still have to use your precious time to recover when things go wrong, and you have to do it on the hardware or network’s schedule, not yours.) Solving daily problems at the expense of once-in-a-lifetime problems is a tradeoff most people will happily make. So gmail and the like are winning, and will win for the foreseeable future, even amongst those like Jesse who are skilled in the fine arts of software maintenance.

This is principled software’s biggest challenge- not how to stay relevant in the face of google’s vast server farms (which are important but not insurmountable for many classes of service), but how to stay relevant in the face of how convenient centrally-hosted web software is for both users and developers.

[It doesn’t hurt that gmail is very nice software. The keyboard nav is very good, search is powerful, conversation view is the first real innovation in email in ages, archiving of IMs as emails is so blindingly obvious that I’m still shocked no other mail/IM pairs that I know of do it, and the intense scriptability (which is now officially supported) means I have more plugins for this than I used to have for evo. None of these were the things that pulled me away from evo, though- it was all about not having to have the responsibility of running my own server.]

EFF user-generated content fair-use test suite

Fri, 02 Nov 2007 00:00:00 GMT

As I mentioned when I wrote about DRM some moons ago, it is pretty much impossible for DRM systems to actually permit fair use. ((Besides what I wrote about in that piece, there is also the problem of “limited times” and of first sale; the first of which DRM systems can’t respect (unless you have a trusted clock) and the second of which no existing system that I’m aware of respects, though it isn’t completely inconceivable.)) The same problem happens to those who would scan the web for copyright violations- is the use of a piece of music an indefensible copyright violation, or is it protected as a fair use? EFF has a test suite for this; their argument is that these things are fair use, and are indistinguishable (by computers) from copied content, making content-scanning robots very problematic.

As a political statement I doubt this can have much impact, but it will be interesting to see where EFF goes with this from here- I have to assume these are already on youtube somewhere, waiting to be scanned, flagged, and C&D’d.

open is over-used, part CXXXIV ("Open Social")

Wed, 31 Oct 2007 00:00:00 GMT

I’m thinking of calling my open services work ‘principled services’ going forward to split some of the difference between open and Free, and remove some of the ambiguity around the often-overloaded terms ‘open and ‘free’. In the meantime, we’re about to get a flood of discussion of open services, courtesy of Open Social, the new Google project.

I’m mocking them, a little bit, but it bears watching. The really interesting question, which I don’t see fully answered yet, is whether or not this is just about widgets/developer platform, or if this is about the broader (and much more important) open social graph. (Unfortunately, the news suggests the former.) Depending on the final form and how much control it gives to Google, it would almost certainly be better from an open/free/principled perspective than Facebook/Myspace. I look forward to seeing if/how mugshot will integrate.

Technorati search of the news; the actual press release ((best press release ever- search for XXXX and Website Partner A)); Techcrunch.

(Tangentially, I’m irritated that orkut doesn’t seem to let me integrate my old orkut account with my google account.)

red hat/novell patent Q&A

Sat, 13 Oct 2007 00:00:00 GMT

Because people asked…

Q: will you be doing a Q&A on the Red Hat and Novell patents suits?

A: Are you crazy? :) I’ve worked for both companies and managed a team that may well have written or implemented the code at issue. I’m not touching that in public with a ten foot pole. :)

Q: but! but!

A: Go read Mark Radcliffe’s summary. Better starting place than I’m going to give you. :)

Q: any notes you might want to add?

A: the complaint clearly involves not one but three patents; make sure you take your news with a grain of salt and remove your tinfoil hats before reading. :)

Q: seriously? that’s it?

A: I’m sure I’ll end up chatting with SFLC about the whole thing and may at some point have some comments for GNOME, or at least the board. Unfortunately, given the circumstances, I wouldn’t look to me for much more than that, at least until SFLC as my lawyers tell me I should ;)

on joe on patents

Wed, 10 Oct 2007 00:00:00 GMT

Some comments on joe’s post on Microsoft’s patents:

they’re unlikely to come after Linux distributors for the well-known “mutually assured destruction” reasons

Which is why they are going after Linux users, most of whom have no patents of their own to retaliate with. Besides the original Fortune article, check out this latest Ballmer quote, where he carefully points out that ‘people that use Red Hat’, rather than Red Hat, owe Microsoft money. (Of course, implicit in that is a threat against all Linux users who haven’t bought immunity from Novell.)

The infighting amongst the community (*cough* with Novell) is counterproductive to the larger goal. We need to advocate for patent system reform…

Well, yes and no; reform is important, but Novell’s alliance with Microsoft actively undermines reform by making the current system seem more reasonable. From now on, on both antitrust and patent fronts, Microsoft gets to point to Novell and say ‘we came to an agreement with Novell, so the system works fine- the problem is that Those Linux People are irrational.’ This is probably the second most damaging part of the Novell-MS alliance (right behind the constant release of free-but-not-really code which MS can later use to threaten users with.)

We need to advocate for patent system reform — like getting involved with the peer review that the USPTO has recently launched …

While I do agree that advocating for patent system reform is a good thing, Peer To Patent (P2P) is a mixed bag for open source. If P2P reaches its goals, Microsoft and other large players (including some of the trolls) will have fewer — but still plenty — of patents to use against consumers. And those patents will be issued faster and be harder to challenge in court. On balance, probably still a good thing for the industry, but far from a solution to open source’s problem.

Until then, sadly, we have to play the game and get as many defensive patents as possible…

Completely correct, except that there is no ‘until then’, unless by reform you mean ‘abolition of software patents’. Otherwise, likely everyone will always have to play the game; ‘reform’ by itself will not be sufficient to protect anyone, since trolls with a dozen strong patents will be just as threatening as trolls with hundreds of patents of unknown quality.

… while rebuffing Microsoft’s scare tactics at the same time.

Completely agreed. Novell’s deal compromises the community’s ability to do that, though.

Tangentially, if you want to see what the most advanced patent trolls are thinking, this paper (co-written by a brilliant stanford IP prof and Nathan Myhrvold of Intellectual Ventures, formerly Microsoft) is a really interesting read. It deserves much broader coverage and interest than it has received.

Also tangentially, this post is reaching its one year anniversary and is still the top Google hit for ‘Ubuntu patent policy.’ Compare top hit for ‘Novell patent policy’ and ‘Red Hat patent policy.’ But hey, they throw good parties. :)

[NP: Radiohead, In Rainbows]

[Picture by Flickr user Ioan Samueli, used under a CC-BY-SA license.]

two addendums to the radiohead post

Tue, 09 Oct 2007 00:00:00 GMT

Two quick notes on the radiohead post:

I forgot to mention that as part of the purchase process (buried in the terms of service, no opt-out possible!) you give Radiohead the right to email you. Being smart, I doubt they’ll abuse it much, but that is a cost to you which you may want to factor in to your purchase price.
NIN has announced they too are going label-free. At this point, a major band going it alone no longer gets to count as surprising or interesting. What is interesting next is how long it will be before we see a band become ‘major’ without ever signing to a label first. (Relatedly, of course, it will be interesting to see what being ‘major’ means in a post-CD age- mega-million dollar tours? mega-million downloads? Something else altogether?)

some free/open services links

Sun, 07 Oct 2007 00:00:00 GMT

I’ve been a little too swamped with school and interviews to do much openservice thinking of late, but it has not been far from my mind. Some links to prove I’m at least reading if not writing:

Matt Asay hits on the crux of the issue- GPL, in a web context, is just like BSD. Some people may think that this is a good thing, but if you’re in the camp that believes that ‘share alike’ is a good thing for users and producers of software, then Matt’s words should bother you. I do think, though, that focusing on the software is not enough- as Mike Linksvayer notes, source code hardly matters at all for a service like Facebook.
Apparently notification-based, pro-user data policies are not completely implausible, even in a seriously corporate context- in particular, Plaxo’s privacy policy requires that Plaxo notify and give the opportunity to remove data on change of ownership or privacy policy. See also.
Chris Messina has some initial thinking about identity and protocol. Traditional open source software gives the user-customer control of their own data, including their identity; to provide the same level of control to users of web services will require really innovative thinking along these lines.
Social network designers are starting to think about these issues; google is rumored to be competing with facebook using openness as the differentiating feature, having hired someone doing interesting thinking on the problem. See also.
See the punditocracy talking about the problem, in bill of rights format. (I suppose this post is a bit of a stone in a glass house on that count, but they’ve got a 1:1 ratio of blog posts to press contacts. Mine is a little bit better than that.) Chris Messina adds some substance; ClaimID is ahead of the curve.
Simon responded to my ‘user-deployers/user-consumers’ post with a very good post on community roles. Important to know what freedoms/rights/features you’re providing/protecting before you go about trying to provide them.
Lots of people have argued that open services do not require open source servers; Matt Asay goes into a related topic here. I currently am leaning towards thinking that there is a place for closed services that implement source-available standards (e.g., Amazon EC2 as basically a very fancy implementation of Xen) but I realize this will be one of the most difficult issues in defining open services.
Jon Udell talks about ‘hosted lifebits.’ Good reminder that in the long-term this is way bigger than facebook and email. Dan Gillmor has some similar comments, in the context of Google’s shutdown of Google Video.
The esteemed Sr. O’Grady writes about open source and the network (related Asay note), noting among many other things that Joyent is an option for those who want open source replacements for the google tools. Perhaps someone could work with Joyent on the TOS for their hosted service to make this a reality. Chandler is already going in that direction- wish I’d had more time to talk to them when they made that post, maybe it isn’t too late :)

two things to know before deciding what to pay for the new Radiohead album

Tue, 02 Oct 2007 00:00:00 GMT

Radiohead is experimenting with allowing you to pay whatever you want for the new Radiohead album, apparently on the theory that you’ll download it anyway, of which they get zero, or buy a CD from a label, of which they get very little.

My friend Iain waiting patiently for a Radiohead concert a long time ago in a place far away. (Image courtesy Nat.) I thought it might be useful to add two facts for those trying to figure out what to pay for this. First, what you’ve actually given to Radiohead (as opposed to the distributors) for past albums. Terry Fisher’s stimulating Promises To Keep has a useful appendix ((Google Books link. If it doesn’t work, search for “promises to keep appendix: where does the money go” in google books.)) discussing what goes where when you buy a CD. Bottom line from Table A.3, p. 262: on average, 12% of the money when you buy a CD goes to the artist; another 4% to the composer. Of course, these numbers are approximate, and averages: some marketing money and other expenses are then taken back from the artists, CDs sold in Canada are even worse (the distributor gets a much larger share), and some megastars get higher numbers in their contracts. But 16% is a good ballpark figure for the percentage of a CD purchase that goes to the composer-musician, which means if you paid $14 for the last few Radiohead albums (($14 is the average price of their last album from the six stores google lists as selling it)) Radiohead actually saw about $2.24 of your $14. Secondly, the actual costs of the album. The majority of costs of traditional CD sales go to various overheads- distribution, marketing, etc. So far, Radiohead has done no marketing for this album, except the website. For the digital product, the distribution costs are very, very low. Assuming they use very high quality mp3 files (call it 1/4 gig), and going from the prices charged by Amazon’s S3 service for bandwidth, Radiohead’s cost for distribution will be a little less than five cents. Combine these two numbers and you get a price floor of about $2.30- if you pay that much for the digital downloads, Radiohead is probably seeing exactly as much money from you for this album as they will have seen from previous albums. Obviously, this is just a ballpark figure, but it is in the right range. Drop below that, and you’ve basically taken advantage of their experiment. I personally have decided to split the difference with Radiohead; of the $11.70 that is no longer going to marketing, distribution, etc., half will stay in my pocket, and the other half will go to the band (on top of the base $2.30). I’m doing this partially because they were probably hosed by the labels in the past, partially because I want to encourage this kind of experimentation in the music industry ((16% going to artists means 84% is going to things other than the art itself, which is insane in an age where the marginal cost of distribution approaches zero, and where word of mouth, sometimes computer assisted, like MySpace, is both free and the dominant form of marketing.)), and partially, frankly, as a bonus for being very good musicians- I like the idea of compensating good artists more than bad artists, instead of having admitted price-fixers set roughly uniform prices across the industry. But yeah, bottom line: if you give Radiohead three bucks, you can probably safely sleep pretty easy at night that you’re not helping them starve. And if you give more, well, you’ve supported some economically innovative artists. Congratulations. (And to Berkman folks still reading this blog: yes, this would be a good time for Terry to put out a press release pushing his own thinking in this area ;)

why I was asking for tux images- engraved laser tux

Sun, 30 Sep 2007 00:00:00 GMT

Much more subdued, subtle, and tasteful (i.e., more in keeping with my current profession) than my previous Pile o’Stickers approach to laptop decoration.

Lasering courtesy Adafruit Industries, who are very cool people- highly recommend them if you’d like to do something fairly interesting and unique with your digital toys.

glowing, gushing followup on my merely positive roomba review

Tue, 25 Sep 2007 00:00:00 GMT

So, I had a positive roomba review a few weeks ago. I humbly submit that that review was wrong. What should have happened was a totally raving, ‘this is the greatest thing since sliced bread’ review.

Here is what I know now that I didn’t know then: the old roomba ate things- shoelaces, power cords, rug fringes, etc. This meant that every time you ran the roomba, you had to make the room safe first. This is no longer the case. The new roomba seems completely unwilling to eat anything. It detects that something is caught and spits it out. I’ve deliberately tried to force it to behave badly, and it refuses. This might not sound like a big deal if you haven’t had a roomba, but it is actually huge. In the past, running the roomba was sort of a big deal- it was easier than vacuuming, to be sure, but it still took several minutes of scanning the apartment for obstacles and potential problems. Now every single time I leave the apartment I can trivially vacuum. I just hit the button and go, with no worries. I’m actually now regretting not getting the more advanced model- in the past, the timer (where you can tell the robot to vacuum on specific days at specific times) seemed silly to me, since you’d still have to remember to clean the floor. Now that you don’t, the timer seems like a great idea- but my model won’t support it. Oops. Overall, not eating things upgrades the new roomba, for me, from ‘pretty nice’ to ‘every apartment should have one.’ Go forth and bring on the robot revolution. [Not my cat or my roomba, but cute anyway. Picture by Eirik Newth under CC-BY 2.0. Thanks, Eirik!]

a couple notes on the new Busybox GPL lawsuit

Thu, 20 Sep 2007 00:00:00 GMT

Just read the complaint in the GPL violation lawsuit filed today on behalf of Busybox. Couple things jumped out at me:

This is exactly what you think it is: a very straightforward “you are distributing binaries without the source, which you are not licensed to do” case. Nothing complicated here; if the license is valid, Busybox wins, if the license is not valid, Busybox does not win. As a result, the complaint is also a very straightforward document- here is what the license says, here are their options, here is what the license says must occur if the distributor of the copyrighted work doesn’t comply.
Traditionally FSF and others who have encountered GPL violation issues have taken the slow and patient approach- working with the various parties over a period of time to come to an amicable conclusion. In contrast, this lawsuit is not only very public, but happened incredibly quickly- the complaint says that the Defendants were first notified that they were in violation on August 28th- not even a month ago. It looks like the defendants have not responded at all, which if I had to guess would be the reason the lawsuit was filed. Still, sort of surprising (given how these things have gone in the past) that it has happened so quickly- I would be interested to see if SFLC or Busybox comments on why it worked out this way.
You can see a hint of how SFLC will pursue this in the very first paragraph of the ‘Factual Background’- besides the obvious legal arguments about the validity of the license, the paragraph notes that “BusyBox is … used in countless products sold by more than 100 manufacturers all over the world, including IBM, Nokia, Hewlett-Packard, and Siemens.” If this actually goes to trial, it is almost certain that those in the courtroom will hear it noted repeatedly that many Fortune 500 companies use Busybox under the terms of the GPL, and profit from it. A decision in favor of the GPL will be portrayed as being a decision in favor of commerce and industry, not just a decision in favor of an abstract license. Is this supposed to matter? No. Does it? Often, yes, it does- judges and juries are only human.

one last post about the Busybox/GPL case

Thu, 20 Sep 2007 00:00:00 GMT

Mark Radcliffe, of DLA Piper (I interview there on Monday, by coincidence) has a ‘view from a real lawyer’ on the case.

Mark seems to suggest that the answer to my question of ‘why now’ may be that this is a reaction to the Jacobsen case. While a number of open source lawyers believed that Jacobsen was poorly decided, there seemed to be nearly universal consensus that the facts (and the license) were not ideal, and that instead of appealing, a different case should be found in which to raise the issue. SFLC may well have decided that this is that different case- better facts, better license, and with a party actually interested in the litigation. But we’ll see, of course…

three more things worth noting about the GPL case

Thu, 20 Sep 2007 00:00:00 GMT

Following up on the last post after some quick discussions with friends:

At this point, this is still merely a complaint- nothing has gone to trial, nor will it for some time. In fact, most cases which reach this stage still never go to trial- they settle before getting that far. Still, this case is notable because it is the first case in the US which has gotten even to this fairly preliminary stage.
the complaint asks not just for injunction (which has always been the presumed remedy for GPL infringement) but for financial damages. It will be fascinating to see what theory SFLC uses to calculate the damages- perhaps expert testimony on what the code would have been worth had it been licensed under a traditional licensing scheme?
the case is about GPL v2, not GPL v3. The legal theories behind both licenses are substantially the same, so a judicial ruling in this case would be significant for v3- just not decisive.

my blog: the Q&A for law firms and other interested parties

Wed, 12 Sep 2007 00:00:00 GMT

the executive summary:

Nutshell: if you’re a law firm considering hiring me, and you stumble across this blog, please don’t get nervous. Instead, talk to me, and/or read the rest of this post. I’m eager to explain why I blog, and why I think it may make me a better lawyer and a good addition to your firm.

[Image by Hugh Macleod of Gaping Void fame; used with permission under the Creative Commons BY-NC-ND 1.0 license. For more on why Hugh licenses his images this way, see here.]

the full story:

Why are you writing this post now, about this topic?

Yesterday I finally got the interview question I’d been dreading/looking forward to: “So, you have a blog…” The interview was a little rushed, so we didn’t get to discuss it much, but they seemed to think it was interesting and a potential positive.

Not all firms who find this blog are going to be so forward-thinking, of course, and some will be legitimately nervous about finding that a candidate is so far outside the expected norm. I thought I’d write this Q&A to demystify the blog and explain why it shouldn’t worry (and might even excite) them.

What is a Q&A, anyway?

A Q&A is a blog post format I borrowed from my friend Steven O’Grady, an analyst at Redmonk. Basically, it is exactly what it says it is on the label- a question and answer format. I’ve found that it can be a useful way of clearly communicating information when you anticipate a lot of questions about a specific issue- which is exactly the situation here.

So why do you blog?

There are a lot of reasons, some of which are more important than others on any given day. Among them:

I want to follow the advice that I gave the Wall Street Journal: the best way to control your online identity is to create positive information about yourself. (It works- not only is this blog the top search result for my full name, it was for a long time the first search result for “luis”.)
When I started blogging, it was an important part of my job description; it helped me communicate with partners and with the volunteers who I used to coordinate. This is no longer true, of course, but once you’re in the habit it is hard to break.
I have lots of friends scattered all over the world who read blogs, and so my blog is an easy way to keep them up to date on my life. (And even my mom reads it now. Dad is still resisting.)
I like writing in an informal but coherent manner, and getting a chance to clarify and discipline my thoughts by writing about them. I didn’t get much chance to do that in my prior life as a programmer and manager, and I certainly don’t get much of a chance to do that in law school, so this is an outlet.
Frankly, because occasionally other people post things like this. It never hurts to have your ego boosted from time to time, and blogging gives other people the opportunity to do that ;)

What do you blog about?

A mix of things- some technology, some law, some in the overlap of law and technology, and quite a bit of personal information- anecdotes about concerts I’ve been to, that sort of thing.

Who reads it?

My logs suggest that about fifteen to twenty thousand people read the average post on my blog. While I can’t know for certain who they all are, and the numbers are imperfect, most of them are probably technologists and engineers of various stripes who are familiar with my work in a previous life, and who remain interested in my experience as a technologist moving into a new field, as well as my occasional digressions back into technology. Most of these probably don’t read the blog directly, but rather through various news sites (called ‘planets’) which I’m syndicated onto.

A smaller number are classmates and other law students (some posts are syndicated into facebook), and at least a handful are practicing lawyers who specialize in technology issues. (At least one GC of a very large technology company has emailed me thanking me for my posts on the new General Public License and letting me know that he’d circulated them to his executive team.)

How do you find the time?

Once you’re in the habit, you can make time. It doesn’t always happen, of course- I’m sure an analysis of my posts over the past year would show that they dropped to nearly nothing during exams. But even then I can sneak in the occasional mental health post, and you’d be surprised how much you can write between 2 and 3am (most of this post, for example.)

Do you think you’ll find the time to continue once you enter the legal industry?

Now that is a very good question. I’m really not sure. I’d like to, because I’d like to think that some of my readers will be starting their own companies in the future and hence they’ll be future potential clients, and (obviously) because I enjoy doing it.

But I’m also a realist- the first few years at a firm, even more so than law school, have a reputation for stripping away your spare time. As one interviewer told me the other day, ‘when I get home, the only technology I want to use is my remote control.’ So… ‘maybe.’

It may also continue as a very different beast than it is now- probably more constrained in the topics covered (because of confidentiality and conflicts) and perhaps more constrained in the volume I can write.

Are you crazy? Lawyers don’t blog!

I don’t think I’m too crazy- lots of tech lawyers are blogging these days, so it isn’t completely unusual like it might have been even a few years ago. Certainly some of the lawyers whose careers I’d most like to emulate (like Mark Radcliffe of DLA Piper and Mike Dillon of Sun Microsystems) are now starting to do it, albeit in low volume. Of course they have the advantage of being very established and very senior, which I obviously don’t, but I’m working on that :)

Aren’t you scared that you’ll say something that will offend someone, and it will cost you a job or otherwise jeopardize your well-being?

Frankly? Yes, a little bit. As a result, I know I’ve self-censored some posts since I started school, and there are other posts which I did not self-censor, but that I constantly worry I should have. On the whole, though, I think the benefits outweigh the risks- I’m not exactly a radical in most senses of the word, so the risks aren’t too high, and I hope that most firms will look at my resume and realize that I’m a professional, and know how to constrain and modify my behavior when necessary. If the firm is so risk averse that it still troubles them, well, then, we should talk.

On the whole, are you glad you blog?

Absolutely. It isn’t a magical cure-all, and it might not be something I always have the option of doing, but I enjoy it right now, and I hope it is something that I’ll be able to continue to use to enrich my private and professional life for a long time.

[I’m going to leave this pegged to the top of my blog until interview/offer season is over; apologies to anyone who reads the blog the normal way for having to skip over it to get to my regular posts.]

I, for one, welcome our new roomba overlords

Sat, 08 Sep 2007 00:00:00 GMT

(Another product review offered as part of my ongoing quest to make friend’s lives better.)

Our old roomba has been dying since this spring- battery life was flaky (both because it was getting old and because there were some bad internal connections) and when it did charge it behaved really strangely (stopped and started, backed up when it didn’t need to, etc.) Fixing would have required at least a new battery and probably more work on the sensors and such, so it probably would have cost over $100 to get in working shape again.

So when the new roomba came out, it seemed like a no brainer to go ahead and get a new one. It arrived yesterday, and so far I am mostly very pleased. We didn’t get the very top of the line model- couldn’t quite justify that money for those features- but still, a nice improvement.

The biggest improvement is the noise- I used to not like to run the roomba while I was in the room, because it was too loud. I’m typing this with the new roomba running around the same room I’m in, with no substantial irritation. I know it is there- it isn’t that quiet- but I have no desire to run away to another room. It now slows down before it runs into most things, which is nice- should improve the long-term robustness of the thing. Supposedly it also is smarter about eating cords; I’m not sure I believe that, and frankly, I’m nervous to try (since I think an encounter with a cord is part of what led to the death of the old machine.) But I’m glad it at least thinks that it is the case. At least one (though not all) of the axles which used to be impossible to clean of Krissa’s hair has been re-engineered to make it less likely to collect hair, which is a nice touch- cleaning it will be more pleasant than it was.

All told- I continue to recommend roombas to anyone who doesn’t like vacuuming. It isn’t a perfect replacement for a really thorough vacuuming job, but a 90% roomba-ing multiple times a week almost certainly trumps a 100% traditional vacuum that happens monthly, and the new roomba makes it even more likely that you will use it regularly.

Law Study Systems

Sat, 08 Sep 2007 00:00:00 GMT

[cross-posted from First Movers]

I suppose it was almost inevitable- you can study for LSATs and bar exams online, and you can invest piles of money into various law school study aids, so it was only a matter of time before someone created an online study system for the typical 1L legal curriculum.

And here it is, or at least, the first one that I’ve heard of. The company calls itself Law Study Systems, and right now appears to have coverage of Contracts, Torts, and Criminal Law- not much, but a good start for lots of 1Ls.

I’ve only skimmed the materials, since they don’t cover classes I’m currently taking, but the material appears to be fairly solid and comprehensive. It isn’t the kind of thing that you’d want to learn Contracts from (that is after all what class is for), but it is probably pretty nice for a pre-exam refresher at the end of the semester, or perhaps as an intro to use over the summer before classes start (as I know some classmates did.) And it has fairly broad coverage- 22 ‘tutorials’ on remedies in contracts alone.

Of course, it has the same problems as most review materials- for example, while it has great coverage of remedies, my contracts course did relatively little on remedies, so that material probably wouldn’t have helped me very much. Of course, no review materials (unless your professor happens to write review materials as well as teach) will be perfect in this sense, but the difficulty of skimming this material to find what is relevant may be a slight disadvantage during last minute cramming. A search function (currently missing, as far as I can see) might help alleviate that, and make it more useful for targetted last-minute review.

Schools appear to have the option to work with LSS to customize the materials- which is an interesting idea. To the best of my knowledge, no law school is emulating MIT’s Open Courseware and putting their course materials online in an organized fashion, and perhaps this might be the start of that for some schools. (Someone will have to eventually- the publicity of making your materials the standard reference for everyone on the web will be too big a lure to ignore.)

Software-wise, this is not terribly sophisticated yet- for example, the online LSAT prep I did was much more interactive, with music and animations, both of which this lacks. Despite the lack of sophistication, the important parts look like they are here and would get the job done- for example, while it is slide-based, it also quizzes you during the slides, so you have to pay some attention (and recall previous lectures). And it works in Linux, so it is likely to work on the Mac as well- something my LSAT prep could not do, in part because of the audio requirements.

Given how little I’ve used this, and given how much different people’s study needs vary, I can’t say that I can recommend this without reservation- but it certainly merits looking at if you’re a 1L who wants to look at online options for studying for your core classes.

[Disclaimer: LSS contacted me and listed me as a ‘blog they like’, and gave me free access to their premium materials for this review, but otherwise I’ve received no compensation nor do I have any relationship with them. I reviewed them instead of ignoring them, like I do most linking/review requests, because of my long-standing interest in online education.]

thoughts on a summer at Red Hat

Mon, 03 Sep 2007 00:00:00 GMT

I realized a few nights ago that posting about interviews for my next job, without mentioning this past summer, might have given the wrong impression about Red Hat- that I didn’t enjoy it, so I was interviewing elsewhere, or something along those lines. So here goes a quick clarification. I really, really enjoyed working at Red Hat- I got to work with great people on great projects that were interesting and that took good advantage of my skills and background, and you can’t ask much more than that. And it wasn’t just that it was good for me- after a summer there, I think very highly of the company. It isn’t perfect- no company is- but it genuinely seems to try hard to walk the walk, and I like that. I would recommend it to friends- which is about the highest praise you can give a company. So I made the right call deciding to go to Red Hat, I think it is a good place to work overall, and I’d certainly consider going back at some point. But right now there seems to be a strong consensus among all the lawyers I’ve spoken to (including the ones at Red Hat) that I should go work at a firm, so that I can learn more about what it means to be a lawyer- the skills, the lingo, the shared experience, so on. And I’m pretty intrigued by the greater variety of cases and broader resources that you can draw upon in a big firm- I can definitely see myself enjoying that aspect of firm life. So, while I may well end up in-house at a small tech company again at some point, I do think a traditional firm is the right place for me to be right now and for the foreseeable future. I hope everyone (including my friends at Red Hat) will wish me luck finding the right one. :)

all that normal humans need to know about my law firm interviews

Wed, 22 Aug 2007 00:00:00 GMT

Lots of folks have asked me questions about the on-campus interviews I’m currently doing. There are really only a few things normal human beings need to know about this process:

Older, non-lawyer to me in elevator: ‘What? You’re not wearing black? Didn’t you get the memo?’ Honestly. I’ll never again be able to be wild and crazy by wearing a light grey herringbone suit. I’m treasuring it while it lasts.
~500 Columbia students, averaging 30 interviews each (I did 33), over five days, over 18 stories of one hotel, with shockingly few serious problems. The Columbia organizing staff is amazing (and actually live here for the duration.)
We have breaks (at least five minutes, usually forty minutes to two hours) between the 20 minute interviews; interviewers typically do them back-to-back-to-back all day. Not easy for either the interviewer or the interviewee to be charming and cheerful all through that, but most actually seem to manage- I’ve had a lot of interesting conversations.
After this is callbacks- firms that you’ve sufficiently charmed in these 20 minute sessions call you back, and you go to their offices to spend a half-day talking to folks and often doing lunch. From there they make the decision that marks the start of the rest of your life, and let you know; we have until early December to call them back with our final decision.

I think that’s it… been interesting, that is for sure, and frankly much more fun than I expected- I’ve met some interesting people, and it is almost a shame that I have to pick one and only one.

[I should note that going through this process doesn’t mean I had a bad time at Red Hat- I had a great time there, and I really look forward to working with some of the folks there in the future. But it just isn’t the right place for the next step of my career, so here I am doing lots and lots of interviews. Will write more about the summer soon.]

the madness of the law firm hiring process

Thu, 09 Aug 2007 00:00:00 GMT

The more involved I get with the law firm/law school hiring process, the more boggled I am by the inefficiencies of the process. Some great/horrifying numbers:

of students offered summer jobs by “big” firms (> 250 lawyers):

just 28% accept

40% of whom are gone by their 3rd year, and

62% of whom are gone by their 4th.

From an Adam Smith, Esq. post.

I know I’m spoiled because I tend to think of hiring as something that is done only after building up an extensive, volunteer-based relationship, which is obviously difficult to do in law. Still, the situation described in the Adam Smith post, and in this American Lawyer article, is pretty brutal- lots of time spent for very poor results. (Anyone who is curious about the process I’m personally about to go through starting next week should skim the American Lawyer article- it mentions Columbia’s process a fair bit.)

The article suggests that some firms avoid a more rigorous interview process because they think it would scare off potential hires, but frankly, if I knew a firm had a more rigorous interview process, I’d be much more likely to interview with them. I’ve had lousy co-workers before, and any firm that is working to weed those folks out before they set foot inside would be immensely appealing to me.

freedom 'for users'- which users did you mean, exactly? (or, of users, user-deployers, and user-consumers)

Tue, 07 Aug 2007 00:00:00 GMT

“Free software… refers to four kinds of freedom, for the users of the software…” —Free Software Definition, emphasis mine

“closing the [ASP] loophole would infringe on certain peoples rights and he [Moglen] didn’t see any way to preserve everyone’s rights…” — Eben Moglen, as paraphrased here

[The rest of this post is not based on any conversations with FSF/SFLC folks on this issue, but merely on readings of essays/interviews/etc., and so their position here may represent a bit of a strawman. To the extent that the representation is inaccurate I apologize and will strive to fix it if someone points out the inaccuracies. That said, if it is a strawman, it is a useful strawman which helped me sort out my own thinking on the subject.]

who has the freedoms and the rights?

In one of my GPL posts, I mentioned that I thought that the question of ‘who holds the rights’ is a critical distinction between the ‘free’ and ‘open/pragmatic’ licensing camps. To the free camp, rights are held by users; and to the open/pragmatic camp, rights are held primarily by developers- who then grant most (but not necessarily all) rights to users. I thought I’d dig a bit more into that notion, particularly into the question of what a ‘user’ is in this day and age, because I think it helps explain the current dilemma around free software as deployed over the web.

who ‘users’ used to be

FSF has always insisted that “users” are the locus of all rights. In practice, to FSF, “users” has really meant “the people who install the software”- what I’ll call “user-deployers” or “deployers”, in comparison to “the people who use the software”- what I’ll call “user-consumers” or “consumers.”

In the beginning, this was not problematic- anyone who deployed free software also consumed it, so giving rights to all deployers also gave rights to all consumers.

As free software got more popular, this got a little more complicated- deployers were often systems administrators in an organization (who had full rights to modify the code) and the software was used by consumers in the same organization. These user-consumers were given the binaries but were not given enough permissions to install new versions of the binary, or access to source (though they could presumably obtain them for their personal, non-work PCs if they were skilled enough.) And so there was a gap between the rights of deployers (who could modify) and consumers (who could not)- a small gap, but a gap nonetheless.

In practice, this worked OK. The interests of user-deployers and user-consumers were not perfect aligned, but they were pretty close- deployers mostly wanted consumers to get things done and get out of the way, so they protected consumers to a large extent. In addition, even if they weren’t always exactly aligned, consumers and deployers were clearly both on the same side against the software vendors- both consumers and deployers wanted more freedoms than the vendors would necessarily have chosen to give. Given this combination, for most purposes it is fair to say that in practice user-consumers had the freedoms to use and modify- even if in practice those rights were granted to and proxied through the deployers hired by their organizations.

who ‘users’ are now

That brings us to the present day. With the advent of the LAMP-powered web, user-deployers and user-consumers of free software are often no longer in the same organization- the deployer, who was once the local sysadmin, is now the sysadmin of Google or Yahoo. As a result, the interests of the user-deployer and user-consumer are often poorly aligned or in outright conflict. In addition, the old tension between vendors and user-deployers, which helped protect user-consumers, has to a large extent vanished- since the deployer of the free software (the party that runs the compiled code) is now also the vendor.

In a web world, then, user-deployers have the same rights they’ve always had to use and modify. The FSF apparently believes that should not change. But since the deployers and consumers aren’t part of the same organization anymore, the deployers no longer protect the user-consumers, and so user-consumers end up frequently making use of free software without even the slightest ability to use and modify the software- and often even without the right to use and modify their own data!

This is, I think, part of why Matt Asay wants to call GPL ‘the new BSD’- like the BSD, the GPL lets software vendors (in the BSD case, Apple; in the GPL case, Google) deliver software to consumers without also delivering the freedoms to use, modify, and redistribute. Some freedom is preserved- the freedom of the deployer to use and customize- but this is not, at least in my mind, the kind of freedom I’m aggressively interested in working towards.

so how to restore freedoms to user-consumers?

This problem isn’t easy to resolve systematically- since they are in conflict, any attempt to guarantee rights to user-consumers would seem to require some compromise of the rights of user-deployers. I admit I myself am a bit stymied on the issue, though I have some ideas.

Prof. Moglen and FSF’s position seems to be that the freedoms of user-deployers will trump those of user-consumers until someone comes up with a principled and rights-centric way to draw the line between the two. Unfortunately, Moglen seems skeptical this line can be drawn- and experience shows that he is usually right.

I remain interested in the problem, though, since in the end I’m much more interested in the freedoms of users than the freedoms of sysadmins. I hope that better understanding that there is more than one type of user takes me one step closer to figuring out where the line can and should be drawn.

no physical spam petition

Mon, 06 Aug 2007 00:00:00 GMT

Green Dimes is a service that helps stop spam from arriving in your physical mail box. I recommended it to family when it was $35/year; it is now a one-time $16 payment, so I recommend it even more strongly.

As a bonus, they’ve decided to start lobbying Congress to fix the problem with a Do Not Mail list, similar to the Do Not Call list. You can obviously help yourself out by subscribing to the service, but if not, go ahead and sign their petition for the Do Not Mail list. No one should have the right to waste our time by spamming us with catalogs any more than they should have the right to spam us with viagra ads.

one solution to the data permanence problem

Sun, 05 Aug 2007 00:00:00 GMT

Part of the open services discussion at barcamp yesterday was about permanence: how do you guarantee that your data is always available so that you can take it and go elsewhere with it? Doc Searls has one solution to the problem:

Since I’m a Berkman fellow at Harvard, and the blogs here are well-supported, and they’ll continue to be supported after my fellowship is over — and since Harvard has been around since 1636 — [Harvard’s blogging server] seemed like a good choice.

(emphasis mine.)

Mark Webbink retiring

Wed, 25 Jul 2007 00:00:00 GMT

Doh. Mark was a huge part of why I came to Red Hat for the summer, and he hasn’t disappointed- it has been a pleasure to work with him. Shame he won’t be sticking around Red Hat, but I feel certain he’ll find other ways to contribute to free software in the future, while perhaps spending a little less time commuting to Raleigh :)

evaluating a Free/Open Service Definition (rough draft)

Sun, 22 Jul 2007 00:00:00 GMT

Thinking about the Open Service problem

As Havoc mentioned, I’m putting in some time on thinking about what an Open Service Definition (to parallel the Open Source and Free Software Definitions). I present here a rough draft of a framework for evaluating such a definition. It is not the definition itself, nor a license/technology/business model/etc. which follows the definition, merely a framework which will generate questions to ask and issues to cover when creating such things. It is not the only possible framework, either, but I think it is probably a good starting point to think about what questions must be addressed.

Some of these evaluation criteria will be familiar from the older definitions; some will have been implied by them but not widely discussed. All will still need elaboration, but I think it will be useful to write down how I’m thinking about the problem. Comments are welcome; email preferred, because of the complex nature of the problem, which I don’t think lends itself well to linear wordpress comments yet. If I’ve reached out to you recently about this problem, expect personalized email or phone calls in the next few days :)

All of these criteria involve sliding scales- obviously if a licensor moves any of them all the way to the closed/unavailable side you have proprietary or semi-proprietary software, but depending on where the lines are drawn, you have more or less onerous requirements with different outcomes- much like the current differences between more protective licenses like GPL and less restrictive but still meeting the definition licenses like BSD.

Goals The point of having open/free systems:

user freedom. results in security/autonomy/self-actualization/moral development/customer satisfaction/what-have-you. (Interestingly, neither the OSI nor the FSF definitions really go into why freedom or openness is actually good, which I think contributes to the lack of clarity around each.)
direct contribution to the codebase or otherwise to the community. Includes the free rider problem and possibly other collective action problems as well.
ecosystem participation. e.g., application development or API consumption. May include network effects and stickiness (both as a benefit and detriment.)

Evaluating these criteria differently will result in different values for the next two categories (preconditions and rights). For example, when in doubt the FSF favors user freedom, which means much stricter restrictions on redistribution than might otherwise be ideal for direct contribution; when in doubt Linus favors contribution and ecosystem participation and hence prefers GPL v2 to v3. And of course the Open Source/Free Software split was precipitated in part by an increased emphasis on ecosystem participation and decreased emphasis on user freedom.

I’m not entirely sure yet that direct contribution and ecosystem participation are really all that different in practice, but it seems they might be (particularly in an online context) so I’m keeping them separate for now.

Preconditions

If these preconditions are not met, then you can’t meaningfully achieve the rights listed below or the goals listed above:

data access: taken for granted until recently because our data has always lived on local drives, or on servers we controlled. As a result, this is implied by the Free Software Definition and yet not protected by the GPL (even v3). DRM falls into this area- the software or hardware takes away your data access, and hence deprives you of the user rights. Sliding scale includes not having any data access (many web services), having access to the data, but only as a binary blob (most end-user proprietary software), or having access to the data stored in standardized or otherwise open formats.
source access: as noted in the Free Software definition, this is a precondition for all other user rights. Sliding scale can include (among other options) mandatory provision (GPL v2), mandatory provision and reuse (v3’s tivo clauses), or no such (BSD.)
hardware access: never much discussed because, unlike everything else here, hardware actually is scarce, and so can’t be provisioned merely by good intent or good licensing. May make some sense to discuss in the context of servers, though- for example, if all your source is available, but it can only be run on multi-billion dollar server farms, is it actually meaningfully open? Does dealing with this angle require p2p solutions, or will single-point of failure solutions (with other safeguards) be sufficient?

It may make sense to speak of skills to manipulate source as being a precondition, alongside but distinct from source access. For the time being, though, I’m content to do what the FSF has done and say that as long as you have access to the source, you can buy skills from elsewhere and hence approximate the freedom of someone with the skills.

User data privacy is clearly important to the analysis of online services, but I’m not yet sure how this fits into the analytical model. It is often spoken of as a constraint on data access, so perhaps it fits as part of that criteria or sliding scale. Note also that there is a similar problem with the data which is created as a shared value- e.g., obviously my password is private when I contribute to Advogato, and so should not be shared, and my Advogato diary entries should probably (though not certainly) be removable, but what about the trust metric ratings I have contributed? Should they remain irrevocably available? Not yet clear where this fits in the criteria/discussion.

Rights

Rights available to participants in the commons.

use: this includes a temporal dimension, which open source has typically taken for granted, but which is now relevant for discussion in the case where servers/services go away (either maliciously or for other reasons.) This temporal aspect may make more sense elsewhere, since it has implications for things like server ownership and server governance. Note also that the v3 now includes some potential restrictions on use (where, for example, the network is damaged by modified clients.)
modify: as in FSF/OSI, pretty much, including sliding scale of options. May have some implications for APIs/service guarantees in an online context which are not readily comparable with the traditional model.
redistribute: as in FSF/OSI, pretty much, including sliding scale of options.

These are pretty much straight out of the Free Software Definition. I tend to think FSF freedoms 1, 2, and 3 have a fair amount of redundancy, so they get collapsed to modify/redistribute, with the assumption that redistribution means either modified or unmodified.

FSF calls these freedoms; I call them rights here because I personally tend to think of them as inalienable things which should be provisioned rather than optional things which can be taken or not. But neither term is completely satisfactory for this analysis, since saying that these are rights or freedoms implies taking a position on where on the sliding scale restrictions should be made.

Not clear where the question of who gets access to these things fits into the analytical model; OSI’s definition leaves that up to the license, and even FSF allows some fairly strong restrictions on who gets source access and hence gets to exercise these rights, so perhaps it is merely implied that that is part of the spectrum of options for each criteria.

Where to from here

I’ll be working with a number of people (both inside and outside Red Hat) to try to flesh this out in the next few weeks. I don’t expect we’ll really have pragmatic outcomes (i.e., licenses, business models) in that time, but I hope that we’ll at least be able to frame the discussion so that those writing code and running servers (including, but obviously not limited to the online-desktop) can think about the issues more easily and more transparently. As such, if there are other axes/criteria that need evaluation, I’m happy to discuss them with anyone- email or by any other way you can get a hold of me.

I’ll obviously be participating where appropriate in similar efforts- I’m not a fan of duplication of effort or NIH problems, so I welcome pointers to any advanced and pragmatic efforts I should be working with. But so far it is my observation that most open service definition proposals either have specific goals (i.e., they think there is a particular technical solution that must be used, or a particular policy agenda which must be advanced) or they have no code in the game, or both. I want to avoid the first problem, at least right now, by advancing a framework for discussion, and then allowing people with specific technologies/agendas/etc. to reason within that framework, rather than picking an outcome and then discussing a framework. I also want to take advantage of the opportunity to work with online-desktop in order to have someone implement the outcome- I think that it is only by implementing such technologies that we’ll actually get a good understanding of what licenses, business models, governance systems, etc., are really appropriate. So far it seems that other such proposals have not had this key element of real-world application in place. (Plan to throw one away; you will, anyhow.)

I’ll probably be wikifying this all soon as well (as soon as I can figure out where, and figure out how to keep the signal/noise ratio high); the wiki will include source links to the various places that have provided background or information for this, as well as some more details and questions that are still very much unanswered. In the meantime, thanks to various people, including Kragen, Mako, Mike Linksvayer, Gabriel Burt, Havoc, and many more who have influenced my thinking on this. (Including Stallman- who, whatever else you may think of him, is the reason we’re all here.)

quick notes on Freedom and "Michael Hardt presents Thomas Jefferson"

Sun, 22 Jul 2007 00:00:00 GMT

[If man is meant to be free] the secret will be found in making himself the depository of the powers respecting himself, so far as he is competent to them, and delegating only what is beyond his competence… so as to trust fewer and fewer powers in proportion as the trustees become more and more oligarchical.

—Thomas Jefferson, letter to Joseph C. Cabell, Monticello, Feb. 2, 1816

I spent the morning writing about Freedom, and then, post unfinished, went shopping for some lawyerly necessaries. Along the way I wandered into the Apple store, played with an iPhone, and got my confidence in freedom shaken a bit- the thing is very, very good; polished in a way that no current free desktop app (much less the N800 or openmoko) are.

So I spent the afternoon reading a selection of the writings of Thomas Jefferson, hoping to get some inspiration both on the writing of manifestos and on their implementation. The work is titled ‘Thomas Jefferson, The Declaration of Independence’, but it is only in part about what is probably the most successful revolutionary manifesto (even if we don’t often think of it as such.) It contains an essay by Michael Hardt, along with a selection of Jefferson’s letters on the problems of rebellion and revolution. In particular, it focuses on the problem of transition: what happens when your revolution is still young and shaky, what happens when your friends try revolution and it fails, how often revolutions should occur, and so on.

It didn’t exactly make me feel too much better about the iPhone, but it was stimulating. In particular, the talk of France (where during Jefferson’s lifetime a democratic revolution occurred, got violent, and then resulted in Napoleon) and of Shays’ Rebellion were both quite interesting- two events that could have shaken the faith of a young experiment in democracy, but which Jefferson took in stride, and to some extent celebrated or used as teaching moments. We are still in the very early stages of our experiment with social production, and no doubt some things (like the iPhone) will shake our certainty in what we do, so there are perhaps some lessons to be learned there.

Similarly, the discussion of the frequency of rebellion was interesting. Jefferson posits that revolutions (of a sort) should occur every 19 to 20 years, specifically because (given the 55-year life expectancy of his day) every 19 years a majority of the adult population will no longer have given assent to the constitutions formed by the previous generation. They might passively assent, and even participate in government, but Jefferson argues that without active participation in the forming of a new constitution, they are not really committed to the government that results from it, nor fully understanding of what it means. [The parallels to GPL v3 as a periodic re-commitment (or not) to a particular vision of freedom are so obvious that I forgot to actually write them in here when I first wrote this down ;)

I could go on and on- there is discussion of education, of the role of self-governance as a means of education, etc., much of it relevant to free software and more generally to social production. Really interesting stuff. But instead of rambling and boring people, I’ll just go finish Wealth of Networks instead ;)

blogging is dead, long live communicating

Mon, 16 Jul 2007 00:00:00 GMT

This is hardly an original sentiment (we had it from time to time at Berkman when we discussed whether or not it made sense to have meetings for blogging) but I think Jonathan puts it well:

But I’d love it if we one day eliminated the term “blogging” from the web lexicon (and that we stopped pursuing “CEO’s who blog.”). CEO’s who have cell phones aren’t “cell-phoners,” those who have email accounts arent “emailers,” those who give interviews on television aren’t “TV’ers” - they’re all leaders using technology to communicate. Communication is central to leadership - using words, written or spoken, to articulate strategy, guide organizations, engage in dialog, and… lead. Leading two or 200,000, you can’t do it without communicating. Using technology just leaves more time for everything else (I’m not saying stone tablets can’t be effective, they just take way longer to distribute).

This isn’t to say that blogging isn’t different from email (and stone tablets), but most discussions about blogging would be much better off if we analyzed ‘communication that is public, searchable and persistent’ instead of ‘blogging’, a term which (bizarrely) has picked up almost mystical connotations amongst some people.

great licensing wisdom from J. Schwartz

Tue, 03 Jul 2007 00:00:00 GMT

“One of my great fantasies in life is that the number of people with opinions on open source licenses will come roughly into balance with the number of people who have read them.”

— “Sun CEO Mum on GPL v3”

Infotopia, information-gathering, and software QA

Tue, 03 Jul 2007 00:00:00 GMT

A couple of weeks ago I finished reading Cass Sunstein’s Infotopia. While certainly not a perfect book by any stretch, it gives a stimulating overview of a central problem for any society- how it collects and filters information so that it can make decisions. Being a good U of C guy, he starts with Hayek’s notion that the price mechanism is an elaborate mechanism for ‘sharing and synchronizing local and personal knowledge’ (to quote Wikipedia), and then goes on to discuss other mechanisms for getting information out of the heads which contain it- wikis, open source, democracy, polling, deliberation, prediction markets, etc. An interesting read to frame a lot of discussions around.

One of those discussions came up today. Quite simply, the big problem in QA is getting information about the state of the software out of the software and into the hands of developers as efficiently as possible.

This has three aspects: creating the information, getting it in the hands of the QA teams, and then filtering it into a form that is useful for developers to work on. Traditional QA has a very hard time getting the information- there are a lot of lines of code to be exercised, and very few people exercising the code (relatively speaking.) It is like squeezing water out of a stone, so they have to do a lot of things (like extensive automated testing) to get that information. The output is a relatively small amount of very regularized data, which is easy to present (though hard to weight efficiently and accurately.)

In contrast, open source QA has a whole ocean of information from the legions of volunteers willing to run pre-release code; the trick is to tap into that water without drowning in it. It isn’t regularized, but given a large enough body of users over time, you can be fairly certain that the bug reports will represent an accurate cross section of your problems, and the interaction with real users (instead of interaction with automated test tools or third-hand via the sales/customer relationship) can give you a fairly good idea of what bugs are actually important to real people.

If you’ve got one person to work on QA, I’d say you always want to swim in the ocean instead of doing any amount of automated squeezing information from the stone. This is not to say automated testing doesn’t have its place- in particular, good unit testing captures information at a very high-efficiency junction (when the original author is writing code) and then gives it back in a very compressed, efficient form that the developer should know immediately how to prioritize and deal with. Similarly, automated tests that attempt to capture regressions once a bug is fixed are also fairly efficient- they capture information which real humans in the field have identified as an important problem, and they again report simple, clear, efficient information- this bug # and commit # which were fixed are now not fixed. But generic ‘well, we’re going to write tests now because that is how we did it when we had no users willing to help us test’ testing is a very inefficient use of manpower- it is trying to dig a deep well to get information when you live next to a deep, clear, safe mountain lake.

So there you have it- proprietary QA is trying to squeeze information-water from a stone; open source QA is trying to learn how to swim in a sea of information. I know which problem I’d rather have.

quick pondering on artificial scarcity

Tue, 03 Jul 2007 00:00:00 GMT

This deserves to be developed more fully, but perhaps the thread that ties together my irritation with the MS-Novell deal, my irritation with the Mozilla TM licensing, and what worries me about the push against copylefted DB data, is the creation of (or in the DB case, allows the creation of) artificial scarcity. I’m OK with charging for things that really are scarce- cars, service, etc., but creating artificial scarcity, either through the use of patents, copyrights, or trademarks, or by allowing others to use trade secret and SaaS tactics to take data from the commons and then proprietarize it, seems problematic.

(This is hardly an original thought; I just wanted to get it out and searchable later, since I’m wrestling with the trademark demon again.)

post-GPL link dump

Sun, 01 Jul 2007 00:00:00 GMT

Several weeks worth of links, dumped:

a law firm that actually wants to encourage productivity and efficiency through competition is either brilliant or terrifying, or maybe both.
I think there is much truth in what Jason is saying about the web; a desktop that provides high-quality free horses and buggies is going to get whooped by advertising-supported cars. The free software desktop may need to start thinking of working with proprietary web services like Stallman and co. used to think of working with proprietary kernels. i.e., until someone builds us a truly open linkedin we should probably go ahead and start using stuff like this, no matter how bad they are abusing the term ‘open.’
in the end, government funding may make a lot of sense for creation of commons like Wikipedia (see Terry Fisher’s Promises to Keep for an analysis of why it might be the most sensible option) but the lack of competition and market incentives when government gets involved still creeps me out.
speaking of open music and proprietary web services: some good thoughts on how to make open music mainstream. Most important point: there needs to be a centralized, open-only equivalent of last.fm that combines streaming and recommendations.
this is a long but fascinating essay on the negative impacts of fear on society, by way of Schneier.
interesting pondering on the GPL and VCs.
Google is beginning to push the idea that government censorship of speech is a defacto trade barrier which works against American companies. Bill McGeveran explores/summarizes. This may be the only way to actually resolve the problem Google is trying to tackle, but it is pathetic that we have sunk to the point where we can only defend basic human rights like free speech if we can couch them in terms of the market.
Steve Jobs may have the best design sense in software, but if you support his company, you’re still selling out the open, competitive, non-duopoly software ecosystem. Moz COO explains.
This looks like a fascinating set of readings on innovation, collaboration, and infrastructure for the next time I have free time… 2009?

GPL v3, the Q&A: part 3- companies

Thu, 28 Jun 2007 00:00:00 GMT

(Before going further, you should (at the minimum) read the disclaimer on Monday’s post and (ideally) make sure you’ve read all of the past two posts. (first, second.))

Q: Companies hate this! The sky is falling if the GPL is adopted!

A: Find your calm place. There is no doubt that the new license will create new uncertainty, which companies hate, and that the license seeks to place rights more firmly in the hands of users, which many companies (though not all) hate. So companies have reason to be nervous.

But the license was created with input from an extensive range of companies who both produce and use free software-based products, so I think you’ll find that it really isn’t that bad for companies who are playing by the rules- that is, for 95% of companies, 95% of the time. Remember, this license is (for most purposes) much more evolutionary than revolutionary, so it gives the same rights, sometimes clothed in different languages, in most circumstances. Most companies will not be affected by the tivo-ization and DRM clauses, and will actually appreciate the additional protections of the new license. Especially once companies have had time to digest the license, and to realize that none of the early adopters have turned into a newt, most companies should be fine with the license most of the time.

Q: OK. A little calmer now. My company makes products based on open source components. What are my new risks?

A: Have you burned the boats? If you’ve truly burned the boats, you’re fine- the patent provisions and installation provisions of the license only help you get closer to your customers and differentiate you from competitors and free-riders.

On the other hand, if you or your customers are still relying on some form of proprietary lockin, the picture is much less clear. You have new responsibilities that you may not have previously had. In particular, if you contribute to GPL v3 projects, you have to open up your patent portfolio to those projects and their users, and if you distribute GPL v3 code, you have to give your users the ability to reinstall code that they modify with very few restrictions. These may not be dealbreakers, but if your business model depends on users who are somehow kept under lock and key, you will have to deeply examine the new license, and may have to reconsider basing your business on GPL’d code.

Q: Do I get any benefits to go with those risks?

A: Like everyone else, you should get greater certainty about patents, and greater legal certainty in general as a result of the improved language. The same clauses that protect your customers from you will also protect you from competitors who seek to use some sort of patent or device lockin to compete unfairly against you, so even they aren’t all bad.

You’ll also get more control over trademark as part of the compatibility with the APL- you can explicitly ban use of the trademark by derivatives, among other things. Most community projects are not overly concerned by trademark, but this is clearly important to companies who are trying to build a brand, and more explicitly spelled out now as an optional addition to the license.

You also get the ability to transmit code to contractors without being considered to have ‘conveyed’ the code, allowing you to use consultants and outsourcers to modify your private code forks without accidentally freeing your work. If you sell non-consumer products (IBM S390 servers, for example, or medical devices which might be under government regulation) you are now even allowed to prevent modification/reinstallation by those who you sold servers to.

If you’re using patents or hardware to lock in your customers, none of these things are going to be much solace. But for everyone else, they should be useful compensations which make up for the short-term uncertainty.

Q: Why is Sun seemingly so excited about this? Should I share their enthusiasm?

A: Maybe. Sun is in a fairly unique situation. They badly want to win developer mindshare away from Linux, so becoming More FSF-Free than Linux is a big PR win for them- more so than it might be for most companies who aren’t competing with one of the poster children of open source and with the ghosts of their own proprietary past. In addition, some of the license features which are problematic for many people may be a benefit to Sun. For example, most people will look at v3’s incompatibility with v2 and think ‘what a pain’. Sun, in contrast, might think of that as a benefit, since that would continue to prevent Sun code from being used in the Linux kernel- who have to be seen as a significant competitor for them. Similarly, the new clauses which make embedding and DRM difficult may be seen as a detriment by many developers, but they play very well into Sun’s business model for Java, which is based on licensing into the embedded market. Anything that encumbers Free Java helps drive embedded market revenue for them, so GPL v3 may be preferable to v2 from that perspective.

All that said, we should probably give Sun some of the benefit of the doubt at this point- they’ve freed a lot of code, and by all accounts are trying hard to become a more open company. If they really wanted incompatibility and embedded revenue, they could just stick to the CDDL or a proprietary license. GPL would be a huge step for them, and is a step that the Free Software community should welcome with open arms, even if their motives are not 100% pure.

Q: Should Novell be quaking in their boots?

A: Hard to say. With their recent joint announcement with the EFF ((which I’m embarrassed I haven’t covered in more detail- it was a bold move by Novell, given their conservative history, and the announcement deserved more attention than it has gotten)) they appear to have started the process of really burning the boats. A company fully committed to competing on the basis of quality and service, and willing to say no to customers who ask for bad things, should have very little to fear from GPL v3, and it seems like (belatedly) Novell may finally be headed in that direction.

Q: But Novell are on the hook for the MS deal, right?

A: Yes and no. While a deal like the Microsoft-Novell deal, which induces a third party to grant a non-assert agreement, older deals got grandfathered in- the FSF appears to believe that it is better to have Novell tentatively on our side than actively using their large warchest to fork everything that goes v3. ((This clause also prevents Sun and IBM from having to review every patent licensing deal they’ve ever conducted- which is probably a good thing, since given a choice between ‘pay lawyers to audit and renegotiate potential tens of thousands of contracts’ and ‘skip the GPL v3 party’, they would almost certainly chose to skip the party.)) But it seems unlikely that MS can continue to uphold their part of the deal without licensing their entire patent portfolio to some key technologies like gcc and libc. So MS has a strong incentive to get the deal voided, and even if not, it will expire in the not too far future. (Remember, they negotiated a license which only covers five years of twenty year patents.) If they do renegotiate, the new deal will almost certainly look like the Xandros and Linspire deal, where MS offers indemnification to individual users instead of to all users. This will be acceptable under the new GPL language.

Q: So can we break out the champagne? Is the MS patent threat over?

A: Definitely not. MS can, of course, cease giving out coupons, and try to induce Novell to adjust the deal. Moreover, because of the complexity of the patent language, there is almost certainly another loophole for them to exploit, though it is hard to see what it migh be at this time. They could, for example, offer indemnification directly to customers- which appears to be the route announced in the Xandros and Linspire deals. ((FSF appears to be OK with this, since that route does not break away a chunk of supporters.)) Even if they do continue the relationship with Novell, lots of very big chunks of code that aren’t GPL v3, like the kernel and Open Office, will not be protected. So we’re still dead in their sights, no matter what.

Q: What does MS think, anyway?

A: They are gearing up their FUD machine, of course. Expect the old reliables: GPL is anti-American, GPL will steal your rights, GPL will eat your babies. Expect some new favorites too- lots of talk about how MS ‘builds bridges’, and about how the GPL hates interoperability. Of course, no mention will be made of the tolls that MS wants to charge on those bridges, or of the tons of GPL licensed code which builds bridges both to open standards and (despite the difficulties) to MS ‘standards.’

Q: What about the little guys in the embedded/consulting space? Opened Hand, Fluendo, etc.?

A: Each will have their own sets of problems and evaluations of the license. The new LGPL should allow Fluendo to continue down the mixed proprietary/open path they have chosen. Perhaps a more difficult question is what this will mean for those who are thriving in the embedded phone/handheld device space, like Opened Hand, OpenMoko, etc. The new license would appear to require that they allow modification, even for things like phones- which may be very problematic for networks (despite the out for network service providers included in the license, which allows you to withdraw services from modified devices if the modifications cause problems.) It will be interesting to see what openmoko’s lawyers say- they appear committed to resolving the problems between a locked down network and an open device, but this may be too much even for them to overcome. ((Perhaps we’ll have to wait for voip over wimax to get truly open wireless devices. :/ ))

Q: What about Google and other SaaS companies?

A: Nothing here that impacts them; they can continue business as usual. There is a new Affero GPL, which closes the SaaS loophole, but the FSF has made it clear that for now they will use moral persuasion rather than licensing to encourage code to migrate out from behind the closed Google doors. You might call this ‘picking your battles.’

Q: what is the bottom line for companies and the GPL?

A: For most? Simple. If you just use GPL-licensed code (for example, as a server or desktop), you have no worries. If you contribute code to GPL projects, you’re OK, as long as you feel comfortable granting your patents to the version of the project you’re contributing to. If you distribute GPL code as part of a device, you’re also OK, as long as you allow users to modify their devices. These categories cover the vast majority of corporate participants in the existing GPL community.

Despite that, this won’t be a license for everyone; some companies may prefer to stick with v2 or perhaps even use other alternatives instead. Like the choice for developers, the choice will require a case-by-case analysis of the costs and benefits. I do look forward to the day when we have a new license, representing a new and appealing business model which makes these kinds of choices easy, but for right now we’re stuck doing the hard and sometimes unpleasant work of protecting more user rights, and that means compromise and muddiness, not clear wins. Sorry about that…

[see all parts: part 1, part 2, part 3, part 4.]

GPL v3, the Q&A: part 4- odds and ends

Thu, 28 Jun 2007 00:00:00 GMT

These are the last odds and ends of my GPL Q&A series. I may or may not find the energy to elaborate on the patent and DRM provisions tomorrow, since those seem to have generated the most questions, but I may not- I’m completely destroyed right now, and I plan on going to a baseball game tomorrow night and having a beer instead of writing. Generally, I do not recommend writing about something at work all week, and then coming home at night and writing more, in a different voice, for a different audience, and all while trying to maintain your impartiality and mental walls on both sides. Draining.

Q: Tell us how you really feel about the ‘pragmatism v. idealism’ framing of the Linus v. FSF camps.

A: Argh. While it certainly isn’t untrue, I think it is a lot more useful to frame the camps in terms of being split by focus on rights of developers v. rights of users. Both camps get pretty irritated when they feel their real rights are being violated- plenty of members of both camps have tromped around enforcing their copyrights when they feel they need to, and both camps feel very strongly about their visions of how the world will or should be (Linus may not say ‘should’ a lot, like Richard does, but the world domination talk is most definitely a driven vision of a specific world that he likes.) And both sides are willing to compromise on methods as long as their goals are reached. (Do you really think RMS consulted with IBM and Sun on v3 just because he is a nice guy? No; he’s just a ruthless pragmatist when he wants to be.) This isn’t to say there isn’t a lot of truth there; the meme wouldn’t be so pervasive otherwise. But both parties have a lot more in common than recent coverage and discussion would have you believe.

The pragmatist/idealist framing not only isn’t terribly accurate, it isn’t very useful. It makes for an easy story for journalists, but past that what is mostly does is to encourage both sides to think of the other side as either crazy or immoral, when in fact they share a ton of common ground. (If their mechanisms and goals didn’t overlap, the fundamentally user-focused v2 wouldn’t have been so wildly successful with developers.) If the FSF spoke specifically of user rights instead of generic rights (which are easier to mischaracteriz/ridicule), and addressed developer rights as a complementary set of rights instead of something secondary, it would help bring everyone together as peers using the same language instead of frequently ridiculing each other. Similarly, if the ‘pragmatist’ camp had admitted that they too were concerned with rights- just a different, perhaps more limited set- it would have helped them get more of what they wanted (simpler language, for example) out of the FSF. Of course, it is too late now for this round, but I think both sides should work on expanding those common grounds in the future. In the meantime, the rest of us will have to sit back and watch while they snipe at each other and Microsoft has the last laugh.

Q: While you’re venting a bit, have a blast: how do you feel about the claims that the v3 is ‘political’?

A: The use of ‘political’ as a slur against v3 demonstrates an abysmal understanding of both the specific history of free software and the general history of how rights evolve.

Yes, v3 is certainly political, in the sense that it claims the existence of “rights” that are controversial, and hence whose existence (or non-existence) has to be resolved via political/social means instead of judicial/analytical means. But all of these things were also true of v2. We’ve now reached the point where even Microsoft has mostly accepted that developers have the right to share if they want, and that community development is a valid and respectable way to develop software. Given that, it is easy to forget that in 1991, the notion of sharing and openness in code was controversial, and that as recently as a few years ago Microsoft was denouncing it as unamerican. If we’d listened to those who dismissed v2 as ‘political’ (or worse) in 1991, we wouldn’t be where we are today. So dismissing anything now because it is ‘political’ (instead of actually discussing the merits, which I fully admit are arguable) would be silly.

More generally, the v2’s transition from ‘political’ to accepted right is a fairly common trend in Western political history, as rights go from non-existent to hotly politically contested to taken for granted. Again, to dismiss something as ‘political’ demonstrates a great deal of ignorance of these broad historical and political trends. A good comparison is women’s voting. We take it for granted, and don’t think of it as ‘political’ anymore- it is now a core right, very broadly accepted. But when women first proposed that they should be able to vote, the question was very much ‘political’- protest marches were held, proponents were scorned, and the process took decades to go from proposal to accepted fact. Now, of course, you could be raised and come to adulthood without ever being aware that it women ever were denied this fundamental role in our society. As it has with the attempted creation of new rights in v3, new issues have evolved from the suffrage movement, like the rights of women in the workplace and affirmative action. The historical question is not whether it is wrong to bring these issues up for being ‘political’, but rather whether in 15 years we’ll see DRM as being more like the rights of women to work (was “political” after voting rights passed, now no longer controversial) or like affirmative action (was “political”, still is in many places.) Either way, the right way to tackle the issues is on the merits- not to use political as a slur.

Q: Back up a bit to day 1 and get off your high political horse. You said GPL v2 is incompatible with GPL v3? That doesn’t make sense.

A: Stallman explains it pretty well here:

When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn’t do the job, because GPLv2 would need a similar clause.

Because of this clause, “compatibility” with GPL is always a one-way street- I may be able to convert BSD or APL code into GPL code, but I can’t do the reverse. GPL with itself is no different.

Q: So, uh, isn’t incompatibility bad?

A: The incompatibility does restrict your ability to cut and paste code directly from one codebase to another. But past that, it probably won’t matter much. ((If you’ve seen an O’Reilly article arguing otherwise, ignore it- or at least go back and read the comments, particularly those from Richard Fontana. The article seriously misunderstood a lot of things.)) Again, quoting Stallman:

Fortunately, license incompatibility only matters when you want to link, merge or combine code from two different programs into a single program. There is no problem in having GPLv3-covered and GPLv2-covered programs side by side in an operating system. For instance, the TeX license and the Apache license are incompatible with GPLv2, but that doesn’t stop us from running TeX and Apache in the same system with Linux, Bash and GCC. This is because they are all separate programs. Likewise, if Bash and GCC move to GPLv3, while Linux remains under GPLv2, there is no conflict.

Q: Talk to me more about this APL compat. Are we going to have GNU/httpd now?

A: The one-way compatibility of GPL (mentioned above) isn’t something that is ‘hidden’ when FSF talks about compatibility- it is very deliberate, very public, and very explicit. So this new compatibility means that one-way GNU forks of Apache projects are now a legal and theoretical possibility. But pragmatically, it seems unlikely- the Apache folks have well organized communities that would likely outcode any fork, and when Mozilla went dual-license, Stallman specifically recommended against such a fork. It seems unlikely he’d act differently now- the goal of this compatibility has been to increase the ability of free software communities to work together, not to split them apart. ((Note that I’ve been told that GNU has done this in some cases, like gnash, so YMMV.))

Q: What about the Internet and Software as a Service?

A: The FSF’s relationship to software delivered over the internet is ambiguous. v3 explicitly maintains the loophole for software whose UI is delivered over the internet, so someone ((*cough*google*cough*)) can still do things like take GNU code, replace the terminal interface with an html interface, distribute it to the world via http, and not provide your modifications upstream. At the same time, FSF does endorse the Affero Public License, which closes that loophole. If you’re worried about that problem, you can definitely use the Affero instead of the GPL.

Exactly why the FSF hasn’t closed the loophole in the GPL and is instead offering the Affero is unclear; if I were a betting man I’d say that the FSF would prefer to use moral pressure on Google and friends, rather than legal pressure until Microsoft is no longer a threat. The phrase is ‘pick your battles.’ You can see Moglen talk a little bit on this subject here. (Be forewarned: I normally think that Eben is one of the world’s best at taking difficult concepts and expressing them orally, but this isn’t, IMHO, Eben’s most lucid talk, perhaps because so much of it may be intended to be read between the lines.)

Q: Any thing you missed or badly screwed up in the first few days?

A: The biggest was that I neglected to mention a significant downside to dual-licensing. When you dual-license, you limit the code you can copy and paste into your own code base to the set of code which shares the same license you do. So, for example, Mozilla (which is triple licensed) can only copy from code bases which share the same three licenses- that is to say, virtually none. Not only does this make it more difficult to reuse code from elsewhere, it also makes it easier for forks to occur. For example, Flock is a GPL-only fork of Mozilla. This means that when Mozilla makes fixes, Flock can take them, but not vice-versa.

I also overlooked another option, besides outright copyright assignment, for handling the ‘or later’ problem- the license allows assignment of a proxy who can decide whether or not to upgrade to future versions of the license. This allows you (for example) to assign the right to upgrade to GPL v4 to the GNOME Foundation, without having to trust them completely enough to do a copyright assignment, while still allowing the Foundation to set some coherent strategy when the next license comes out. It seems like this is something that organizations who intend on being around for the next 16 years might want to consider as a lighter weight alternative to copyright assignment or just blindly trusting in ‘or later.’

Oh, and I’m not doing the all-caps thing; that is my theme. Sorry about that; I intend to fix it at some point. Q: parting shots for now?

A: This license is an evolution, not a revolution; a good one that lots of projects will adopt, but which won’t (quite literally) change the IT world like v2 did. The revolutions are still to come- when we figure out the licenses for things outside of copyright (like web APIs, standards, personal data, and trademark) that give us great developer benefits and improved user rights, like GPL v2 did, we’ll see explosive growth in those spaces.

[see all parts: part 1, part 2, part 3, part 4.]

GPL v3, the Q&A: part 1- the license

Tue, 26 Jun 2007 00:00:00 GMT

Q: So why are we here? A: At the end of this week, after 16 years, the Free Software Foundation should bless version three of the GNU General Public License, the sequel to what is arguably the most widely used and most impactful copyright license ever. ((Microsoft’s licenses are possibly more widely used, but only by a handful of pieces of software; the various Creative Commons licenses are probably also more widely used but (for better or for worse) have not yet set billion dollar industries on their ear. Really, we owe to GPL the notion that a copyright license can actually be important at all.)) Quite literally everyone who makes software - open, proprietary, or web - needs to understand the v3 and figure out if it is evolutionary, revolutionary, or DOA, and how it impacts them as a potential contributor, consumer, cooperator or competitor. This is my small contribution towards that understanding.

Q: Can you summarize this Q&A in a haiku? A:

new license rolls in stormcloud- large, complex, strong, dense scares, but should bring rain

(I really, really wanted to use “Snuffleupagus” in that, but sadly that doesn’t leave many syllables for imagery.)

Q: Why did you feel the need to summarize in haiku?

A: Because this was the longest blog post I’ve ever written. It is now going to be in (at least) four parts over three or four days, so you’ve been warned: you might want to leave off at the haiku :)

Q: Any disclaimers before you get rolling?

A: Tons. I am not a lawyer; whether I’m even a particularly good law student is still up in the air :) Don’t rely on this for legal advice.

I’ve based this commentary on the final discussion draft of the license; changes between now and the final, final version may invalidate some of my claims.

I’ve been on GPL Commitee A, so I’m predisposed to believe the FSF and SFLC’s interpretation of the license. On the flip side, I may not have learned much from that experience; mistakes are my own and may be plentiful.

Finally, I’m currently a Red Hat employee, but this is emphatically not a statement of Red Hat’s policy or interpretation of the license. No one at Red Hat has read this or commented on it beforehand, so again, mistakes are my own and may be plentiful.

Q: Why are we doing all this again? Isn’t GPL v2 reasonably good?

A: As I already mentioned, GPL v2 is almost certainly the most important and successful copyright license ever. By ensuring cooperation instead of competition, it has played a critical role in creating the large and thriving free/open source ecosystem. By providing a robust legal framework, it has provided predictability and protection for everyone who uses it. And by protecting the rights of users, it has done a fairly good job advancing the explicit goals of the authors of the license. So one has to consider it incredibly successful- especially considering that it is a legal document which most lawyers considered insane for a long time, and which still makes many uncomfortable.

That said, the license was written in 1991, and the computer industry has changed a lot since then. Patents have become a much more critical issue for the industry- in 1991, Microsoft had only just begun to understand how important patents would be to locking out new competitors. In 1991, the idea that computers would be the dominant form of media delivery would have been fairly ludicrous, much less the idea that software would be legally protected against “tampering.” And since 1991, the free and open source software community has gone from being a decent number of volunteers and one company, operating primarily on an informal basis, to being millions of volunteers and a multi-billion dollar industry, with all the legal structure, firepower, and infighting that implies. So an update was probably not a bad idea. ((Novell’s decision to expose a real loophole in the patent language of the old license was only icing on the cake; the process was well underway before that happened.))

Q: So what should a rewrite have done? A: That is the million dollar question. While few people think of it that way, the FSF is a user-focused organization. GPL v2, to them, was about protecting the rights of users to control their own computing devices. The pragmatist camp sees GPL v2 as being about the rights of developers to progressively expand the commons and prevent bald-faced exploitation of their labor, a la Apple/BSD. These camps aren’t mutually exclusive- many of the license features which the FSF originally intended primarily to benefit users have been beneficial for developers, and obviously the thriving developer community is beneficial to users. But members of both communities often seem happy to trade away the rights of the other parties if there is a conflict.

Given that broad background, FSF’s specific goals for v3 were to protect user freedoms from ‘new’ threats like patents, DRM, and tivo-ization, while benefiting (or at least not alienating) developers. To the pragmatist camp, if there were to be changes, they needed to make life easier for developers- including not just individuals, but corporations. Since no one could think of any significant way to improve on the old license in that respect, they wanted to focus primarily on simplifying and strengthening what was already there.

Q: Given the success and the controversy of change, has the license really changed that much from v2 to v3?

A: The core goals, methods, and structures of v2 were successful and have been carried over with very few changes. If you use GPL code and do not redistribute it, you still get to do whatever you want with it. If you modify and redistribute GPL code, or build new applications on top of GPL-licensed libraries, you still have to release modifications and derivatives as GPL-licensed source. And you can can still build ‘immoral’ (aka, proprietary and/or DRM) code on top of the new LGPL. Some of the language has been changed enough that these goals may be hard to find in a casual read- but they are very much still there.

Q: What has changed, then? A: A few major changes (note that some of these have been grossly oversimplified to be audience and scope appropriate; please don’t jump on me when I’ve not noted exceptions, loopholes, etc.) Note that I’ll have more on several of these over the next couple of days.

internationalization: the new license moves away from language like ‘derivative’ - which comes from US copyright law - in favor of language which does not exist in any system of copyright law. This is excellent in theory- it should make the license more politically palatable and legally enforceable outside the US. In practice no one can really know what courts will think of this until it is tested. ((The Creative Commons lawyers think this approach is borderline insane, but their approach- one license per legal regime- drastically increases license fragmentation, which we know is a very real problem.))
increased complexity: this tries to be a more lawyer-friendly document. It is not clear that it succeeded. Regardless of whether the lawyers like it, it is definitely less clear for hackers and executives on first glance, and that may slow uptake. ((Note that v2 isn’t nearly as clear as people would like to think- much of the supposed ‘clarity’ is really just the result of living with it and interpreting it for 16 years.))
patents, the straightforward part: the license attempts to create an explicit and irrevocable patent grant extending from all contributors to all users. If you contribute a substantive patch upstream ((not just any patch; it must be meaningful enough to be copyrightable)), you’re granting a patent license to the whole project. Merely distributing without copyrightable contribution, like IBM does with many GNU tools ((edit later: IBM contributes to a number of GNU tools like gcc and classpath, I don’t mean to downplay that. Just that they also distribute the entire GNU user-space stack on AIX, which is the biggest example of ‘simple’ distribution that I know of.)) still does not grant a license. This should help create more certainty about the patents owned by our major contributors- the folks like Sun, Novell, etc. - but it doesn’t help against those who don’t contribute code, like Microsoft and patent trolls. So the impact is positive but limited.
patents, the complicated part: a lot of verbiage has been added in an attempt to prevent future blanket indemnifications like the Microsoft-Novell deal, and to ‘trick’ Microsoft into granting us their patents. I won’t go into these in much depth because I’m pretty sure they don’t buy us much - it looks like the Xandros and Linspire deals are already structured to avoid triggering these clauses, and there is no reason to believe that Novell and Microsoft can’t do the same. So net result here is probably that only the worst abuses of the old language, like the current Novell deal, are prevented. Not bad, but not the end of the Microsoft problem by any stretch.
user control: the new license tries to make it clear that users have the right to control their hardware and software. This takes two forms: first, it forbids a claim by distributors of GPL’d code that the code is part of an ‘effective technical protection measure’ and second, it explicitly guarantees that installation instructions (including all the necessary tools and keys) must be available so that users can modify their software and reinstall it on devices that they own. This language, while not always straightforward, should mean that consumer-level users of GPL v3 code should be able to reliably modify the GPL-licensed code on devices that they own.
license compatibility: the new license is compatible with the Apache Public License, so if you’re working on GPL v3 code, you should now be able to copy and paste from APL-licensed code. This does not mean that someone working on APL-licensed code can copy and paste from GPL v3 licensed code, though- compatibility with the GPL is always one way. (And the same applies to GPL v2 code- you can’t copy out of GPL v2 code, even into GPL v3 code.)

Q: So did the FSF reach their goals?

A: Since the FSF was in control of the process, the changes have focused on users rather than developers. Developers don’t necessarily fare poorly, but where there is choice between user freedoms and developer flexibility, the balance always tilts towards users. If, despite this, developers choose to use the license, it should give users and developers more certainty about patents, and it should ensure that users have the legal rights to control the devices that they own. ((Of course, those new rights only help you if you’re also a hacker, or can afford to pay one to hack for you. But this was a problem with the v2 as well.)) Overall, then, a win for the FSF.

Q: Bottom line- in a year, what are we going to be saying about GPL?

A: Over the next few days I’ll explore the details of how developers and companies might feel about the new license, but I think the bottom line is that within a few years many will switch over. Communities who feel particularly threatened by patents, who badly want to draw from Apache, or who are particularly inclined to protect users and disregard possible costs to developers will adopt it particularly quickly. After that, adoption will slow for a while, but as users, developers, and corporates get comfortable, the various small improvements will gradually make it the default license for a plurality of new open source code, despite the understandable reservations (some well-grounded, some not) that many people currently feel.

[see all parts: part 1, part 2, part 3, part 4.]

GPL v3, the Q&A: part 2- developers

Tue, 26 Jun 2007 00:00:00 GMT

(This is part two of a series. Before going further, you should (at the minimum) read the disclaimer on yesterday’s post and (ideally) make sure you’ve read all of yesterday’s post.)

Q: Has there ever been a sequel that wasn’t terrible?

A: Godfather II and Star Wars II. (I refuse to call it V.) I’m no Coppola, but I hope I’m better than Lucas. We’ll see.

Q: I’m a developer, and my current code uses GPL v2- should I update to the v3?

A: Probably. While the license does not include any huge wins for all developers that would make an upgrade obvious or mandatory, there are small wins here for virtually anyone who seeks to have a functional FLOSS project. In particular, every developer should appreciate the improved (if still imperfect) patent protection, the ability to copy and paste APL-licensed code into your code, and the internationalized legal language, offering them stronger protection outside the US’s copyright system.

In addition, those developers who object to TiVo-ization of their code, or to the use of their code in a DRM system, will like those sections of the new license. As I mentioned yesterday, these sections of the code may not be perfect, but they should go a long way towards ensuring that users of your code always have the right to access it and modify it- something that wasn’t necessarily clear under the old license.

Q: There must be some downsides.

A: Absolutely. I f you adopt now, you’ll be on the bleeding edge- with all that entails. You’ll have to explain the license over and over again to people, explain why you’ve chosen it, and so on. That won’t be fun, and you may lose some contributors over it. There is also the possibility (though small) that you’ll have chosen incorrectly, and that there will be some flaw in the license. While this seems unlikely ((the license has been vetted by a lot of very skilled lawyers and a fair number of common-sensical hackers, and even in the worst case, you should get the same rights and protections you do under v2)) it isn’t impossible, and you will be taking that risk by switching before the license has been out for a while.

You’ll also lose compatibility with GPL v2- you’ll be unable to copy and paste code from (or to) any part of that huge base which is not under v2 ‘or any later version’. Depending on how you develop, this may be a big downside, or it may not. But it is one to be aware of. (More on this in a later post.) Similarly, if there are applications that link against you or otherwise share your code, and they are not ready to relicense, that may weigh against a relicensing as well, since GPL v2 apps can’t link against GPL v3 apps. ((The current FAQ suggests that v2 apps can’t even link against LGPL v3, but SFLC told my committee last week that this would be resolved.))

Finally, there is the DRM and embedding/TiVo-ization language. If your project is heavily used by embedded or multimedia devices, your partners are likely to get very nervous if you start talking about v3. If you yourself take the libertarian or pragmatic developer-centric viewpoint, you may personally be opposed to those new restrictions as well. So those may well be reasons to avoid the license for many projects.

Q: I really want to hose Novell. Should I switch to v3?

A: If you’re looking for some sort of vengeance on Novell, you won’t get it in this license. More on that tomorrow, but nutshell: you’re not getting it. Even if you did, that is a pretty lousy reason to choose a license anyway. With any luck, the GPL (and your GPL’d code) will outlast the current Novell leadership and maybe even Novell. Make decisions based on what is right to protect you, your code, and your users, not on whether or not Novell deliberately circumvented the intent of the old license. (On that ground, hint: this will protect you from at least some Novell-like situations in the future, so if you think what Novell did was a bad idea, you might want to upgrade.)

Q: The kernel folks screamed a great deal about the earlier drafts. How far has the license gone to address their criticisms? Will that impact the uptake of the license?

A: The original drafts of the DRM and embedding license were not exactly models of clarity. As a result of criticisms from Linus and friends, the final draft is a lot more straightforward. The DRM clause now states merely that one can’t claim to be an effective DRM device, for example; previously it actually tried to prevent the construction of such devices. Similarly, the embedding clauses now make clear that what is required is sufficient information to reinstall the software (whatever form that information may take); previous versions had been murky enough that they had been read (incorrectly) to imply that things like developer’s GPG keys had to be revealed.

It isn’t clear that this new clarity will actually help uptake, though. It should reduce the opportunity for FUD, of which there was a fair amount around the first draft. So if people’s decision turns on these clauses, it’ll at least turn on the right issues and not false ones created by poor wording. But the clauses still burden and restrict developers without giving them any clear pragmatic benefits in return. If the pragmatic developer’s bottom line is ‘give us benefits and we’ll use your license’, the clarifications to those clauses will only clarify the situation- they will not substantially change it.

Q: So there are upsides and downsides- how do I pick? Unfortunately, there is no simple right or wrong answer for this. Every project will have to make their own judgment about the pragmatic costs and benefits, and the political-philosophical implications. Projects who particularly want to get solid patent licenses from their contributors or who are particularly philosophically concerned about user control will probably lean one way, and projects who are worried about the mobile space or whose copyright situations are particularly confused will probably lean another.

Q: That wasn’t helpful at all- I still can’t make up my mind. Should I consider dual licensing with GPL v2 or another free software license?

A: Dual licensing is a mixed bag. On the one hand, it gives more flexibility and choice to your users, and it will reduce uncertainty for your contributors and your users. On the other hand, it gives more flexibility and choice to your users- including the bad guys. In particular, your code is only as protected as the protections of the weakest license you license under. So if you release your code under both GPL v2 and GPL v3, you haven’t gained much- the next person who sells you out on patents or DRM will just say ‘well, I’m using it under v2.’ You can only gain the full protections of v3 if you license only under the v3, or under the v3 plus an even more restrictive (presumably proprietary) license.

The only major advantage to dual-licensing, then, is that other people can reuse your code under the license of their choice. This is not a small benefit- it will be particularly useful for GPL-licensed platform projects which expect to have programs developed on the platform in both GPL 2 and 3. But it isn’t necessarily huge either.

Q: What about ‘or later?’ should I use that? Doesn’t the controversy about this license mean I can’t trust the FSF to make good decisions about GPL v4?

A: The FSF recommends licensing your code under ‘v3 or any later version of the GPL’, just as they have with GPL v2. This cuts two ways. On the positive side, it means that if a problem is found in the license, and people are unable to contact you, they can still use your code under the new, less problematic license. This is arguably exactly what will happen with Novell and the patent clauses of v2 and v3- a problem was found, and those who left their code under ‘v2 or later’ and then dropped off the face of the planet can still have their code be useful for others.

On the negative side, it also means you have to trust the FSF. I do; if you actually take the time to read the four freedoms, it is clear that they’ve done nothing with this license that isn’t exactly in line with the goals they’ve been stating for 20 years. But if aggressively protecting those user freedoms aren’t your cup of tea- and they obviously aren’t everyone’s- you might not want to trust them with GPL 4, and so ‘or later’ might not be appropriate for your code. ((It may be worth noting that even if you dislike the FSF, they are only going to make the license more restrictive- you’re never going to get a more libertarian GPL 4 that says ‘go wild, have a party, do whatever you want to the code.’ That means that if GPL 4 states ‘everyone must pay obeisance to RMS before using the code’ and you’ve used ‘or later’, the worst case scenario is that those people take your code and play with it in their own, small corner. As long as you really believe that fewer restrictions will win out in the marketplace of ideas, you’ve got nothing to lose from ‘or later’- large numbers of hackers will only move to the new license if there are really compelling reasons, no matter what FSF does.))

Again, this is a fairly personal decision about risk, reward, and trust. I personally think the FSF is pretty predictable, so I’d license my work under an ‘or later’ clause, but I realize that this isn’t for everyone.

Q: If I do decide to relicense, what are the mechanics of that?

A: The FSF and SFLC will be issuing recommendations on relicensing best practices. My recommendation as of this writing is to wait for them- they are the experts, and have given these pragmatic details a great deal more thought than I have at this time.

Q: You mentioned projects whose copyright situations are particularly confused- what do you mean by that?

A: Take, for example, the kernel. We know much of it is licensed as v2-only, and we know many of their contributors have gone AWOL, or have even passed away. Only one project of that scale (that I know of) has ever tried to relicense (Mozilla) and the process took ages, even though most of the code had a single copyright owner (Mozilla/Netscape). The kernel could well be worse- no single copyright owner, and several times as much code. So talk of relicensing the kernel, especially in the near term, is probably largely academic; pragmatically dual-licensing of some chunks may be the best that can be expected.

The kernel is not alone- many large projects (like GNOME) don’t do copyright assignment, and so any attempt to relicense would involve a long time spent relicensing, and potentially even an effort to rewrite old code whose authors could not be contacted. This may well limit the impact of the license- v2 may remain the defacto license of older projects, with newer projects moving to v3. We’ll see.

Q: Bottom line for developers?

A: The advantages to the license are not huge, but they are real, and my guess is that within a few years it’ll be the default license for most new free software projects, as v2 is now. If you choose not to get on that train now, you’ll be in good company, but make sure you understand the license and are doing it for the right reasons- you’ll regret it if you make a kneejerk decision (either way.)

[Thanks to Nicu for the shiny new copyleft logo.]

[see all parts: part 1, part 2, part 3, part 4.]

when I graduate + quick note on the Next Big Questions

Mon, 25 Jun 2007 00:00:00 GMT

Matt, all of the following are probably true. I graduate:

(a) two years from last month.

(b) way too late, because so many interesting companies are doing so many interesting things right now.

(c) way too soon, because answering the Big Questions is probably going to need the kind of deep thinking that tends to be enabled by academia and/or monasteries, not the Real World.

The Big Questions I have in mind are hard to even express clearly right now, much less answer. I think of the family of Big Questions as all following the pattern “how do you find a GPL2-like sweet spot which in one swoop provides more rights for users, solves coordination problems for developers, and leaves room for economic incentive for companies.” If you can find that sweet spot (or something related; this is a gross oversimplification in some ways) you’ve done some really interesting thinking and solved a lot of problems for people.

GPL itself is a fairly good example of a legal document which creates this sweet spot around traditional client software. We need to create the same sweet spot around user data, to encourage users to give up their data to the googles of the world while giving them a high degree of confidence that their rights will be respected. And we need to create the same sweet spot around web services and APIs- Bungee may be doing very interesting things, but if their legal relationship to the folks they serve was standardized and gave incentives to every party in the transaction I’m certain even more interesting possibilities would open up. And of course I still quixotically insist that such a position must be possible in trademark :)

Because copyright is not involved, solutions for these problem spaces probably look more like contract than license, but they may include other aspects of the law as well. For example, the solution to the personal data problem may borrow from common-law property rules like bailment, or (in the worst case) from regulatory law like that which created the SEC. More generally, the complex legal redirection that is copyleft is probably fairly straightforward compared to some of what would be necessary to solve some of these. That is why I think tackling some of these are probably multi-year projects- more than I can cram into just the next two years, probably. Knowing myself, I will probably be making a stab at them anyway ;)

on the unexpected end(?) of my journey on the shoulders of a giant

Tue, 19 Jun 2007 00:00:00 GMT

[Nutshell for those with less free time than me: Lawrence Lessig is the closest thing I have to a personal hero, and he’s leaving the IP/culture game to play for bigger stakes, against even tougher opponents. In this post I explore and explain my very personal relationship to his work, wish him luck, and fervently hope that our intellectual paths cross again.]

At some point during my senior year of college, I read Larry Lessig’s Code and Other Laws of Cyberspace. It put into words something I’d felt but not been able to articulate: software mattered a great deal, not just for its own sake, but as the new architecture which constrained and helped define markets, politics, and speech- the dominant forces in most of our lives.

Code was very consciously in my mind when I chose to go into free software after graduation instead of what looked like sure money in hardware. ((Of course, that company bombed and Ximian succeeded beyond my wildest dreams, but I had no way of knowing that at the time.)) After Code, I felt even more strongly that in order to have transparency in markets and communication (and eventually in speech and politics) we needed transparency and vigorous competition in our software. And so I chose to follow that dream for a while. (So far, so good.)

Later, seeing Lessig speak for the first time at the Duke Conference on the Public Domain, and then reading his Free Culture, reaffirmed that choice. While Free Culture talked very little about free software, it was hard for me to read without thinking that that a free culture would not - probably could not - grow in a software monoculture, nor could it grow without learning from the methods and the madness we’d pioneered in free software. And so I kept at it, trying to keep in mind the idea that this wasn’t just about writing better software- it could be and probably should be about something much bigger. ((Not a coincidence I got started in mozilla, was passionate about GNOME, and am very excited about OLPC, Wikipedia, and Curriki- if we’re ghettoized on corporate servers, or just serving elitist software geeks, there isn’t much point to us being here. We must be on tens of millions of clients, and we must go beyond software, to really make a difference in the world.))

It wasn’t coincidence that after being steeped in ‘marxist-lessigism’ for years I ended up in law school. Just as Lessig made it clear that code impacted the real world, he also made it clear that the real world (and particularly politicians, governments, and lawyers) inevitably impacted code- and more importantly, inevitably impacted how people spoke with each other and sold things to each other using that code. It is my current career goal, in no small part because of Lessig, to be a lawyer who helps bridge those worlds, bringing the tools of the modern lawyer together with the tools of my friends to make the world a better, richer, more sharing, more human place. ((Like Lessig, I think vigorous capitalism is a valuable part of that richer, better place, so I certainly won’t object if I can manage to make a buck by upending entrenched businesses along the way.))

This isn’t to say I think Lessig is a saint, or that I always agree with him on matters of policy and tactics- see, for example, this post for some good criticisms. But it is no small sign that even those who disagree with him must often define themselves in his terms and on his grounds- it indicates that his choices to bring the discussion to the masses on largely morally neutral grounds achieved a broad and significant traction that hadn’t previously occurred. (Whether or not that is unambiguously good is another discussion for another day.) ((Also, I tend to think that even in matters where we disagree, the disagreement is a public formalism which he uses as a strategic and marketing tool, and that some day when he puts aside the mantle of public intellectual, and can become more honest about his motivations, he’ll be much closer to Mako and Stallman than they expect. Hopefully we’ll someday get to see that side of him- hard to know for sure.))

So to summarize- I’m usually in awe of Lessig. The last 6 years of my life have been many things, but whatever else they have been, in large part they were a ride on his shoulders.

Which brings us to today. I am even more in awe than usual, because he has announced he’ll no longer focus on IP, instead choosing to concentrate more on what he calls political ‘corruption’- corruption in the general sense that ‘the political system is broken, and has forgotten how to fix itself’, rather than the specific sense that ‘the political system is full of people who have been effectively bribed by lobbyists.’ (Though of course the one is part of the other.) The self-confidence (the self-sacrifice?) to leave a field where you are the acknowledged global leader, quasi-founder, and expert, and to start from scratch, is something I’m pretty sure I couldn’t do. ((It would be easier, I’m sure, if I had a full, tenured professorship at Stanford and an obsessive-compulsive global fanclub I wanted to escape from for a few years, but still… general point stands. :) )) And he’s doing it in a very high-profile way, into a field that the world pretty desperately needs right now, without (apparently) having much sense of what the answers are. I admit I’ve often in the past year thought ‘free software is small beans compared to Guantanamo, or global warming, or religious fundamentalism’, but I’ve stuck with free software in part because I feel certain I can make a difference here, and to try to solve those other problems means almost impossible odds. For him to leap into something where there is no certainty he can achieve anything, against fairly overwhelming odds and deeply entrenched interests… yeah, awe is a good word. Takes bravery (or perhaps craziness, or both) that I can only hope to find in myself some day.

In some sense, Lessig’s choice could be interpreted as a diminishment of what I and others have worked for alongside him and Stallman - a stark acknowledgment that if the background mechanisms of our national politics is broken, then the freedom of our software and our culture doesn’t make much of a difference. But my hope (perhaps my arrogance or my denial) is that this isn’t the case. Rather, I much prefer to think that social production, free culture ((like his push to open the debates)), and perhaps even free software ((voting software!)) are going to be central to retaking control of our government and our country from the sources of this corruption. So I’ll tell myself I’m helping out in Lessig’s larger and more important battle, even if the link is more tenuous than I’d like right now. Hopefully I’m right; possibly I’m wrong- either way, that rationale will help keep me motivated while Lessig is off finding and promoting his own solutions, whatever they may be.

More personally, good luck, Larry. You’ll need it, but we’ll be cheering for you, and we’ll all benefit, both in IP/culture and elsewhere, if somehow you can pull off even a fraction of your impossible dream. (And if anyone can do it, I think I speak for many others when I say that I have a deep faith that you can.)

'it is just a number, and numbers aren't protectable' drivel

Sun, 10 Jun 2007 00:00:00 GMT

(A belated rant on a certain number, and responses thereto.)

From Ed Felten’s comments:

And it proves again that the lawyers fail to see something very important… . _everything_ in the internet _is_ equivalent to a number. In the mathematical sense. You can transform it as often as you want, it is still equivalent to a number. And numbers are ethereal, they always existed, and will always exist. You cannot destroy them, and you cannot — brace yourselves, IP advocates — invent them. Therefore you cannot protect them either.

From LWN’s comments:

A number is a number. A number is not a product. (Well, maybe this one is, because it’s not prime, but never mind that.) A number is not a service. A number is not a device. A number is not a component. A number is not part of a component.

This is pure drivel, people. Yes, I can represent any idea - any information- in a number. So what? Numbers are not magical and mystical; there is no part of the constitution that says ‘numbers cannot be protected by intellectual property law.’ What matters - what can be protected- is the meaning which humans are able to imbue in and draw from those numbers. We humans have imbued that particular number with a meaning, and as a result, we’ve decided to protect it.

Or to put it another way- locksmiths use numeric codes to replicate keys. Access to those code books is restricted. If someone gave the numeric code for your front door key, along with your address, to a criminal, would you say ‘well, it is just a number, I guess I shouldn’t try to do anything about it’? No, you’d do just what you’d do if the criminal had been given a physical key- you’d change the locks. Again, it is the idea that the number represents- the key- which is what is important, not the number. And so we can protect it or restrict it as we please- to do otherwise would be insane.

Now, I’m pretty sure that giving this particular number legal protection is a bad idea. But that has nothing to do with whether or not it is a number. Anyone who thinks otherwise… oy. Repeat to yourself: all data is a number and all physical keys are numbers, and that doesn’t stop us from patenting, copyright, and otherwise protecting keys and data. HD-DVD keys are no different- it may not be good policy, but it is very clearly the policy we’ve got, regardless of whether or not something is ‘just a number.’

On textualism, purposiveness, and maintainability

Sun, 10 Jun 2007 00:00:00 GMT

[Written in large part nearly a year ago, but holds up well on review, so publishing it while waiting for the late-night, extra-innings, baseball game to wrap up.]

Some ponderings on what the legal scholars call textualism and purposiveness, roughly what the rest of us tend to call strict and loose constructionism. These thoughts were inspired by my class in Legal Methods, which explores, among other things, how to interpret laws. Since I’m not likely to directly return to the issue until next semester, I wanted to force myself to write this down now and think them through. It is worth noting that these are likely the least original things I’ve ever written, given how hashed over this subject has been, but they are all new to me :)

The reason why this ends up cast as a conservative v. liberal thing, typically, is (per Posner) “[liberals] think that modern legislation does not go far enough, [conservatives] think that it goes too far. Each school has developed interpretive techniques [i.e., strict and loose construction] appropriate to its political ends.” Loose construction, then, is about creating new law to fill in gaps, and in most recent political history in this country, new law has meant liberal law. If the recent conservative ascendancy continues, though, and the hypocrisy of the conservative ascendancy continues, we’ll almost certainly see conservative loose construction, and liberal strict construction. It should be interesting to see how that develops, and whether or not we see more consistency or more hypocrisy as a result.

There are a number of reasons the problem comes up:

Some of the issues that call for loose construction are caused by Congress just plain screwing up- using language that is badly and unnecessarily imprecise. If Congress says ‘legal fees’, and then explicitly and repeatedly says in the record ‘when we say legal fees, we mean legal fees and witness fees’, then surely you would think (1) Congress could have just said in the law ‘legal fees and witness fees’ and (2) a sane court would say ‘OK, they meant legal fees and witness fees’. But I didn’t make this example up. Congress didn’t add the three words, and the Court did completely ignore what the Congress said it meant, eviscerating the clear intent of the authors of the law. That said, they’ll likely be more careful next time- so maybe it isn’t a bad thing. (See more on that below.)
Some of the problem stems from the nature of the Congressional process- the record is inevitably incomplete, and potentially dishonest, so there are times when what Congress says publicly it wants to do, and what it agrees to write to get votes, are different. This is a legitimate problem, I believe- closed-room discussions are substantially and meaningfully less democratic than the discussion of a full body of Congress. (This is not to defend the poor state of deliberation in Congress, but merely to point out that it is even worse in commitee.) So should the courts pay attention to that? They often do.
A third cause, and the most difficult one for the strict constructionists, is the ENGLISH99 problem- language is not standardized and not standardizable. The textualist argument explicitly presumes that there is a standardized English, which is clearly not sane.
A fourth cause, of course, is Congressional incapacity- they just can’t anticipate all the corner cases that a law can cover. This is a deep problem for both camps to grapple with. If even in the very, very best case Congress can’t write perfect laws, how do you deal with this?

An open question for me: is the spirit maintainable? Can a system built on some mix of incompetence and fallibility (on the part of Congress) and baling wire (on the part of the Court) hold together? My current sense is that it is not holding together very well. Loose construction almost definitely produces more just short-term results, but it also clearly encourages sloppy lawmaking (at best) and undemocratic behavior (at worst) by Congress.

Given those problems, where is the balance? Is making the system more sustainable, reasonable, predictable, etc., at the cost of relatively temporary, small injustices, worth it? What if the injustices are bigger? longer-term? I am really not sure how to reasonably assess the problem, though it is clear that the current method of figuring out the problem isn’t working either- instead of a meaningful political discussion (like the one that has apparently led the EU to declare that all law should be interpreted purposively), it gets handed off to the Supreme Court justices to bicker about, with the occasional new nominee thrown in. This seems like nearly a worst-case scenario, unfortunately.

[Tangentially, I have a hunch that much of the significance of this problem is that the ur-text- the Constitution, particularly the Bill of Rights- is what provides much of the animating ‘spirit’ of American national law, and it is in many ways antiquated. If, for example, it contained a clear, simple privacy right, there would be much less need to engage in purposive interpretation when it came to Constitutional issues. We’d still have this tension when it came down to interpreting regular legislation, but inevitably legislative mistakes by the Court are less significant and easier to fix than Constitutional ones.]

open source advice: 3 + 3

Fri, 08 Jun 2007 00:00:00 GMT

I’ve never before actually answered a blog meme (unless you count this.) But sogrady tagged me with one that I thought was interesting. Here goes: three things I would tell every open source business to do; three things I would tell them not to do. (In an attempted to do more than just repeat what others have said, these may be a little more abstract and a little less useful, but I hope they are fun.)

To Do:

do emphasize volunteer QA: one serious, concrete piece of advice, first. Most of your users want to help you make your software better, and QA is a pretty low-barrier way to let them do that. So take advantage- invest in public bug tracking systems; invest in people whose job it is to help volunteers use those systems; invest in ways to get regular builds to volunteers so that they can test and verify on the latest and greatest. User-driven QA is very, very difficult for proprietary software to do, and should be a great differentiator (both in quality and in cost) for open source.
do something revolutionary: software is more fun and more dangerous (to the other guy) when it is really revolutionary. Not merely innovative- ‘we want to do something new’ but revolutionary - ‘we want to actively overthrow the old.’ We are here because we revolutionized the method of software production, but to continue to grow, we have to start revolutionizing other things too. Be the Wii, not the PS3. If you really want to catch them by surprise, be a revolutionary using open source, but not in software. The people outside software (well, except for poor Encyclopedia Britannica) don’t yet realize what is coming for them.
do it with joy: if you’re in open source, you’ve given away most of the weapons past software companies used to build a lead and then coast - you can’t get lockin and you can’t get a monopoly. So unless you get bought out and retire, you’re going to be on this treadmill for a long time- someone will always be at your heels. So have fun, or the treadmill will burn you out very fast.

To Not Do:

don’t be afraid to embrace freedom: open source businesses tend to be allergic to the word ‘free’. That is a mistake. Say ‘freedom’ a lot. Love freedom. Embrace freedom. Your community likes freedom. It differentiates you from the proprietary competition, and if you embrace it wholeheartedly (not just this weak ‘openness’ stuff) it will differentiate you from most of your open source competition too.
don’t let your community’s fears drive your feature choices: if you’re a real open source company, you’ll have very direct contact with your customers. This is normally a great thing, but when you make a decision they don’t like, particularly if it scares them, you’ll hear about it loud and long and clear. If you let that negative feedback drive your decision making, you’ll never grow beyond the needs of those people. You must not be afraid to piss them off when you truly believe that a design decision is for the broader good. Remember, the pissed off people scream- the happy people just go on with their lives. So you can’t just say ‘more people screamed than thanked us’- that isn’t a useful metric.
don’t stick around if this isn’t for you: This is just not for all of us. Open source is people, in all their messy glory, interacting primarily as partners and friends rather than as hierarchical worker bees. Some people take to this like a fish to water; I dare say that most people should. But not everyone will. If you don’t - if you think this should just be about a copyright license - get out now, and spare both yourself and others the irritation of dealing with you in a situation you’re just not suited for.

Can’t think of anyone I want to tag right now; maybe in the morning.

thankfully the number of people who will understand this post is small

Mon, 04 Jun 2007 00:00:00 GMT

your personal mission statement could be like “oGALAXYo of the legal world”

westlaw doesn't get it- search with gradients, but without relevance

Sun, 03 Jun 2007 00:00:00 GMT

Sigh. So, kudos to westlaw for coming up with a new beta front page. Very clean, very google-like. (If you can’t see it, trust me.) Sadly, westlaw seems to think that the appeal of google is the clean look, rather than the good results.

If you search for ‘ebay v. mercexchange’ on google, you get the Supreme Court’s ruling on the case as the first hit, wikipedia, a blog post, and then the Federal Circuit’s (lower court) ruling on the case. This is pretty reasonable. Every hit on the page is relevant. They also got the ruling as the first hit within weeks of the ruling, which goes beyond reasonable and into ‘fairly impressive.’

When I searched for ‘ebay v. mercexchange’ on the new westlaw beta search a couple weeks after the ruling, I got… well, nothing referring to the Supreme Court. A bunch of commentary on the Federal Circuit’s decision. Some stuff on Indiana cities suing each other, and wills/estates. (WTF?) When I clicked around for a long time, I eventually found both decisions that Google finds immediately. Now, I get to commentary directly (better), but still no direct link to the case (still bad).

Now, I’m obviously not an expert, but I’m guessing someone searching for ‘ebay v. mercexchange’ is searching, 9 times out of 10, for the case itself. In fact, a teacher of legal research will tell you that you should never rely solely on commentaries- you should always read the case, as well as the commentaries, even if your intent is to first read the commentaries. So the should be result #1 (like it is in Google), followed by relevant background information and references (like Google.) That Westlaw still doesn’t get this is mind-boggling.

What makes Westlaw particularly maddening is that they should be able to measure relevance in much greater detail than Google can. Both Google and Westlaw have access to a rich database of documents which link to each other in a measurable, meaningful way. Westlaw has more- they can measure precisely how long people spend looking at documents, and know which results they click, in which order, when they run a search. And legal documents have a strict heirarchy which can be used to infer value when links are weak. And despite that, Westlaw still fails. (Lexis is no better.)

But hey, now the first search page you go to at westlaw has gradients. That counts for something, right?

they keep talking about building bridges, but forget that toll booths are optional

Thu, 31 May 2007 00:00:00 GMT

“The only way that[ customer-benefiting interoperability is] possible is for companies to really be open to licensing arrangements and building these bridges that people thought were impossible before, among different providers and among different software development models.” —Horacio Gutierrez, Microsoft’s vice president of intellectual property and licensing

Or, you know, you could agree not to assert the IP against your customers, open source, or standards-based projects, and actually benefit your customers like you claim to want to. Wouldn’t that be a wild idea. I think everyone is in favor of bridges, but some of us don’t assume that all bridges have toll booths.

(And I’m still waiting for someone in the mainstream tech media to challenge MS’s assumption here instead of just letting them get away with it. But I probably shouldn’t hold my breath.)

social producers are going to get lawyers whether we like them or not

Wed, 30 May 2007 00:00:00 GMT

One of the comments to Matt Asay’s post about me over the winter asked what I think was a pretty good question, and one that has been asked in a couple variations this summer:

…I am usually saddened to see that law becomes a necessarily evil in science (programming in this case). Why can’t we just be?

For better or for worse, social producers (not just software, but wikipedia, etc.) are becoming so successful that we often have to interface with the real world. We’ve got two options. First, we can either stay small and under the radar, allowing us to keep operating on a handshake basis. This will work for some products and some producers, but I think many of us want to have a broader impact than that. For those of us who do think that social production is going to have a serious and broad impact on the world, we can use the tools the rest of the world has developed to relate to that real world- laws and legal experts, aka lawyers. I’m pretty sure there is no third option to ‘be big but somehow still avoid lawyers.’ (Feel free to convince me otherwise; I’ll save at least $90K in school bills if you do. :) At best, we might be able to avoid some of the regulation which has affected every other pervasive industry, but even without regulation by government, when you’re big you have to relate to other private parties- corporations, less trusting individuals, etc. The bigger you get, the more those relationships are mediated by lawyers, in order to make sure that all sides can eventually trust each other once the lawyers are gone. The need to defend and define our success, in part by using the law and legal experts, is a virtually inevitable byproduct of our success- the rest of the world is not just going to let us be if we have the impact we hope we can have.

The types of issues lawyers can and will help social production navigate aren’t just going to be defensive issues, thankfully. If more of our relationships are going to lean away from the purely economic/industrial and begin to include more aspects of the social/cooperative, we’re going to need creative new ways to structure and define those relationships. The GPL is the canonical example of this, of course, but there are other examples too, like the Red Hat sales model. We got lucky in many senses with GPL- while originally intended for a cathedral-like model of production, it happened to provide the reciprocity which turned out to be critical for success in the bazaar. We aren’t likely to be so lucky again- we may never again have the time to allow such relationships to grow slowly and organically. Red Hat’s current sales model couldn’t evolve; it had to be sculpted with the aid of lawyers from day one. Again, then, if we want to have such relationships, we’re going to need to choose the ways we structure them more deliberately and proactively- and lawyers will likely be involved, whether we feel comfortable with that or not.

This isn’t necessarily to say that social producers should give up and let the lawyers have their way with us; they should be viewed with some suspicion, and we should demand that the same principles which tend to govern social production now - values like openness, transparency, simplicity, robustness - should continue to govern social production in the future, even after the lawyers get involved. (Mike Dillon, Sun GC, has a great blog post on the clarity/simplicity thing; and another on aligning provision of services with the needs of customers instead of the needs of providers; great social production lawyers will take both of those to heart and great social producers will demand it of their lawyers.) But denying that law (and with it the lawyers) is coming doesn’t serve anyone well.

So… perhaps unfortunately, our own needs and the needs of the outside world are going to push social producers into the arms of lawyers, whether we like it or not. Fortunately, more lawyers are going to get it as social production becomes more pervasive; the team here at Red Hat certainly seems to, and hopefully I’ll add myself to the pool of such lawyers in another couple years.

pathetic commentary on computers, from my new cable box

Sat, 21 Apr 2007 00:00:00 GMT

This is what the world has come to expect from computers:

“Keep in mind that your DVR will act like the computer it really is, and as such, may reboot occassionally or the screen may momentarily freeze.”

— from the ‘quick tips’ for my new cable box

No wonder everyone wants to move to web apps.

blogging codes of conduct

Tue, 10 Apr 2007 00:00:00 GMT

A couple quick final thoughts before I pass out for the night: I haven’t read O’Reilly’s proposed blogger code of conduct yet; some commentary I have seen on it suggests I’ll be irritated at it as an involuntary speech restriction, and one comment makes the useful (and almost certainly correct) point that when you start censoring comments, you increase your liability for what the remaining comments say.

That said, I’ll almost certainly add an express mini-code to my own site after exams, reflecting what I’ve already been doing in comments. Basically: (1) a no asshole rule, since people should be told early and often that being an asshole is always unacceptable, and (2) a recognition that I’m accountable for what is on my site, and I will act accordingly, since trash in my comments reflects poorly on me.

I dislike overreactions that succumb to the framing of the internet as this horrible place filled with evil lurking around every corner, but I do believe in the power of social norms, and I do believe that no one should be subjected to what Kathy went through. So I’ll do my part to make sure my little corner of the web is clean, even though I think others should make that choice for themselves.

[Photo courtesy pamelaadam under CC-BY. See also what is almost certainly the only photo on flickr tagged with ‘enforced by aardvarks’.]

[Later: or just ignore me and ignore everything else and read John Scalzi. He has a long post, but the money quote is “What the blog world needs is not a universal “Code of Conduct”; what it needs is for people to remind themselves that deleting comments from obnoxious dickheads is a good thing.” Right on.]

Israeli Supreme Court on Torture

Tue, 03 Apr 2007 00:00:00 GMT

We are aware that this decision [banning torture] does not ease dealing with that reality [of terrorist attacks on Israelis.] This is the destiny of democracy, as not all means are acceptable to it, and not all practices employed by its enemies are open before it. Although a democracy must often fight with one hand tied behind its back, it nonetheless has the upper hand. Preserving the Rule of Law and recognition of an individual’s liberty constitutes an important component in its understanding of security. At the end of the day, they [add to] its strength…

From Public Committee Against Torture v. State of Israel, 1999. Read it tonight in criminal law, as part of a section on the defense of necessity. Sigh. All too timely. :/

minor but semi-triumphant thought on gpl v3

Wed, 28 Mar 2007 00:00:00 GMT

More thoughts on gpl v3 later, but a quick thought from skimming through some of the online comments:

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. — the second sentence of the license, emphasis mine

I don’t understand the word “most” on the preamble. Is it really true that most software has non-free licenses? When the preamble was originally written this made sense, for sure, but now it sounds unnecessarily pessimist. — a comment

I’m not quite as optimistic as the commenter (a majority is probably still proprietary), but man… the GPL has come a long way that he can say something like that and not be completely out of his mind.

Replacing ‘most’ with ‘many’, or even just ‘proprietary’, would be a wonderfully appropriate way to capture and celebrate the change that GPL v2 has wrought over the past 16 years.

advice for future law students

Sat, 24 Mar 2007 00:00:00 GMT

If you enjoy musicals, and are planning on going to law school, do yourself a favor and don’t watch Chicago the same week you cover murder, wife-beating, and murder defenses in Criminal Law. Nothing like correcting lyrics in your head to spoil your enjoyment of a good musical.

For example, “It was a murder But not a crime!” is a great lyric, but not correct, since murder is by definition unlawful. “It was a killing But not a crime!” would be more correct. (But of course it probably doesn’t have the same ring to it.)

Yes, law school has made me even more of a pedantic bastard. My apologies. My only excuse is that it apparently does this to everyone- you’ll be incapable of taking Crim Law and watching Chicago without having the exact same thought. Therefore, my advice, learned the hard way last night. ;)

Notes from Prof. Eben Moglen's talk on "The Empire & the iPhone: ‘Technology Platforms,’ the Commons, and the Way We Live Now"

Mon, 19 Mar 2007 00:00:00 GMT

Tonight I attended a talk by Eben Moglen titled “The Empire & the iPhone: ‘Technology Platforms,’ the Commons, and the Way We Live Now”, put on by the Information Law Institute Students Assocation at NYULS. They are hosting a Stallman talk on Wednesday; it is Krissa’s birthday so I won’t be attending that one.

The talk was a full hour, plus 30 minutes of Q&A. Necessarily, then, these notes are fragmentary (‘written’ on an N800). It is probably best to read them as jotted (and heavily paraphrased!) notes and highlights rather than expecting a coherent narrative. Don’t rely on these for reporting Eben’s thoughts- if you see something of interest here that you plan on quoting in a Serious Format, contact me, or better yet him, to confirm that it is acccurate.

I wish I had deep thoughts to add, but I’m pretty beat up tonight. Possibly more tomorrow. Nutshell version: I think Eben is obviously correct that platforms are loci of control, and hence are very dangerous for anyone concerned with rights in a digital context. (Not just software freedom, but freedom of speech, freedom from government eavesdropping, etc.) At the same time platforms (and the standardization they can create) can facilitate innovation at other levels in the stack, and efficiencies all over. Figuring out how to strike that balance may be as easy as just having good rules about platform licensing, but I have a gut feeling it will be more complex and difficult than that. At any rate, like I said, probably more of my own thoughts tomorrow.

The Talk

He wants to focus on non-license stuff, and instead focus on where we live now- the broader view of the environment rather than the specifics of one license. (ed.: of course the first question in q&a was about ms-novell. :)

The commons is here and not going away; production in 21st cent. will be community based, and traditional sellers are now realizing this, and reacting defensively or otherwise.

Rise of prosumer is critical; digital camera is the beginning of this but only the beginning; will impact much more than photography- stage shows, etc.

We now know that ownership of knowledge blocks, and/or makes inefficient, knowledge production. [ed.: he asserted in Q&A that we should issue patents under a formal adminstrative cost-benefit analysis scheme, but I’m not sure how one can even pretened to do that, given the sparseness of the economic research on the topic.]

Other than MS every single significant software vendor uses- depends on- output of commons. Not just culture and software but banking and money are now contested; paypal distributes banking. Ebay decentralizes vending.

Commons are now central both for the most and least powerful.

Many mechanisms for commons to protect itself; copyleft but also stubborn 12year olds and p2p. Needs all of them.

IBM and HP are doing well in large part b/c of harnessing commons.

Talked regularly to Bill Hilf, MS. Calculated that MS can bring 3.8 million manhours/week to the table; from sf.net + surveys done by rishab ghosh he gets (in 2004 ) 5 million manhours/week spent producing GPL software; now probably closer to 6m overall. So commons is the majority in some parts of software, even if not yet in other places in ip.

Despite the reality of production, commons is not the dominant theory of production. Proprietary mental models still dominant, which is why we still pay for phone calls. Skype is not perfect, but is still early and very threatening to a broad range of interests, and having an impact.

Question, then: owners will have their innings to respond; what will the response look like?

Says their answer will be the platform, which is (among other things) a safe box within which commons can be safely controlled/walled off.

The cell phone network is an example. It gives people impression that movement matters (“roaming”); that expensive hardware is necessary; that you must carry the state with you in the form of e911; that you must eventually give vast amounts of info to marketers.

Commons has better answers for all this (wifi, skype, etc.), but like MS, the cell people tie you to a platform and scare you w/ isolation if you leave the comfort and security of the platform.

The story Jobs spins is ‘There would be no music w/out the platform- people will stop singing w/out the platform.’ This is obviously ludicrous but we’ve bought into it. Despite his recent letter, Jobs is not really anti-drm; just doesn’t want to lose the platform.

“Who will make software if you sell it below cost?” is what the economists used to ask; now sony and xbox do this for hardware, and the economists justify it as a blade/handle model, which he finds economically implausible, unless we give them alternate forms of control so they can force the blades on us- this, again, is the ‘platform’.Says that Tivo’s GC finally checked in on gpl3; Moglen apologized for RMS’s use of “tivoization” as a phrase, but tivo still wanted the keysigning clause removed. Says Tivo even offerred removal of drm from the stored video, just as long as they could keep the subscription lockin by signing the software. If they gave away subs via hacking, they lose out. They want free software to compromise so that they can commit the “economic stupidity” of too-cheap hw.

Sees the near future as the process of maneuvering the commons through the obstacle course of platforms which benefit incumbents.

Notes that government is fertile grounds for creation of platform by fiat/incumbents.

Notes that not all platforms are the same; some more or less bad than others.

Job/wealth creation from the comon is not inherently bad, but it can create pathologies as people attempt to game or exploit the commons. He says we will need a language to describe this; we’ll probably get it from ecologists. [ed.: he didn’t mention Boyle, but clearly he is influenced by Boyle’s paper.] Says that the commons is not as bad off as the environment, b/c the commons was created intentionally and with a clear, self-conscious, long-term politics, whereas we exploited the environment for ages without clear understanding of what we were doing.

Biopatent protests are similarly politically motivated- goal is to demonstrate power/value of commons, and the damage caused by parcelization. The success of the movement is not predetermined; it requires determined, aware effort. “Can’t leave war to the generals or platform decisions to the platform makers.”

Governments now understand that commons is a reality, and has significant momentum, but we can’t be complacent. We are becoming more diverse, which makes political action hard, esp. since some of our allies are only allies of convenience.

From each according to ability is actually a possibility now in our domain; others before us did not really have the option, but we do and we should take it. This time we win.

Questions (really mostly just the answers):

By political he means civil/civilized- over coffee, in courtrooms, etc.- not in the street, nor by pushing for specific political candidates, since the fcc and doj are more important than top-level politicians, and appointments are also unpredictable. (Notes that both Gore and Bush made pilgrimage to Redmond in 2000, whereas he can’t imagine Teddy Roosevelt making a pilgrimage to Standard Oil.)
Thinks winning in open standards is long term- after 8-10 years most standards bodies are going to look like w3c, and have patent policies in place to enable them to escape from patent gaming.
Says the SFLC brief in Microsoft v. AT&T is identical to Eli Lilly’s brief; pharma is trying to throw software out of the patent tent before software takes down the whole thing.
Cites Rawls to justify the superior morality/justice of a sharing culture, with reference to the moral problem of keeping knowledge from the poor. (ed.: my political philosophy work pays off!)

spillover, arts patronage, and Linux

Thu, 22 Feb 2007 00:00:00 GMT

[Old post that I meant to elaborate on, but never did; seems worth pushing out now; maybe I’ll write more about it later if anyone finds it interesting :)

On the day before Christmas, I read a paper on ‘spillover’ by Brett Frischman and Mark Lemley. In a nutshell, the paper is an attempt to think about the value created when new intellectual property is created, but which for various reasons isn’t, can’t be, and/or perhaps shouldn’t be captured by making IP more like ‘real’ property. They call this additional value ‘spillover’- in copyright, an example would be the period after the expiration of the copyright grant or fair use, both of which represent value which (for various reasons) we don’t allocate exclusively to the original copyright owner. [Image of an arguably fair use; search for Koons in the linked article.]

On Christmas itself, Krissa gave me Marks of Opulence, a book about the ties between economic trends and art production. I’ve been plowing through it at high speed, because I’m interested in the links between the financing of art and the financing of free software- both of which are goods which aren’t as predictably monetizable as other similar goods (commercial buildings, for example, or proprietary software.) The book is rife with examples of ‘spillover’- first and foremost the centuries of art created primarily to further the ends of religion, which had unintended secondary beneficial aesthetic effects spilling over hundreds of years, which were not necessarily captured completely by the churches or their sponsors.

I don’t have any stunning revelations from these two pieces yet. But I think there are likely some good nuggets to be had. Spillover is where most of the value in free software is, obviously; we’ve put various labels on it- services, consulting, etc., but I like having one term- ‘spillover’- which covers all of it. Similarly, I’m pleased that there is a very long and distinguished history of great works created whose value was always primarily spillover- there was always, of course, a strong desire to own most of the great works, but other non-proprietary, non-commercial, and often irrational motivations have always played a part in sponsoring these works.

Canonical: putting money where mouth is, credit where credit is due, all that.

Thu, 15 Feb 2007 00:00:00 GMT

I intended to blog about this when I saw the FFII news last week, but school got in the way. Anyway, Mark having expanded on it a bit gives me another chance. I’m pleased that Ubuntu/Canonical are getting more active on the patent front, announcing that they’ll actively support Nouveau, and helping create a Free Ubuntu. These are good steps, and I’m glad Ubuntu is taking them. In particular, the idea of directly funding European lobbying on the patent issue is a good one (as distasteful as lobbying is), and I think it would be a great way for other participants in the game to make it clear that they’re on the right page. Similarly, the decision to put off proprietary drivers for six months, while not as permanent/strong as I would hope, gives Nouveau and other such driver projects some more breathing room, and puts a slight bit of additional pressure on Nvidia and ATI to think about following Intel’s lead and free all their drivers.

I’m still uncomfortable with a lot of what Canonical/Ubuntu does in this space (apparent sense that gratis is more important than libre, bragging when moving people from libre tools to gratis ones, lack of formal patent policy a la Fedora) but we should all give them huge thanks and due credit for taking this particular important step in the right direction.

another dream job I'm just a little too late for ;)

Mon, 12 Feb 2007 00:00:00 GMT

One of the things that makes me think I did the right thing going to law school is that every so often incredible jobs in very cool law offices open up. I’ve snagged an internship in one of those places, of course, but there are others. The latest such dream opening is at Creative Commons, where their general counsel, Mia Garlick, is apparently moving on to greener fields. (No idea what those are or could be… :) From the one conversation we’ve had (right before this picture was taken) and some lurking of mine on the cc-license mailing list, Mia seems like a very sharp cookie- I wish her luck wherever she goes next. I hear that there were over 100 applications for EFF’s last legal opening, and I’m sure this one will be similarly contested. Good luck to whoever gets it next…

[update: Lessig says Mia has been swallowed by Google.]

open source thought leaders (aka 'if you were stranded on a desert island, and could only have 5 rss feeds...)

Thu, 01 Feb 2007 00:00:00 GMT

Lauren Cooney, one of IBM’s open source folks, asks who the top five open source thought leaders are. Interesting question- here is my answer. Of course, I can’t limit it to just five. Oops. :)

Not all of these folks are bloggers; many choose more traditional routes to express their ideas, which is great/fine, just means you’ll have to put in more work to get their ideas. :) Feel free to tack on your own suggestions in comments- I’m out of the loop, so I’m sure I’ve missed people.

Note that my focus here is mostly not on who the top thinkers are, but rather the top thought leaders- i.e., influence counts for more than correctness. Thankfully, we’re mostly a sane bunch and so the people who get listened to are usually right :)

five who don’t say much, but who are listened to raptly when they do say things:

linus, mitchell baker, bdale garbee: lead the most successful open source projects, have a big impact in corporations, demonstrate good judgment and good taste, and voila- you’re huge. All spend more time doing than talking. (Also in this category, though probably a step below in terms of broad impact: Larry Wall, Nat/Miguel, Brian Behlendorf.)
eben moglen and richard stallman: love them or hate them, when they weigh in on a debate it usually has a huge impact.

six who say a lot and are listened to very broadly. Hard list to write, since ‘open source’ is so broad and fragmented- I tried to exclude folks whose impact is felt only in one community.

tim o’reilly: duh. :)
simon phipps and tim bray: big thinkers at an industry heavyweight. Don’t always agree with Simon (particularly think he tends to ignore Sun’s miscues while vigorously attacking the same mistakes when made by others) but he’s a very sharp thinker on open source issues most haven’t even thought about yet (governance, dealing with patents instead of wishing them away), and always worth listening to.
mark pilgrim: a blog I read said yesterday ‘if you are arguing with Mark Pilgrim, you are probably wrong.’ Sadly does not blog as much as he used to. (dhh may be the new Mark, though I disagree with dhh more often than I disagree with Mark.)
matt asay: he’s got his finger deeply on the pulse of what is going on in the open source business space, and is widely listened to there.
mark shuttleworth: only CEO of an open source company on my list- speaks often about open source and has a very big platform to say it from. Szulik or Tiemann could easily join mark here, but both seem to favor talking softly and carrying a big stick so I think of them as less ‘thought leaders’ and more ‘leaders by example.’

five conscious thinkers who should be listened to more:

redmonk, particularly stephen o’grady- smart people who are living and breathing transparent production principles, and as a result are quite influential and should be getting more so. (stephen gets called out because he is their open source guy; they are all sharp.)
karim lakhani: best academic thinker on the organizational mechanics of open source/peer production, bar none.
ethan zuckerman: lots of great thinking on how software (including open source) affects the non-first world.
tech liberation front: politics are in software and in software to stay, so politics is important. Whether or not you agree with their politics (very libertarian, just like many programmers) these are (IMHO) the sharpest collection of thinkers out there on the subject.
stormy peters: I always find stormy’s thinking on the industry to be very clear and very sharp. She should be higher-profile than she is.

four who are not strictly open source software people, but are software people and widely read and respected in the open source community:

joel spolsky: I think he comes across as a prick, but he’s a very, very smart prick, and even when I disagree with him (which is often) I learn something.
jon udell: now an MS employee; long a wise observer of industry trends. Likes to get his hands dirty in new tech trends.
kathy sierra: if you care about your users, no matter what field you are in, YOU MUST READ KATHY RELIGIOUSLY. YOU ARE FAILING TO DO YOUR JOB IF YOU DO NOT. Ahem. Possibly the only person (other than Lessig and Moglen) who I’d go out of my way to see speak at a conference.
paul graham: hacker, vc, great writer.

four who aren’t strictly software people, but are listened to anyway:

jimbo wales: the software/content lines are blurring, and jimbo is out there on the front lines of peer produced content.
lawrence lessig and yochai benkler: lawyers, and great, influential thinkers. If you are serious about thinking about open source, you’ve read Code; if you are very serious, you’ve started Wealth of Networks; if you are very, very serious, you’ve finished Wealth of Networks. :) (I’ve started.)
bruce schneier: rigorous thinking and great writing on a topic which should be near and dear to every programmer’s heart (security) means that when he speaks on software, he is listened to almost reverently. Fondness for transparency a big plus in the open source community.

six open source/tech law sources (most people won’t care about this list, but hey… this is my list :)

aforementioned: moglen, lessig, benkler
mark webbink, mike dillon: GCs at serious open source powers. Between the two of them may well determine the long-term fate of GPL v3, because their respective engineers write so much code.
wendy seltzer: Promotes MythTV. While teaching at law school. What more could you want. :)
legal staff at EFF: sadly, none of their lawyers blogs (that I know of) but collectively are on the front lines of, and set the agenda for, tech law development. [Ed.: a commenter points out that Jason Schultz blogs. Awesome.]
pam jones, groklaw: more open source developers get their legal news and opinions from pam than any other source, so she is influential no matter what you think of her.
andy updegrove: andy is The Man for open standards, which means he is The Man in the next big thing for open source.

six who would hate to be called thought leaders but are damn smart and doing very interesting things and should be famous:

chris blizzard: OLPC might be the most influential thing open source ever does; Chris is square in the middle of that.
havoc pennington: ran away from the well-earned spotlight to work on mugshot, which if successful could put tens of millions in regular touch with open source and put the spotlight back on him whether he likes it or not.
jeff and pia waugh: wish they lived in this hemisphere so I could see them in person more often.
aaron swartz: very smart. Now apparently fairly wealthy. Renaissance man. Younger than you.
david weinberger: co-author of the cluetrain manifesto; thinker on the internet and interwingliness; claims not to know a thing about software and hence might know more about software than the rest of this list put together.

[FWIW, Lauren’s list was sort of java-centric, so I’ve never heard of many of the people on her list; I think several of them I have heard of would not consider themselves ‘open source’ people. But I’m sure they are interesting. My one serious quibble with her list is Marc Fleury- I don’t know anyone who likes or respects Marc Fleury. Hard to be a thought leader when huge sections of the industry have flipped the bozo bit on you. Despite that quibble, I’m very glad Lauren did it and made me write all this down!]

totally forgot- gigantic thanks (and two links on post-law school hiring)

Mon, 29 Jan 2007 00:00:00 GMT

When I posted about my summer internship, I forgot to call out the one person most responsible for it happening- Chris Blizzard. Chris started talking RH up at GUADEC, saying ‘I have no idea if we have internships for lawyers, but if we do, you should come work for us.’ And he kept pushing it, and I kept listening, and he kept poking around inside RH. Many moons and some emails later, it turned out that RH did have legal internships, and voila- now I’ve got one. (In case you can’t tell, I’m still totally psyched. :) So thanks to everyone who congratulated me, but particularly thanks to Chris for really being the catalyst that made this happen. You rock, dude, even if you are Typhoid Mary.

Relatedly, Sun’s General Counsel has had a very interesting blog for several months, and he wrote yesterday about their legal internship program. He’s got brief but interesting things to say about how what he sees happening in the legal job market, in terms of experience, skills, etc. Worth the minute or two of your time if you’re interested in the career side of law. Matt Asay also wrote a good post recently, focusing on how terrible the law firm experience is. Everyone should read this- learn something about whether ‘thank you’ or $160K/year is more important, even for the stereotypical soulless lawyer :)

Red Hat's mindshare, and my summer internship

Sun, 21 Jan 2007 00:00:00 GMT

[Edited to clarify who was saying what, and a postscript added to further clarify my position re: developer mindshare.] Silicon Valley Sleuth said Thursday:

“Red Hat may not be perfect, but the vendor has by far the most developer mind share within the open source community.”

James Governor replied Friday (in his del.icio.us links, which he should make more linkable ;), like Stephen does):

“what might that mean? there is no single open source community.”

James is completely correct that there is no single open source community- there are server people, desktop people, solaris/bsd people, ‘commercial’ open source people, ‘enterprise’ people, community people, etc., and each of those is splintered into a thousand different projects and products. But here is the thing- Red Hat has a huge mindshare in basically all of those areas. They may not be liked; in many spaces they are being aggressively competed against; and in some places they are losing. But however you slice it, people are definitely aware of RH in virtually every open source community. If you’re an enterprise deploying ‘enterprise’ open source, odds are very high you’re using RHEL, though OpenSolaris is charging hard. If you’re doing web hacking, odds are overwhelming you at least evaluated RHEL or Fedora as a server, even if you settled on Debian or something else. If you’re doing open source desktop deployments, the same (though replace Debian with OpenSuSE or Ubuntu). If you’re an open source community of any stripe, odds are good your software has developers and users who use Fedora. (Mozilla, for example, gains the majority of their market share from Windows, but gets a ton of patches from RH [ed.: see comments], mozilla.org runs on RH, and one of the Mozilla board members is a RH employee.) If you’re a BSD, you’re aware of (jealous of?) of Linux’s (and hence RH’s) market share. If you’re an open source company, you’re envious of RH’s cash flow and growth, and you’re studying (and maybe mimicking) their business model. So there are many open source communities/spaces, and RH is being challenged aggressively in all of them. But RH is one of the few who can legitimately claim to have significant mindshare, either as a player, tools provider, or role model, in just about every one. So I think the original comment that James quoted is originally correct. What about me? One of those spaces I haven’t mentioned yet is the open source/corporate legal space. RH’s leadership on patents has been a model other open source companies should follow, their trademark policy is influential (even if I wish it could be done differently), and they get themselves involved in critical work like GPL v3.

Given that important role, I’m really excited to write that I’m going to work as an intern for RH’s general counsel’s office this summer. I’m sure I’ll be doing the legal equivalent of fetching coffee all summer, and at best working tangentially on the really interesting stuff I’ve mentioned above, but still- it is an interesting and influential place, and I’m excited to get three months to peek inside it, and take away lessons that I can apply wherever I work in the future. [Tangentially, as an open source-concerned intern, I’m not just excited about how Big And Important Red Hat is, I’m also pleased that they seem to get the little details right. For example, their company code of ethics (which I signed yesterday) explicitly says that contributing to open source projects, even if it adversely impacts the company, is not a violation of the conflict of interest rules. This can’t perfectly cover the natural tendency not to bite the hand that feeds, but it is a very solid step other open source companies should emulate. There are other nice, pro-open source/pro-community things scattered throughout their non-compete, code of ethics, etc., but that was the one that really jumped out. I’m always nervous when opening up an NDA or job contract- but after reading through this one I was thoroughly pleased. Kudos to RH on getting the little details right- another reason why I’m excited to work there for the summer.] Postscript: on developer mindshare After I originally wrote this, James and Stephen argue that “the linux platform with the most developer mindshare, we argue, is clearly Debian.” I have to disagree. I don’t think that has been true for a long time. Debian is clearly respected, and lot of people (including me) believe that Debian’s health and strong stand on Freedom are critical to the long-term health of Free software. But Debian’s long delays between releases and terrible installer (better now, but still primitive when compared to any modern distro) have been costing it users and mindshare for nearly a full decade now. I used to be a Debian bigot- to install Debian on my first laptop, c. 1999, I was very happy to jump through 1,000 hoops. One of the first hoops was to do a full Red Hat install, because even in 1999 Red Hat’s installer was light years ahead of Debian’s, and I couldn’t convince Debian’s installer to recognize critical bits of my hardware. I haven’t given a moment’s thought to installing Debian since late 2001, when I realized I could get a journaling FS in a RH install and it was likely to be literally years before I would get that in a stable Debian release. (I’m pretty sure that the default installer for stable Debian didn’t recognize ext3/XFS until Sarge, in June 2005; coincidentally the same release that included GNOME 2.x (first released in 2002) in stable.) This doesn’t even consider Debian’s constant internal bickering, which I’m willing to ignore when choosing an OS, but which generally has made their developer community the laughingstock of other large free software projects. Debian’s developer community is the retarded boogeyman the rest of us want to avoid being (and I say that as a GNOME developer, where talk first/develop later has become a scary norm. GNOME still isn’t that bad.) I think that has cost them a lot of mindshare, at least among knowledgeable/‘old hand’ free software developers. So… I love Debian, and think it is critical to the long-term health of the Free Software ecosystem. I hope it always has users, developers, and mindshare. But I haven’t considered installing it in ages, and I think I’m in a large majority there. If even a complete Free Software bigot like myself won’t install it, I can’t believe that it has dominant developer mindshare. I’m pretty sure that position still falls to Red Hat, by virtue of their broad user base, broad commercial uptake, and freedom, ease of use and up-to-dateness for non-commercial (read: community) users. (Worth noting, by the way, that Ian seems to agree that RH is #1 in mindshare.)

new research on motivation and money

Sun, 14 Jan 2007 00:00:00 GMT

I haven’t had a chance to read the whole thing yet, but those who were interested in my past post on intrinsic motivation might be interested in this study on the psychology of money, from Science late last year. Apparently even the mere mention of money can make people less helpful- “Reminders of money, relativeto nonmoney reminders, led to reduced requests for help andreduced helpfulness toward others.” There is also a related article which gives some context. Note that the survey was performed on undergrads in Minnesota and so probably has significant cultural biases; it would be very interesting to see a cross-cultural replication of the survey methodology.

[Ed.: this is really quite interesting; the paper is more nuanced than the bit I originally came across- the core of it is that reminders of money makes people feel more independent- not just less likely to give help, but also less likely to ask for help. The report ties this into a number of things, including self-image of those who are unemployed. Well worth a read.]

pledge-drive bounty system example for nvidia drivers

Sat, 06 Jan 2007 00:00:00 GMT

I’ve written in the past about use of online pledge systems to fund bounty-style payoffs for developers, so I thought I’d note that the nouveau project appears to be doing something similar. So far over halfway to the pledge drive goal with a month remaining- which is very interesting. I have pledged (free drivers are ultra-critical to our long-term health), though I wish they’d been much more explicit about what/who the money will go to (and I might not pay up on the pledge until they are at least a little more clear on that.)

Talk Proposal for LCA and/or GUADEC (2011)

Thu, 16 Nov 2006 00:00:00 GMT

This came to me in the shower, which means it is probably a terrible idea:

Legal English as She Is Spoke- From Legalese to Hackerese, by Way of English

How The Legal System is Worse Than You’d Feared

How The Legal System is Better Than You’d Hoped

As Jeff would say, book your tickets now.

the GPL is not a monopoly

Thu, 09 Nov 2006 00:00:00 GMT

Nice smackdown ruling by Judge Easterbrook. For a 6 page intro to antitrust pricing law via discussion of the GPL, go read. (Yes, he does make a fundamental error about selling GPL’d software in the first paragraph or so, but otherwise, sound.)

JZ at Columbia Law: PC as Appliance, Software as Service

Thu, 26 Oct 2006 00:00:00 GMT

My old boss, Jonathan Zittrain (the only person I know with a two-letter domain: jz.org) spoke today at Columbia. So I’m live-blogging-ish the talk.

starts off with the hourglass diagram- everything going through Internet Protocol- don’t need to know a whole lot about the top if you’re good at the bottom, or vice-versa: any task on any device can happen over any medium
he pairs it with a PC hourglass architecture- any app on top of the OS which sits on any x86 box- app author doesn’t need to know the details of a printer; OS hides that.
good that we have an open top of the hourglass- can create any new thing you want, including (for example) a slew of VOIP apps. This is all good…
… except for a slide showing a graph of security incidents, which is a very, very steep upward curve.
next a slide of the cap’n crunch whistle: AT&T could be hacked because it used sound to control the network, so the control could be gained by issuing the appropriate sound. PCs are still at this stage- data we love to send around is also a program, so separating data and control vectors is approximately impossible, as long as you want to keep the system flexible and open.
So now two examples of attempts to educate the user: email from Harvard IT, and a web browser https security alert, both of which we all instinctively ignore, or (better? worse?) read and can’t understand. Shows the Vista dialogs, which are prettier, but still unlikely to be useful, esp. since they default to off b/c of antitrust concerns.
MS auto-update is a problematic approach to security: besides someone potentially hacking MS and then wreaking serious havoc, you’re asking MS every day ‘how do I behave?’. Not just Windows; virtually every app is doing this now. Pushing software to be service rather than product- regular updates, just like any software.
Example: Tivo; discussion of difficulty of hacking it and tivo’s retroactive removal of features.
so we get to Napster, and the 9th circuit ruling, which overruled Sony and the 512 safe harbor, and (in his mind) reasonably decides that the company should put in some technology that makes it more easy to monitor copyright infringements.
Result: when Tivo sued a competitor for patent infringement in Texas; they are ordered in the case to update their software to disable it (which is possible since all DVRs have update functionality, obviously.) The next napster/grokster will likely have a software update functionality, and so could be forced to update it.
tangent re: GPL and software as a service: software on your own machine that you can’t control is ~= web 2.0 software that is on another machine that you can’t control. So JZ is finally aware of the web service GPL loophole
his concern: we are about to see the end of the free-floating exe file. Will the clamp be perfect such that only good software goes through and is only bad software blocked? Seems unlikely- the filter will fail, and we’ll still have zombies/viruses/etc. And so we’ll likely gravitate away from general purpose PCs and towards special-purpose machines (Tivo, Blackberry, etc.)
The PC is a swiss-army knife, and so is pretty bad at most things, just like a swiss-army knife. So it is in many ways good if things get more specialized- they get more reliable, easier to use. But the worry is that if you’ve got no ‘safety valve’- if TiVO is not threatened by MythTV, for example- then we have problems.
Tim Wu: Everyone having the same platform is a positive common good. JZ: the possibility for innovation is a positive externality that people don’t price for- they get value from innovation/generativity, but they aren’t willing to pay for it, so they are happy to buy something cheaper/stupider which fulfills their immediate needs.
Apple’s security was discussed a bit; I stopped following the discussion for a bit to move this post from Tomboy to Wordpress.
Discusses the AMD Internet Box and the like (such as Xbox 360). Discussing the Xbox specifically, notes that the biggest difference between it and a PC may be the business model- you can’t install anything on it unless the developer of that game has paid MS for the privilege. Thinks that the biggest reason PCs aren’t on that model is historical accident, and that most things are moving towards the Xbox model, which would be bad for innovation. [Notes that MS execs haven’t really thought about why these two models are different.]
Sees this pattern happening in other places wrt openness- wikipedia was really open b/c of generativity; now they have rulesets, bans, etc., and thinks this will become more intense as they become more popular. Really aren’t popular enough yet- what happens when Wal-Mart has real interest in what the Wal-Mart entry says? How will they cope? Some form of heavier hand will be needed, most likely, which bothers the happy anarchists (like Yochai.)
Solutions:
revisit the ‘sacred cow’ of end-to-end neutrality: ‘if you want a neat room, just shovel everything under the bed’. Simple network makes for messy end points, which are insecure. This makes your endpoint a middle from a choice perspective. So how do we, for example, quarantine machines on the network? That violates end-to-end but is probably better for generativity.
to borrow from global warming: for a long time, our ability to create pollution outstripped our ability to measure pollution. On the network, we did the same, so now we have a measurement problem- we don’t know what are on the endpoints, how healthy they are, etc., etc. So he wants to build this- his ‘dashboard’. Give consumers information about applications that is more useful, and based on information about mass usage, and which (being end-user-y and not MS-provided) can’t be ordered to do evil things by the government. Emergent ‘third way’ between individual action and government action.
Q&A:
Notes that courts have ruled (in an SEC case) that your fourth amendment rights mostly vanish when you hand information to a third party, so your email is not likely to be particularly safe, even under the fourth amendment. In the context of this discussion, any app that records where people go or what app they run that is held by MS is not really legally protected.
Q: isn’t an analysis of emergent network patterns conflicting with a tightening of end-to-end for security purposes? A: Definitely some potential tension, but sees them mostly as being at different levels. Notes that he isn’t completely anti-end-to-end, just thinks it is a flawed heuristic.
Q: how will new users get on the net? A: very interesting issue; has traditionally been PC first, then get a TiVO or what have you. May get to it over the phone or over an xbox first in the future.
Q: I didn’t get a sense that consumers will regret the problem. Is this path irreversible, once we go down it? Will people realize what they’ve lost? A: I’d love to believe that this would be the case, and we’d have a pendulum effect, where after a while, people suddenly want MythTVs. Worries that this is not the case because often we don’t actually own our net access boxes- corporate environment, cafe environment, mobile phones- generally an increasingly locked-down world. Also, that more and more devices will have ‘signatures’ which create gateways to information- you can only get to the interesting content if you use a safe/locked-down device.
Q: Tim Wu: contradictory issues: you’re saying that there is a security threat that will drive us away from this valuable, open model; but on the other hand, you’re willing to compromise openness, both on the network and at the end-point. A: is there a big contradiction there? I don’t think so; he calls it ‘subtlety’, and a warning to fellow travelers who worship at temple of end-to-end that the security problem is very real, and the first order attempts to deal with it are problematic, so we must seek out better, more subtle solutions. Tim responds: so maybe what you need are criteria for what constitutes a ‘legitimate’ lockdown/end-to-end violation. Compare and contrast to how a cell-phone is locked down. This might sound like the war on terror; because we have to fight the war on terror we have to repeal the death tax. Is the fear of security the same thing here? JZ: very much so; if customers/voters are so scared that they really run in the non-rights/non-open direction, we move in the same way. Should pre-empt that.
Q: Clarisa Long: what about economic demands of users? A: because we couldn’t kill napster with a button, we got a dialectic which led us to iTunes Music Store, which makes most people happy. He’s not anti-TiVO, just worries about the loss of the safety valve, and impossibility of valuation of what you are missing out on in the future. Scott(?): this story is hard to tell, but you can tell stories about what people might have missed out on- MiniTel for example.
Discussion: Tim on MS: hasn’t government been useful here? The antitrust suit has kept them on their toes; if they were like baseball, and got a free pass, would Windows be more like Xbox? JZ: maybe they’d at least block out new platform competitiors. Scott: there is an assumption about PCs that isn’t there with cell phones. JZ: baseline thought experiment re: net neutrality: suppose comcast added a channel called ‘the internet channel’ that allowed you to surf to pre-approved internet sites (like old AOL)- what then? Is that objectionable?
JZ notes that Google APIs/Google-as-OS is critically different from Windows-as-OS in that you can’t take away Windows (right now); Google can, and it is totally within their TOS.

My thoughts:

He only said ‘generativity’ twice; perhaps he has been convinced that it is a really hard word for people to wrap their heads around? [Edit later: he says that he feels that explaining generativity is still complex and would have distracted from the talk, which is why he kept it out of this particular talk.]
The notion that openness and anarchy leads to control problems in organizations is stimulating. Will have to think about that more.

IBM patents

Tue, 24 Oct 2006 00:00:00 GMT

Some time ago I talked about trusting open source companies, with the bottom line being ‘trust them as far as their licenses and their profit motives let you, and not a bit further.’ IBM has generally been very good about supporting open source, and as steven says, they’ve been very up front about their motivations- they are doing it because they want to make money, and they think open source and open standards help them make money.

This consistency has extended to their opinions on patents- they have made it clear that they think the system is broken, but they have also made it clear that they think patents are a perfectly legitimate business tool, and that they want to fix the system so that they can continue to make money on patents. (Their Counsel for IP law discussed this all in the Harvard panel I moderated last year- realplayer stream here.)

So it shouldn’t be a surprise to anyone that IBM are using patents to go after Amazon. What surprised me, after skimming the patents, is that the patents they are using to go after Amazon are so broad. With the exception of one (which is so opaque I can’t figure out what exactly it is patenting) a cursory reading suggests that these are exactly the kinds of broad, obvious patents that everyone (even IBM) at least says on the surface that they hate. Maybe by demonstrating that they have what Tim Bray calls ‘the Internet Tollbooth’ they think they can precipitate real patent reform, but that seems unlikely; more likely they just want a cut of Amazon’s pile. Shame, really, but it shouldn’t be a surprise. (It also shouldn’t raise much backlash from any company which doesn’t have a patent policy like RH’s- if your company is not following such a policy, some part of your company is jealous of IBM.)

[Tangentially, yes, the combination of law school and trying to enjoy NY is kicking my ass ATM, hence the light posting.]

[Update: David Maisters, a lawyer, has an interesing musing this morning on the subject of company ethics being less than the sum of the ethics of their employee/parts. It is mostly about lawyers and law firms, but it seems to have some relevance to this discussion. I’m curious to see what, if anything, comes up in his comments.]

Creative Commons Salon New York

Sun, 15 Oct 2006 00:00:00 GMT

On Friday night I went to NuBlu for the first NYC Creative Commons Salon. It was an interesting little get together. Some random thoughts:

I put up some pictures. Like all my pictures, they are CC-SA, but unfortunately the gallery hack I was using to indicate licensing is busted. Go ahead and enjoy them.
As far as I could tell, only one of the three artists who presented actually uses CC, which was disappointing.
Licensing aside, the art was a fun/funky mix of digital art. Paul Slocum showed off some cool music stuff, including a printer he’d hacked to play music via a combination of ‘mere’ printer noises and cassette tapes wrapped around printer drums. More here. Evan Harper of Eyebeam and Marisa Olson of Rhizome.org also presented- some neat stuff (some of it documented in the picture gallery, including Marisa’s tape gallery, and Evan’s… well, guerrilla seating and all-porn browser. What more can you say than ‘all-porn browser’. :)
Nublu is, without doubt, the trendiest (or wannabe trendiest) club I’ve ever been in- they are too hip to ‘have a sign over the door’. Still, nice space and very good DJ after the Salon.
Was good to meet some new folks and see Ronald.

Definitely glad I went, and will definitely make the next one.

By the way, for those in the New York area who are interested in this kind of thing, there is a great InfoLaw New York calendar full of events like this one, maintained by the kids at the NYULS Information Law Institute. Definitely worth subscribing to in your calendar tool of choice.

why DRM and our copyright system don't play nice together

Tue, 10 Oct 2006 00:00:00 GMT

[Originally posted at First Movers. Comments should be made there.]

[Update: !@#@!#@!ing POS WP text editor.]

Disclaimer Keep in mind that IANAL, and I’m still learning the limits of some of the things I’m talking about, so my legal claims may not be 100% accurate, though I stand behind the moral and legal intuition behind them. Also keep in mind that I’m tired, and will have no time in the near future to flesh this out to the length it deserves, so it may appear skimpy- that is not my intent, just my reality ATM. I look forward to comments on the post that might help improve, refine, or if need be correct the arguments.

With all that said, here is why I think DRM breaks our current copyright regime and as such is a problem.

The Nutshell

There are lots of facets- completely ignoring the hypothetical right to ‘share’ that many anti-DRM arguments depend on- that make up the constellation of rights and restrictions that we group together as ‘copyright’. I believe that DRM is fundamentally incompatible with several of these rights; extending some that should not be extended, and reducing others that should not be reduced.

The Rights of A Buyer of a Copyrighted Good

When you buy things, you have certain rights as a buyer. Most relevantly, since 1908 in the US, buyers of copyrighted goods have had a right to resell the good, a statutory right which has become known as the First Sale Doctrine. The basic idea comports with our intuitions about something we’ve bought- once you’ve bought something, you own it (like you own, say, your car), and can do with it basically as you please.

All current DRM (that I’m aware of) breaks this basic statutory right, as it is tied to a specific piece of hardware and does not allow the user to transfer the rights to different pieces of hardware. One could conceivably write DRM that allows resale, but it seems unlikely that this would occur unless it is statutorily mandated, since the publishing industries have been opposed to the first sale doctrine since Day One, and they dictate the design of most modern DRM.

[I personally believe that the first-sale doctrine also implies the right of users to use as they see fit before the sale- for example, moving it from one computer to another. This is a use model that is conceptually very, very difficult to fit into a DRM model without requiring people to register every computer/media player they own with a central registrar. But I really don’t know anything about the rights of users to use goods once they’ve bought them, so I won’t elaborate on this point much. Talk to me again about this one in a year :)]

The Rights of a Copyright Holder

In the US, copyrights derive from the Constitution, particularly the ‘promotion of science’ clause in Article 1. Specifically, the Constitution grants Congress the ability to create copyrights and patents ‘for limited times’. Conceptually, the Founding Fathers understood copyrights not as ‘intellectual property’ but as ‘limited monopolies’- that is, as monopolies granted by the state. While modern statutes haven’t really respected that notion, the basic intuition is sound- the state grants creators specific rights, and rights which are not granted to creators by the state should be reserved to the people in exchange for bearing the costs of a monopoly. Creators do not, and have never had, unlimited rights to do as they choose with their creations- which is something assumed by everyone who argues for ‘it is mine, so why can’t I put DRM on it?’

So, we limit the rights of copyright holders, and have since the day copyright was written into the Constitution. The first limitation, and most obvious (given the Constitution’s language) is on the length of copyrights. A DRM system that respects this right isn’t inconceivable- it would merely require that the player software phone home to a ‘trusted’ clock. But I’m pretty sure no current system does this, and depending on the existence of a remote server to get access to goods one owns when the copyright on the good expires does not seem like a wonderfully reliable mechanism for what is supposed to be a fundamental right in our system.

Much more problematic is the idea of fair use. Fair use, in a nutshell, is the idea that certain usages (educational uses, for example) cannot be prohibited by a copyright holder. There is no ‘bright line’ in fair use law- every case is decided on its own merits, which vary from situation to situation based on a number of tests. That makes deciding whether or not something is fair use very hard for judges. It also means that if you can make DRM which allows fair use, congratulations- you’ve written an AI, and you’re going to make a lot of money. In short, there is no way to write DRM which respects fair use- any copyright holder who uses effective DRM is saying ‘screw you’ to the limitations on copyright which our system has developed over the past 200 years, and replacing our legal system with technological force.

The canonical example of this last issue, in my mind, is the film teacher who wants to teach her students by showing clips from important films. Copyright law in this country makes it clear that the copyright holder cannot prevent the film teacher from editing the clips to use in her class as appropriate.

Summary

You don’t have to like file-sharing or hate Big Music to be against DRM. You just have to like the basic system of copyright law which we’ve evolved over the past 200 years- a system with fairly minimal buyer’s rights, and with fairly minimal restrictions on state-granted monopolies, and which even then is trampled on to various degrees by all existing and hypothetical DRM systems.

Future Avenues for Exploration

Once you start thinking about ‘What rights do we currently have? Would DRM take them away?’ there are a number of other issues that can be explored, which I might do in the future, but which I won’t right now. Among them:

Opt-in DRM: In the US, the presumption is that anyone who breaks DRM is guilty of a violation. Perhaps the legal regime should be shifted, making it illegal to apply DRM which creates new defacto rights. This would allow DRM to be used in cases like trade secrets, where there is no ‘limited time’ clause or fair use, while preventing its use in situations like copyright, at least until someone invents that darn AI.
Market forces: in the past, we’ve depended on the legal system to protect our rights. Should we depend on market forces in the future, as argued by some of those who support DRM? If we do depend on market forces to protect our rights as consumers, how does DRM impact competition (amongst DRM providers, tool providers, content providers, etc.)?
Other forms of IP: not all forms of IP have the same sets of rights and limitations. Would it be possible to envision DRM that is compatible with the legal regime for non-copyright IP (think: trade secrets), or DRM for copyright as envisioned in other nations?
Personal Use IP: we use copyright now in some circumstances where the item copyrighted isn’t beneficial to society in the way the founders envisioned. For example, some people copyright their pictures in part to help prevent unauthorized uses. Is it time to create a separate IP right whose motivation is personal privacy, akin more to trade secrets than copyright? If we did, would use of DRM be appropriate there?

Of course, there are also the other much-rehashed questions- how IP creators are supposed to make money without DRM, whether or not DRM is ‘just’ a form of contract (a la a EULA), and not a copyright license, etc.

[Image: a Viking padlock, via Wikipedia.]

ponderings on other economies

Mon, 02 Oct 2006 00:00:00 GMT

On the same day he spoke with Chris Anderson about the implications of Long Tail for alternative means of producing IP, Lessig blogged ‘on the economies of culture’. The fine folks over at Tech Liberation Front have posted recently on how markets don’t need money, and more recently on the gift economy.

I’d love to have coherent thoughts on this, but I don’t right at the moment. Some jotted down bits that might get refocused later:

The hybrid economy will happen on a sliding scale. Some participants (Lessig, for example, or the Grateful Dead and Phish) will be able to make money very reliably on the second-order effects (tenure for Lessig, live shows for Dead/Phish). They will, in general, opt for very liberal licensing of their first-order IP creations- books for Lessig, recorded music for the Dead/Phish. On the other end of the spectrum will be those who can’t for some reason reliably make money from second-order effects- musicians who hate performing live (or who suck at it) would be likely the most common example of this. They’ll obviously want to license as restrictively as possible. The middle ground will be occupied by, for example, RHEL, who will strictly license their trademark, but not their code, since they can reliably generate revenue as long as no one confuses the non-supported code with the officially supported version.
There will be a big business in helping people make the transition from enthusiastic volunteer to paid creator, or in surfing that boundary. We’ve already seen in free software that lots of people want to create for free; but that most of those people, given a choice, will happily take money to create full-time. So there will be services around channeling money to volunteers. Bounty programs; advertising placed on volunteer-owned websites (i.e., blogs); or professional placement specialists who help people find jobs that meet their demonstrated need- we’ll likely see more of all of these.
Editors/tastefinders will become even more important. Red Hat is already such an editor; editing and confirming quality is what people pay for RHEL for. Easy enough to imagine radio stations of CC-licensed music with paid advertising, or websites selling ads on cc-licensed pictures.
At Tech Liberation Front, I noted that as great as whuffie is, it doesn’t pay the bills. We’re not actually post-scarcity yet. I think this is a huge problem for volunteer communities. It means that whenever you feel like the rent, or retirement, or whatever $CASH_REQUIREMENT is hanging over your head, activities which don’t generate cash right now go right out the window. I think we’ll all be better off when whuffie-generating activities can also pay the bills directly- they’ll be more stable, more predictable, more useful. (And people will still be able to opt-out if they just want to have good, clean fun.)
Lessig’s meanderings are interesting, as always, but I am confused by his assumption that GPL (which defacto makes everything Free) is somehow incompatible with a hybrid economy, when the very first examples of hybrid economies that he cites- Mozilla and RH- both make their money while owning virtually none of their core IP. I respect that he is trying to push for flexibility in licensing while people experiment with hybrid business models, but it seems like in this post he unecessarily and incorrectly slammed those who disagree with him.

On Killing Spammers, and Other Methods of Setting Legal and Moral Precedent

Sat, 23 Sep 2006 00:00:00 GMT

I was reading one of my course books last week (probably Civil Procedure) and one of the minor notes mentioned a British case (early in the development of the jury system- 1200s? 1300s?) where a judge ordered the death penalty for a defendant despite a hung jury. The king responded by… literally hanging the judge. I’m sure that was the first and last time the King had to tell a judge to pay attention to the jury. Relatively speaking, some early product liability judgments were also huge- it got the attention of companies and helped focus them on the creation of safer products. Clearly, penalties we would now consider wildly disproportionate have at various points in the past helped establish precedent (both moral and legal) that certain things Just Aren’t Done.

So here is the thought that crossed my mind as I read that hanging case- do we need to do the same in spam? Life (or death) sentences for mass spammers until it is communicated that it is just not acceptable to spam? I realize, of course, that this would never fly constitutionally, and practically it is hard to define ‘mass’ spammer. But it really seems like it is a shame we probably couldn’t get away with killing a few spammers- because surely you wouldn’t need to do more than 1 or 2 before the point got across very clearly. To put it another way: I don’t think all spammers should die; I just think that enough spammers should die so that the rest stop doing it. :) We’re clearly in a fairly interesting historical situation, where some of the things we all hate have no clear moral or legal antecedents, and the penalties we’ve set up so far are clearly not discouraging enough.

So anyway… I’m really curious to do more reading and research about how, in times of historical change, precedent is set- because it seems like we need to do some precedent setting. Something else for the ‘papers to write’ file, I guess :)

what fsf got wrong

Fri, 22 Sep 2006 00:00:00 GMT

The FSF got some things wrong in this process as well. (But I had dinner in between posts.)

The FSF has failed to convince people that patents are a threat. The FSF folks apparently believe (1) that patents are a threat to free software projects and (2) that patents are immoral. These are distinct issues. I think if they’d focused on (1) they’d be ahead. Clearly the kernel guys think the best way to cope with the patent threat is to ignore it. The FSF has not effectively countered that argument, and so the kernel folks (and lots of other people) think that v3’s patent clauses are unnecessary and political, instead of a necessary defense against a dire threat.
The FSF has failed to convince people that DRM is a taking of freedom. For the kernel folks (and a lot of other people) DRM is just a choice programmers have made on top of their stack. I tend to disagree (for reasons I’ll probably make clear in perhaps another post this weekend) but however you slice it, the FSF has clearly failed in convincing people that DRM built on top of Linux is the equivalent of shackles built on top of their code, and hence, that the DRM clauses in v3 are necessary.
I’m not sure if this is a failure or not, but it was pretty clear from the beginning that the consultation was going to be an open way to get feedback, but that Richard was going to make the final calls. Given how famously difficult he is to convince of anything, and how the big problems to be solved by the license were apparently chosen before any open consultation, it is pretty understandable that some people (like the l-k guys) were turned off, and have chosen to act outside the system instead of within it.

These are not minor problems, but I should note that these should not completely blot out all the good the FSF has done within the process. The committee process has been a very open one, where just about anyone can contribute in a meaningful way. (Hell, they let me on one of them.) The software used to track and collate comments has overall worked well, and made it easy to spot problem areas quickly. (Sadly, it was not used on a mission statement.) So overall, despite the big-picture PR mistakes made above, the process has been very good and very smooth so far. CC, and any other community pondering license changes, should be following along to learn how to conduct a license review process.

What the kernel guys are and aren't (and really should be) saying about GPL v3

Fri, 22 Sep 2006 00:00:00 GMT

The kernel guys just put out a doc about their feelings on GPL v3. It is really a remarkable document, if for no other reason than that 30-ish kernel developers actually agreed on something :) My thoughts on it are that they are saying some very substantive things, but that they are dodging the real discussion- and maybe it is time for us to have that discussion again.

What they are saying, substantively*:

GPL v2 works just fine.
No problems are being solved by the new license.
The DRM clause limits what users can do, which contradicts the freedoms which users had under v2 and which might scare away both users and contributors.
The patent clauses would also scare away potential contributors.
The FSF is violating the trust of those who have used the GPL under the assumption that future versions would not be fundamentally different.

Freedom, and how it is defined, is really the issue that all these rotate around. How does it tie these together?

GPL v2 works just fine, and no problems are being solved by the new license- it does work fine, if you think that people using your code to build DRM-enabled products is acceptable. Otherwise it is very good- but clearly flawed.
The DRM and patent clauses limits users and scares away contributors- both of which are true, but assumes that DRM does not violate meaningful freedoms, and that patents are not a threat to our codebases. (Both of which are defensible positions, I believe, though I don’t agree.)
FSF is violating our trust by being ‘political’- which is true, if you think that FSF has never been political. If you’re sane, and realize FSF has from day 1 been political, then you might disagree with this :)

What the kernel guys really seem to want is a GPL 2.1 which reflects their very pragmatic approach to open source- take, as long as you give back. Past that, do whatever. What the FSF- and particularly Richard- wants is a GPL which reflects the FSF’s long-term approach to free software, where patents and DRM are another restriction (like binary software) that could reduce freedoms. Nothing in GPL v3 is inconsistent with FSF’s very long-term mission- to increase what they see as Freedom.

So really, as far as I can see, this is the old Open Source v. Free Software debate coming to a head again, in yet another guise. (Worse, it might be the GPL v. BSD license debate, where everyone argues about the definition of ‘freedom’, all over again.) I really don’t know where I stand on this, but I think it is clear most of the kernel developers are clearly in the Open Source camp. That’s fine- it is certainly their right, and frankly, I think they represent a majority of GPL v2 users. I do wish they had been more forthcoming in this inevitably important document, and spent less time confusing the issue. If they had, the document could have been a lot shorter, a lot sweeter, and a lot more accurate.

Let me make a stab at it, in fact, honestly trying to be as neutral as possible on the definition of Freedom:

“We believe that our particular community of GPL v2 users have come over time to a different definition of freedom than the FSF. We believe that the focus of the GPL should be on the elements that encourage collaborative participation, which include simplicity, enforced code-sharing, and end-user freedom. We reject the FSF’s attempt to define freedom in such a way as to include charged issues like DRM and patents, which our contributors disagree greatly about. As a result, we call on the FSF to stop the current discussion about GPL v3 and create a GPL v2.1, which does not seek to expand the Freedoms of GPL v2 in controversial directions, and instead focuses on strengthening and clarifying the terms of the current GPL so that we can more securely defend the rights and freedoms we believe we currently have, and which we have created a large community around.”

So, yeah. That’s really what it took them five pages to say. I think, put that way, they’ve got a fairly sound argument- clearly lots of people would want to use a GPL 2.1 that had the same focus as GPL v2, but with more refined legal safeguards. I personally would prefer a GPL v3, that prevents people from using my code to create devices whose primary purpose is to deliver DRMd content, and which protects me from the patent portfolios of companies which I may like but can’t trust. But clearly that is a difference of opinion that merely having an open comment period is not going to paper over.

It is telling, of course, that the kernel guys who wrote the paper (and Linus) did not participate in the open comment period. They could easily have done so, but I think at some level they know that this really isn’t about an issue they can discuss with the FSF. They must know that there is no way in hell GPL v2.1 is coming out of the FSF- convincing Richard to redefine what he sees as freedom (and the threats to it) is not ever going to fly. So they didn’t participate- they did an end-run. I wish they hadn’t run so far out, though.

Linus (as usual) says it very clearly and straightforwardly, but again, to the echo chamber of LKML and not to the FSF directly:

“My personal opinion is that a lot of the public discussion has been drivenby people who are motivated by the politics of the discussion. So you have a lot of very vocal GPLv3 supporters. But I think that the people who actually end up doing a lot of the development are usually not as vocal, and haev actually not been heard very much at all.

In some sense, the poll is a way for the people who actually do a lot of the work to show that the FSF doesn’t speak for necessarily even a very big portion of actual developers.”
Where he says ‘politics’ read ‘freedom’ and… yup. Sounds pretty familiar.

* They are saying a lot of other things that frankly I think they got very wrong. Another post about that shortly.

what the kernel guys got wrong

Fri, 22 Sep 2006 00:00:00 GMT

I just posted about what the kernel guys really want. They are saying some other non-substantive things, but most of these are either solvable or just plain wrong.

Virtually everything they are saying about license proliferation is wrong, except for the obvious statement that license proliferation is bad. We’re all agreed on that. GPL v3 increases compatibility with other licenses (apache license would now be compatible, for example, helping solve all the hoops beagle has to jump through currently to use lucene), so gpl v3 helps this problem, not hurts it. They are working hard to make even more licenses compatible, if they can- lots of people are looking at making eclipse license and gplv3 compat, for example.
Similarly, allowing GPL to add and remove clauses in an orderly way would actually reduce fragmentation, not increase it as they claim. Sure, you’d get lots of GPL variants- but many other licenses would quickly die away as they became GPL variants (LGPL, for example, will do just this), so the net number of licenses actively being used in new could should stay the same. And if there are 100 licenses, and 90% of them share 95% of their language, we’re way better off than the current situation- where we have 100 licenses, which mostly agree on shared goals, but which share no language and hence are hard to make work with each other. [The shared language things matter- if I find code under a GPL variant, it is a lot easier to convince someone to add or subtract one clause than it is to convince them to change from, say, MPL to GPL (any version.)]
They criticize the wording of the patent provision- but some very, very large patent patent portfolio owners have had large teams of lawyers participate in this process, and they’ve been willing to work with the draft. So it seems likely that the patent clause is not nearly as hosed as they think it is. The real thing to watch here is IBM- they are both the biggest contributors to the kernel, and the largest holder of patents in the world. So if they remain involved, then there is a pretty good chance that they think that the patent clause is (at least) salvageable.
They completely ignore the many small and real problems that have been solved- the license is now more likely to be upheld by international courts and has a clearer definition of linking, for example.
Their complaints about the DRM language are… well, maybe FUD is a little strong, but saying ‘people were confused at the first draft, so we should give up altogether’ is pretty irritating. They should either say flat out ‘we disagree philosophically with the DRM clause’ (which is fine, and honest) or they should work with those who are working hard to clean up the language by giving specific complaints.
c’mon, guys- when you say ‘politics’ we all know you mean ‘how we define ‘freedom”, or some variant thereof. Quit playing the linguistic game of calling it ‘politics’.
[Later edit: I totally forgot, of course, the most serious disingenousness- the belief that the FSF wasn’t political, and is now political. C’mon. The FSF has been political from day one, guys- everything they are doing now would have been pretty damn predictable from the first day RMS heard about DRM, and the first day someone asked ‘what about this patent?’ on an FSF mailing list. To claim that this is now betraying the trust of people is really pretty silly. Is it in disagreement with what most kernel FLOSS contributors believe? Quite possibly. Is it in disagreement with what the FSF has been advocating for more than a decade? No, not at all. C’mon.]

So yeah… again, a shorter, sweeter, more straightforward declaration discussion would have been preferable. They’ve got a strong core point- people disagree about what the core freedoms are. They don’t need to surround it with groundless claims to substantiate it.

What happens when statistics and masses replace institutions?

Mon, 18 Sep 2006 00:00:00 GMT

[Reposted from First Movers. Law and other fields are beginning to see what free software/open source has seen for a while, as more and more skilled people move to the web and begin to give away their knowledge, displacing established (read: knowledge hoarding) institutions along the way. Clay’s post, linked within, made me write about this in the legal context.]

I’ve long thought that in open source software we are seeing a trend away from trust in an institution (think: Microsoft) and towards trust in ‘good luck’- i.e., in the statistical likelihood that if you fall, someone will catch you. In open source, this is most manifest in support- instead of calling a 1-800 # (where someone is guaranteed to help you, as long as you’re willing to be on hold for ages and pay sometimes very high charges), one emails a list, where no one is responsible for you, but yet a great percentage of the time, someone will answer anyway. There is no guarantee, but community practices evolve to make it statistically likely that help (or bug fixing, or whatever) will occur. The internet makes this possible- whereas in the past if you wanted free advice, you had to have a close friend with the right skills free time, you can now draw from a much broader pool of people. If that pool is large enough (and in software, it appears to be) then it is a statistical matter that one of them is likely to have both the right skills and the right amount of free time.

Clay Shirky today makes an argument that this isn’t just something that is occurring in open source, but is hitting other fields of expertise as well: “My belief is that Wikipedia’s success dramatizes instead a change in the nature of authority, moving from trust inhering in guarantees offered by institutions to probabilities created by processes.” Instead of referring to a known expert to get at knowledge, you can ask Wikipedia- which is the output of a dialectic process which may fail in specific instances but which Clay seems to suggest can be trusted more than any one institution’s processes in the long run.

So does this have any implications for the law? My sense is that it might. The Berkman Center’s OpenLaw project experimented with generating briefs via volunteer input years ago, but never quite got the critical mass needed to take off and become self-sustaining. So it might not be that we’re writing briefs by public collaboraiton in a wiki any time soon. But Wikipedia is already an excellent resource for double-checking interpretation of important cases, SSRN downloads are being used to supplement (and perhaps eventually replace?) journal placement as a metric of quality of scholarly output, blogs are being cited in Supreme Court decisions, and we’re seeing some of the first computer systems that make legal decisions, and allow external input.

Clay would take from this that our legal orthodoxy and leading institutions are being challenged- in many cases, instead of first looking to what the Leading Journals tell us, we’re looking to what blogs, wikis, and other systems of shared expertise tell us. His extrapolation seems to be that this will eventually change how we feel about authority in our field. I’m not sure I’m ready to go that far- but based on some of the data points noted above, I’ve got a hunch we’ll end up a lot closer to his end of the spectrum than we currently are.

[No comments on my blog; if you want to comment, go to the original post at First Movers.]

Red Hat voting followups

Sun, 17 Sep 2006 00:00:00 GMT

There have been quite a few followups to my voting post. A couple of the most common themes:

Why do we need electronic voting anyway? It is inherently insecure. I think a lot of people, first off, tend to forget how insecure and exploitable paper ballots are- Chicago, Mexico City, and lots of other places will tell you that paper ballots are very, very exploitable. Secondly, I of course assume that a serious e-voting initiative would have at least a Voter Verifiable Paper Audit Trail- basically, a way to do recounts on paper, with a way for voters to verify that the right paper votes have been cast. (aka, ‘two databases are more secure than one.’) Finally, lots of smart people are working on even more secure alternatives, that potentially are even more secure than VVPAT approaches. I’d be certain that a serious open source-based voting project would not make the same mistakes everyone else has.
What about Ubuntu/Novell? Obviously both of them have the engineering qualifications to do this, but neither have focused of late on ‘outside the box’ projects- they seem to be focused, for perfectly good reason, on their distros and communities. So they are welcome to take me up on the suggestion- but it doesn’t seem like the kind of thing they are interested in right now. (Of course, non-corporate types can do it too- but corporate support is very meaningful in this kind of project.)
This isn’t new. Apparently not- Red Hat has apparently at least given it some previous thought, and there is even a functional GPL’d voting system in use in Australia (which, you’ll note, was audited by outside parties with patch-like results). I’m glad it isn’t original- that means I’m not insane ;)

Red Hat's next outside-the-box program: electronic voting

Thu, 14 Sep 2006 00:00:00 GMT

In the past year, Red Hat has gotten deeply involved in two projects- mugshot and OLPC- that get them outside their comfort zone (enterprise Unix-y operating systems) and into new territory. Here is my free advice on the next outside-the-enterprise-box project they should take on- one that would make the world a better place, keep them close to their core competencies, make them some money, and get their foot in the door in a critical market, all at one time.

I think that RH should go into voting machines.

Eh? Voting machines are not sexy. They’re dull. They’re duller than dull. But they are very important to democracy (a growing market! ;) and hence the world, and they are going electronic- with currently embarassing-to-criminal results.

So why should RH get involved? First off, electronic voting matches up well with open source’s traditional strengths.

security- As Ed Felten demonstrated spectacularly yesterday, the current generation of electronic voting machines are painfully insecure. Go watch the video. Open souce security auditing can do much better than that. (Diebold’s defense, by the way, is that Felten should have asked them for more information. That would not be a problem in an open source context.)
cost- Governments are fairly price sensitive, especially in low-profile areas like voting. Open source is traditionally very cost competitive, and in this particular case, the closed-source systems have to license components like WinCE, so they are definitely at a disadvantage.
pre-existing community- Corporate-sponsored open source work does best when it works in hand with existing bodies of volunteers and expertise. Such groups already exist in open source voting; open voting consortium is the first hit on google but I believe there are others as well.
political motivation: one of the most tried and true ways to motivate open source contributors is to give them a bad guy. Voting fraud is replete with bad guys on all sides; if a project got enough backing (i.e., RH) to make it look like it might get actually used in an actual election, people would come out of the woodwork to audit and patch it.

Secondly, voting plays specifically off RH’s strengths:

‘enterprise’ understanding and sales- governments are enterprises; they like being told about how enterprise-y their software is. RH is very good at this; telling them that Fedora E-Voting (or whatever) was Enterprise Quality shouldn’t be hard.
hardware support- as demonstrated by OLPC, and historically by RH’s long tradition of working with server vendors, RH is good at getting Linux going on new hardware. If RH could leverage the OLPC platform it could conceivably lead to very nice economies of scale, with a platform RH is already an expert on.
complex systems- RH is good at pulling lots of disparate pieces together. Obviously a comprehensive e-voting system is complicated and would require lots of engineering talent- which RH has in spades.

Finally, a voting project would fit needs that RH should be seeking to fill:

High profile in a critical market: practically every government in the world wants secure e-voting; what better way to get your foot in the door for later sales of servers, desktops, etc.? Combined with OLPC, this could be a double-whammy for RH marketing to governments.
Continued expansion of the Linux footprint. Anything that benefits Linux benefits RH, and making Linux the secure standard for one thing that every citizen should do would make a huge mindshare impact for Linux in general.
Revenue: after the various voting fiascos in 2000 and 2004, lots of governments are spending money on electronic voting right now. RH should get a piece of that pie.

So, yeah. E-voting. Have a blast, RH, and drop me a note when it is making you piles of cash and we’re all better off because of it :)

[Tangentially, it may be worth noting that OLPC and Mugshot don’t necessarily match up well with all these things that I’ve noted should be important to RH, or that RH is good at. In particular, mugshot is not something at all within RH’s comfort zone; instead, it is a deliberate attempt to grow RH’s skill base. They are experimenting with new design techniques; they are experimenting with a new business model (server-side services); and they are experimenting with a category (social software) that open source has never really tried to do before. It isn’t bad to be experimental- I do hope they succeed- but given how far they are from RH’s traditional strengths, it will be an uphill battle. OLPC, by contrast, plays off a lot of these strengths, even if the glamour part- the UI- is fairly different from what RH has done in the past.]

Death and rebirth of the science journal, journalism, and what the hell, maybe the law journal too

Tue, 12 Sep 2006 00:00:00 GMT

Interesting melange of articles, not quite sure what they point to for me in the future:

Two bioinformatics guys write about ‘the death of the paper’. Their thesis is that scientific journal articles are going to need to be reinvented, as massive data sets become more common, and more important than the actual paper/writing themselves. In specific, they want to publish the actual searchable databases, not just a handful of graphs, and they want to get academic ‘credit’ for something other than the actual article itself; primarily, the db.
Jurisdynamics* extrapolates the previous link into the legal realm. As I mention in the comments, legal articles don’t typically have databases, so I think if the legal article matures technologically, it’ll look more like the next two links…
… in which Stephen O’Grady writes about microformats replacing boxscores and the future of journalism, and Adrian Holovaty writes similarly and in more depth (brilliant minds thinking alike, yadda, yadda.) This is in some ways the exact opposite of the ‘death of the paper’ article, since microformats are data in micro-sized chunks, and bioinformatics databases are anything but micro. But obviously the core is the same- traditional reporting and traditional scientific papers could potentially become vastly more valuable if they contained machine-parseable data.
Of course, microformats.org has given some thought to some of these things. Of particular interest to me right now is that they have given some thought to legal citations. So a microformat-driven journal- and the tools to consume that data- is perhaps not far off. (Of course, the utility of all this in the legal journal is constrained by the two proprietary databases that drive all legal research, but that is a rant for another time.)

So what does this mean, exactly? I’m honestly not sure, but the obvious conclusion to draw is that everyone on the publishing side of things (CMSs, word processors, and of course authors themselces) needs to be thinking very hard about how to publish all the relevant structured data that they can, and doing it soon, because the demand from content creators is finally in the pipeline. On the consumption side (web browsers, word processors, etc.) people should start thinking about how they can make the coming flood of parseable data useful to their users. That might look like whatever the hell Mark Pilgrim is working on, or it might look like dabbledb, or more likely like something not yet invented, but people should probably start thinking about it now, because time may be running out if you want to get in on the ground floor :) * conflict of interest note: I might start writing for one of their side projects soon.

facebook rebellion(?), and potential lessons for other internet communities

Wed, 06 Sep 2006 00:00:00 GMT

So facebook did an update last night, changing it from something that had all the data to enable stalkers, but which made it mildly irritating to do it from their UI, to making it radically easy to find out all sorts of personal information about someone. Lets be utterly, 100% clear- you can’t do anything now that you couldn’t do 48 hours ago. They just made something that had been mildly hidden very, very obvious. In 43 hours, 345,000 people have joined the largest protest group- ‘Students Against Facebook News Feed’. In comparison, the self-titled ‘largest facebook group ever’ has 840,000 members. So that group is huge, growing at an insane rate (over 20K/hour for most of today, has grown by 4,000 while I’ve written this post) and that is only one of many. Clearly putting it in people’s face every time they log in exactly how little privacy they have may have been a mistake for facebook. There is a pretty straightforward lesson here for anyone building online community- the things you and your power users think are obvious (‘it is already possible to stalk someone, duh!’) may not be obvious to the vast majority of your community members. Surface those issues that are obvious to the core without thinking about the details of how you surface it outside the core and it may well blow up in your face, even if nothing substantive has changed.

NB: there may be another long-term lesson here: people adjust and things blow over sometimes. It will be really interesting to see whether or not that happens in this case, and why. If I had to place a bet, I’d guess that facebook will make some very minor changes (one or two categories might become opt-in instead of opt-out) and the essentially exhibitionist facebook crowd will get used to it. If they do get used to it, that has huge implications for the future of privacy in our society- the majority of an entire generation will have spent very formative years living very, very, very publicly, and that will inevitably influence what they think of privacy as a value in the future.

on blogging in the corporate open source context

Sun, 27 Aug 2006 00:00:00 GMT

One of the more interesting sub-threads spun off by my QA posts of the past week happened in the comments of this post, where I glibly tossed off the comment that ‘I assume that at least some developers blog about what they are thinking about/working on, and if no developer blogs about this Very Big Fuckup, then… that ain’t good. :)’

Since then, Tollef and Mark have each blogged about the problem, about 48-72 hours (depending on how you want to count) after it happened. So a key issue (lack of frank, open commentary on the problem from significant, relevant community members) is resolved in this specific case. Each of the posts are detailed, relevant, honest communications that go a long way towards reassuring me as an Ubuntu user that Canonical takes the problem very seriously and is going to make sure it never happens again. [I will return to the substance of the QA problem involved at some other time; it seems Mark, Tollef and others have a solid grasp on the key issues, so it isn’t pressing.]

In this post I’ll turn to the more general question: why do I think paid open source developers should be blogging fairly regularly? What issues are involved?

To start with, open source as a business model only makes sense if your company has an active community which contributes QA, code, sales, or other resources to your company. If you are opening your code without getting contributions back, you have no competitive advantage over a proprietary competitor who has free trial downloads, and likely several disadvantages. Other people who want to grow a community should also do so, of course, but they have no responsibility to do so. Open source companies who aren’t actively investing in creating community are not fulfilling their responsibility to their investors. At this point, Ubuntu/Canonical may be the best example of how to do this, but as last week shows, there are still lessons to be learned by everyone.So… how do you go about creating and fostering community? Basically, you make friends. There are a million ways to do this (being polite in bugzilla, having good mailing lists, etc.) but they mostly boil down to speaking to each other in a human voice. So compare and contrast: official ubuntu problem announce with Tollef’s blog. The official post is good- it speaks to customers, people who aren’t friends and likely won’t be. There is an expectation of a formal tone there. But the community should be composed of your friends, and you communicate with friends differently- you use the tone Mark and Tollef used, ideally in a more timely manner :) And this is why blogging is so good for open source community development. The mechanism allows for timely delivery of communication- you expect friends to keep in touch regularly, especially when something significant happens that might affect your friendship. The typical style of blogs (and the segmentation from official mechanisms of communication) mean that the tone is usually less formal and more friendly- exactly what you want if you’re trying to create new friends. It is personal, too- it is much easier to make friends with Tollef or Mark than it is with an abstract logo. It is also public, and with comments, can typically be interactive. It is much harder to make new friends if they can’t find you, or if they can’t talk back.

Is blogging perfect, or exclusive? No, of course not- you need a wide variety of tools. But it has quickly become pretty critical, I believe, to creating a functional and healthy and growing community. Some responses to points from the comments in the last post:

Obviously blogging takes away from time that could be spent doing other things, like fixing bugs. Valuing blogging is hard- the value isn’t obvious, it is indirect, and it varies from person to person, role to role, and company to company. Good employees and good management identifies things like that, puts a value on them, and tries to do them (or encourages employees to do them) in appropriate levels. This is true of a lot of things, not just blogging- documentation, good bugzilla habits, developing maintainable processes, etc. So if, as a paid open source hacker, you or your management thinks the only valuable thing you do is write code, you’ve likely got bad management. :)
Relatedly, friendly blogging doesn’t have to take much time. It would have taken about 30 seconds for Mark or someone else to open up a browser, say ‘damn, that sucked; working on it- more details tomorrow’ and hit post, and that would have had a huge impact- way more impact than this verbose, hour-long post will ever have.
One attempt at justifying Ubuntu’s lag on response was ‘We were in a sprint’- i.e., we were all locked in a room together, working hard. There are of course many ways to interpret this, but here’s one way: ‘we were so busy being cut off from the community that we didn’t have time to stop being cut off from the community.’ As evolution learned the hard way and has spent some time trying to correct, it is more efficient in the short-term to put all the paid people in one place. And it is very, very tempting to do that- you spend less time explaining, less time persuading, more time just doing. Everyone loves JFDI. But long-term, if you start working only with each other, it is very unhealthy for the project. If anything, while in a sprint, Canonical folks should be more sensitive to what is going on outside, and be very careful to not neglect it, else it is very easy to start doing ‘us (Canonical) and them (community)’ instead of ‘us’ (Ubuntu).
From the same comment: ‘[Blogging] is one of the least efficient ways of talking about things.’ Again, the measurement problem. Are you trying to specifically solve the X problem? Yes, a blog post is a terribly, terribly inefficient way for X developers to talk to each other about how to solve the problem. Face-to-face is undoubtedly the most efficient way to fix the X problem. Are you also trying to build the trust of the community? The number of friends (aka community members) you have? Talking face-to-face, in that case, is completely inefficient- no one knows you did it except the two people involved. Again, you have to find a balance.

Anyway, this has gone on too long so I’ll stop. Bottom line: blogging is a great way to create friends. In open source, friends create better software, albeit usually indirectly. So anyone serious about creating better software needs to figure out how to incorporate good, friendly communication into their workflow. Ubuntu does this way better than most- but still screws it up from time to time, as it did last week, and we should all learn from it.

standards: microsoft, netscape- is there a third way?

Tue, 25 Jul 2006 00:00:00 GMT

Are there any examples where someone created a broadly deployed standard and did not in time become either MS (high, expensive barriers to entry to use/support the standard, hence hated but wealthy) or Netscape (low barriers to entry, hence loved but dead?) I really can’t think of any, but I’d love to know of any examples out there. Not just software; could be hardware, or really any network effect.

I ask because I firmly believe open standards are a net societal good, but it seems to me that traditional capitalist economic incentives may fail to create this particular good, and I’m interested in what kinds of tweaks might be necessary (or not) to see this happen, while maintaining the best of the competitive, entrepreneurial tech industry.

(I’ve actually turned on comments for once; lets see how spammed they get :)

GNOME is people^Wmosaics^Wpeople

Mon, 17 Jul 2006 00:00:00 GMT

I’ve posted the mosaics from my ‘gnome is people’ slide deck. I’ll post the mugshots and ideally instructions on use of the totally awesome metapixel tomorrow.

talks I gave in 2006

Mon, 17 Jul 2006 00:00:00 GMT

In the past year, I’ve given a few talks. In roughly reverse chronological order, before I forget (yes, I’m using the blog as a purely personal CMS :)-

the closing at GUADEC 2006, aka the ‘gnome is people talk’. PDF here; people mosaic here. (More pictures/mosaic versions coming soon.)
an intro to stopbadware.org, given at the Asilomar Microcomputer Workshop. ooo-html here.
a talk on open standards at LWE. News Forge reported decently on it, but I did not have any slides so nothing to put up.
I moderated a panel on Patents and Open Source at the annual JOLT symposium. I have not yet watched the webcast but really should.
Spoke to a small learning technology group at HBS about the Berkman Center- the kind of outreach within the Harvard community that Berkman should do more of. The host and organizer, Denis Saulnier, wrote up some notes on it.

guadec thoughts, #1- health of GNOME and helping users kick ass

Wed, 05 Jul 2006 00:00:00 GMT

I have a number of GUADEC thoughts I’d like to throw out there; they will probably come in dribs and drabs. So this is GUADEC thoughts #1 :)

GNOME is, overall, very healthy. We’re a little diffuse right now- not the sense of direction and drive we had around 2.0. But otherwise, we’ve got a lot of people, a lot of energy; a lot of companies (large and small) investing in a diverse number of projects; we’ve got a lot of people shoring up our infrastructure (gtk, various GL-bits, etc.). So we’re poised and ready. When we find our focus and define our problem, we’re going to attack it relentlessly, and it is going to be pretty awesome to see, I think.
Which brings us to what the next focus will be. :) In retrospect, much of our work in 2.0 and since could be summed up as ‘make the user experience not suck.’ We’ve polished, trimmed, tucked, and made things Just Work, such that we can legimitately say now we’ve got a pretty solid basic experience (though of course it is still not perfect and still needs much work.) I’ve been pimping a number of specific improvements for a while (people as first-class object, search as primary file interface, collaboration, etc.) for a while, but after listening to Kathy Sierra’s excellent talk at GUADEC, I think the overarching theme that is going to carry us forward once we figure out how to do it consistently will be ‘helping our users kick ass’. So far, we’ve gotten out of the way- if you know what you want to do, we won’t stop you. But if you don’t know what you want to do on Linux, we haven’t helped you- we’ve left you with a big, blank screen and pretty poor tools. Really, our user experience is only complete if you’re a hacker- in that case, Linux has the tools to really help you kick ass once GNOME has gotten out of your way. So I think GNOME of the future (3.x? Topaz? Whatever!) must help non-hackers kick ass. Now that we’ve gotten out of user’s way, we need video editors, sound editors, picture tools, great collaboration, innovative data gathering and filtering- tools that help people do what they want to do. Luckily, we’ve got the beginnings of great tools in all of these areas and more. Lots of them were demoed at GUADEC. Somehow (I’m not sure how yet) we’re going to put those things together, so that in a few years, our users will sit down and really be able to quickly kick ass with the help of GNOME. We’re not there yet, but we will be. GNOME: Helping Users Kick Ass.

guadec thoughts #2: client development platforms and the web

Wed, 05 Jul 2006 00:00:00 GMT

Someone who I respect a lot told me at GUADEC ‘open source is doomed’. He believed that the small-ish apps we tend to do pretty well will migrate to the web, increasing the capital costs of delivering good software and giving next-gen proprietary companies like Google even greater advantages than current-gen proprietary companies like MS. (I’m vastly over-simplifying his complicated argument, but bear with me :) I’ve had a half-written essay on ‘why web apps suck and they are beating us anyway’ on my drive for a while, but this conversation at GUADEC made the light switch on for me.

Three big things:

Web development/deployment is easy, and desktop is not.
Web development makes certain things easy; primarily location independence and collaboration.
Desktop development has advantages web devel does not (rich inter-app integration, localized search, etc.) but taking advantage of them is a PITA.

Or more simply- our biggest competition in the developer space is not microsoft, and it isn’t apple. Our biggest competition in the developer space is php, rails, and the web client-server paradigm. C# and Java are great, but as long as they are pretty wrappers on the same style of development we’ve always done, they are lipstick on a pig. We need to take the plunge and fundamentally make development more web-like while also leveraging the strengths of the client, or else we really are in trouble. So, what’s the constructive takeaway that became clear to me at GUADEC? Our developer platform (really, any developer platform that wants to be relevant in 3 years) needs to be:

braindead easy to start with: if you can’t have an app running in an hour, you’re in trouble. 80% principle applies here- the rails people say ‘we don’t care if you can’t build Amazon with rails’; we should probably say ‘we don’t care if you can’t build evo with g-rails.’ If we can’t make developing a desktop app as easy as a web app, people will develop web apps. Simple as that.
dead easy to ship, deploy, and update: probably impossible to be easier than the web here, but we keep saying ‘apt is better than windows install tools’, which isn’t relevant- that’s like saying your car is better than a horse and buggy. Might be true, but the web’s install/use experience is a formula one car. You must beat that, not the horse and buggy. This is something I’m sure others have realized forever but I never did.
building a collaborative app must be easy: I have been using writely instead of abi at work because I can trivially and transparently collaborate with my co-workers. The development platform must have collaboration as an easy-to-use part of the platform or the web will wipe us out on that feature alone.
easy/powerful integration with search: search is really just the canonical example, for me, of things that are easy do across a desktop but which are hard for, say, GoogleOS to do. Obviously google can make it easy for me to search across all google properties, but never (or at least painfully) across flickr, delicious, etc. Our development platform should make it trivial to automagically instrument your files and let beagle know about them.
easy/powerful integration with hardware: another thing desktops can do well and web apps can’t- our platform should make it easy to take full advantage of webcams, microphones, etc. Of course, like many of the other things on this list, this goes way beyond GNOME, but we’ve done that before, and must keep doing it. [Ed.: added later. I knew I’d forgotten something ;)]
identify the web’s weak points, and go after them: search is just one example of things that local, client apps can do easily that web apps cannot. Development platforms (and apps) should be brainstorming hard about all those things, prioritizing them by user impact, and doing them. Every advantage of things you can do that the web can’t should be made trivial to develop and brought to users quickly.

Anyway… I guess that’s just a rant. But it was something that I hadn’t fully known how to say until a conversation or two at GUADEC.

guadec thoughts #3: where is .gnome?

Wed, 05 Jul 2006 00:00:00 GMT

Seeing so many of us using proprietary software for some of our most treasured possessions (our pictures, in flickr) has bugged me deeply this week. Just as bad, it strikes me as a fairly large and self-sustainable business opportunity- a small but growing number of people are willing to pay for services which give them the kind of control that flickr and others can’t or won’t give. Further, 37 Signals and other things has convinced me that it is possible to build small, basically self-financed web businesses. We now have millions of GNOME users out there; just 100,000 (hell, 10,000) GNOME users paying $5 a month for hardware, bandwidth and some software would finance a lot of software development. So I believe firmly there is a big opportunity out there for someone to do a free software based for-pay web service that integrates well with tools like f-spot, gnome-blog, evo, gossip, ekiga, nautilus, etc. It should be easy for GNOME users to sign up for one account, pay a small monthly or yearly fee, and be able to easily (no further configuration) publish their photos, blogs, etc., and communicate via email/jabber/voip/etc. Could be a small for-profit (like 37 Signals) or it could be the funding source for the first free-software cooperative. Either way, the opportunity is there for someone to do some agile, rapid development and have this in place soon.

crowding out of intrinsic motivations- aka, the bounty problem

Sun, 18 Jun 2006 00:00:00 GMT

A couple GUADECs ago, I agreed to do some good old fashioned research for the board on the issue of ‘crowding out of intrinsic motivations’- in other words, what happens when you start paying volunteers? I had been told by someone (I believe by the excellent Karim Lakhani) that there was good research demonstrating repeatedly that paying volunteers can have a counter-intuitive effect- that paid volunteers end up working less. I didn’t do the follow-up research, unfortunately, so I was unprepared to discuss the issue when bounties came up a few months later in a GNOME Foundation Board meeting at GUADEC.

While reading Karim’s dissertation (verdict: excellent and interesting- a blog about that when I finish it) I came across a reference to a key paper in the field. Today, in between world cup matches, I finally sat down and found the paper (here), and started reading it. Thanks to the excellent scholar.google.com, I was able to find an even better series of papers citing that one, providing context and lots more information. I strongly recommend anyone thinking about bounties or other financial incentives in a free software context read in particular ‘Motivation Crowding Theory: a Survey of Empirical Evidence’, by Frey and Jegen. (Ignore the economics; skip to the examples, which are really interesting.) Herewith some notes and comments:

while at first the idea is counterintuitive, the basic notion is straightforward: when people do things for their own intrinsic goodness (i.e., for reasons other than payment), introducing payment can reduce the amount of invovement.
Clearest example I’ve found in the quick literature skim so far: an experiment on parents who used Israeli child care. The parents had to pick up their kids at the end of the day; being late was not punished financially, but obviously was an inconvenience to the teachers. When fines were instituted, presumably parents would get more timely in picking up their kids, since they had whatever motivated them previously, plus the fine. The opposite occured- parents became worse at picking their kids up on time when the fine was in place. The real kicker? The fine was canceled… and parents did not return to their original level of picking kids up on time. They had been permanently (at least for the duration of the experiment) ‘ruined.’ (Referenced article is here, but not available publicly, unfortunately; I read about it in Frey and Jegen.)
The basic psychological rationale behind crowding out theory is that as soon as you pay people (or introduce other ‘forcing’ incentives, like increased managerial oversight of employees), you’re reducing the sense of self-determination and self-esteem, and so their intrinsic motivation- doing it because they want to help others, or because it is fun, or because they are embarassed to seem like they don’t care about their kids.
This isn’t all bad- there are also examples of ‘crowding in’, where external incentives can strengthen pre-existing intrinsic motivations- for example, if laws are structured to imply to citizens that citizens are trusted, they may in fact act in a more trust-worthy manner because they feel more valued/respected/etc.
There is at least some controversy about this theory in academia. There is a faction of behavioralist psychologists who argues that the whole thing is BS. However, both of the papers by economists that I read suggested that this faction’s research was deeply flawed and conclusively disproved by the first paper I linked to. There are apparently also a number of economists who don’t believe that this effect can be more significant than positive economic incentives (i.e., they believe that increased pay will always increase supply, without exception); the second paper I linked to seems like a fairly conclusive debunking of this position.
I have not yet seen references to research into community-wide crowding out; i.e., if I’m offered money to do bug work, does that crowd out incentives for Elijah and Olav? (The anecdotal evidence would suggest ‘no’, but perhaps that is partially because of the large gap between volunteering and full-time jobs- bounties may be different in this respect.)
Directly relevant to GNOME, there is some research that indicates that paying volunteers can reduce their overall level of contribution. Specifically, it concludes that those paid small amounts in correlation with volunteering work fewer hours than the average volunteer, while those paid large amounts end up working more hours than the average volunteer. The data is survey based, rather than experiment-based, though, so I’m a little leery of placing too much weight on it- the effects may well be correlation and not causation, though the study authors do attempt to control for other causes.

So, uh, what does all this mean? Not sure it means a whole lot, exactly- none of the research is so strong as to be conclusive or suggest direct guidelines for a bounty-issuing volunteer organization. It does suggest to me that we should consider doing more reading and research before substantially expanding payments to volunteers. Given the suggestion that these communities are fragile (i.e, that once you’ve destroyed the sense of intrinsic motivation, it doesn’t come back) it suggests that this isn’t something to be trifled with without thought. Finally, it suggests that there is a very, very good psych/econ paper lurking in google’s bounty system- surely this is one of the widest-scale experiments in potential crowding out ever, and if someone can figure out a clever way of measuring the impact, they should have a very good paper and very useful advice for us on their hands.

Anyway, the last two papers (not the first one, it is by psychologists and substantially more unreadable than the other two) took me only a couple hours to read; I’d suggest that anyone interested in this topic should suck them down and give them a read.

the excellent licensing wisdom of rlove

Thu, 08 Jun 2006 00:00:00 GMT

luis: I don’t think J5 got your blog post. I haven’t had a chance to read it yet, I’m at work only the one sentence that came through wordpress moderation certainly my point was not an ‘us v. them’ dichotomy exactly, your point was more on the power of the license right nothing about who was good or who was bad but that that was all made moot by the license right maybe I should s/company/aggregations of people/ in the post ;) or s/company/copyright holder/ yes, the latter maybe s/company/joint copyright holder/ ? or do what I do and punch people in the face with your thesis: “The license is the great equalizer” or some snappy conclusion I’m not *quite* so cynical as to not trust you, for example, if you decided to implement lovix tomorrow, I would probably use it whatever the license and I appreciate that and I’d probably add features, just for you little luis-inspired easter eggs even with lovix, though, you have no chips without the right license what about your undying love for me? what if I died and my estate was run by crooks? or I declared Chapter 11? or — god forbid — Chapter 7? I am just saying. You want some chips. let us just post this conversation to our blogs and smite our doubters with it.

(Yes, I’ll probably post a more serious response when I’m home from work.)

on trusting open source companies

Wed, 07 Jun 2006 00:00:00 GMT

Dave: but you’ve hit on the head exactly why you can’t trust Sun (or Novell, or RH) any further than you can trust their licenses. I love Glynn like a brother, I like Danese, and Simon Phipps and Jon Schwartz appear to be incredibly sharp and fairly clueful, and so I’m optimistic that the company will do the right things in the future. But what if the corporate winds change? Danese is already gone (and apparently was frustrated); what if the stock slips again and Schwartz and Phipps are the sacrificial lambs? At that point, all the community has is the license, and Sun’s licensing choices… typically at best they signal that Sun is ‘first among equals’, at middling they indicate strong distrust of the community, and at worst they indicate outright attempts to block interoperability with the community. When Sun actually trusts communities, and signals as such by treating the community as equals and giving the community the power to fork (aka by putting their jewels under GPL-compatible licenses), then the community should (and I think will) trust them back. But not until then.

Re: MPL and firefox, lots of people justifiably weren’t happy until it was triple licensed (which didn’t completely resolve netscape/aol’s privileged position, but at least ameliorated the problem). I personally still don’t completely trust them (because of the trademark issues about which I’ve blogged about before) but until I or someone else comes up with a trademark license that actually respects freedom two I probably should shut up about that :) (Or maybe I mean ‘respects powerplay two… another post, I guess.)

Anarchist in the Library, Siva Vaidhyanathan

Wed, 10 May 2006 00:00:00 GMT

I just finished Anarchist in the Library, by Siva Vaidhyanathan. I probably wasn’t the right target for this book- too many of the arguments and discussions were pretty old hat to me. It did cover a much broader range than the average info-policy book, but it didn’t seem to tie them all that coherently together, unfortunately. That said, the book did attempt to provide an interesting analytical framework- to grotesquely over-simplify, the balance between anarchy and oligarchy. It is a reasonable way of looking at the world- certainly it offers the possibility of tying together into a single narrative such things as the NSA’s Total Information Awareness, slashdot trolls, and Big Entertainment’s DRM. As a result, overall, I’m glad I read the book- this might be a useful mental tool. But if you read the other usual suspects in info-policy, don’t buy the book- just find a copy and read the intro and the final chapter. The rest will fall into place without reading the intervening chapters. :)

Rainbows End- Vernor Vinge

Fri, 05 May 2006 00:00:00 GMT

Having been a bit cranky and just wanting to get away from it all a bit, in the past two nights I’ve plowed through Rainbows End, by Vernor Vinge. It is typical Vinge in some senses (the renegades who want to stay free of government surveillance use the HURD), but very near-future- set in 2025, just like True Names. The characters aren’t his best, but the ideas are all over the place, and most are just far enough out there to be challenging, but also close enough to be plausible. Anyway… I thoroughly enjoyed it, and anyone who likes Big Ideas scifi should definitely pick it up.

"New Features aren't Innovation" and ekiga/gaim/evo

Wed, 26 Apr 2006 00:00:00 GMT

Great post by Dare Obasanjo (MS employee) titled ‘New Features Are Not Innovation’ that everyone in software should read.

Along those lines, on the one hand, I’m thrilled to see that ekiga is working on improving their UI, but on the other hand, what I really want to do is lock ekiga, gaim, and evo in a room at GUADEC and not let them out until I have one data store for people and one UI to get at them. It isn’t rocket science, it just requires people reaching out beyond their communities and giving Linux users something that no other platform really has yet, which I think would represent actual simplification and innovation, in ways the various proprietary OS silos just can’t do. It seems sort of sad that orph might get closer, faster, to that with gimmie than the actual clients have. :/

[Edit later: I realize I said ‘data store’, but that was unclear- what I meant is that to the user it should appear as if there is one data store- i.e., the totally false and historical breakages between communication apps should be broken down. The data can be stored in 10,000 different places, or on one shared set of punch cards, for all I care, as long as when I get an IM from Jeff I can instantly and sanely decide to respond via IM, email, or VOIP, and when I decide ‘I want to talk to Jeff’, I open a Jeff object, and then pick an appropriate method, instead of then having to pick through several databases and tools to figure out the best method.]

well, blah

Sun, 26 Mar 2006 00:00:00 GMT

So I finally redirected tieguy.org to my new host at rimuhosting. Mostly I’m happy, though my blog looks like butt and I need to fix the theme. (Does it really matter? Who reads blogs from the web anyway?) Apologies to any planets the new feed spammed. Mostly pretty psyched- still can’t get over how cool the Gallery Google Maps plugin is, or that I now have RSS feeds for my galleries so that I can get my mom to subscribe to my picture stream. Again, need to do some theme hacking on the gallery, though- a little non-obvious to navigate right now, and my CC licenses have dropped off the face of the earth. (Except, oddly, in the RSS feed.)

After all that, what blahs me is the discovery that I’m so close and yet so far on blog tools. One of the big plusses for me of switching to a new host was the ability to run a db server, and hence to run more sophisticated blog software than I had been running. So far, so good- I’m running WP now. I have categories, which is great, since I’d like to be able to separate posts about gnome from posts about work, etc. But it turns out I’m now dissatisfied with all my posting options :/

So, I guess my perfect blog tool looks something like:

Utterly minimal posting cycle: launch from panel, (select blog if I have more than one), type subject, type body, select category, hit ‘post’, app goes away and I stop thinking about it. gnome-blog works perfectly here; kblogger apparently the same. BloGTK fails here because I need to ‘connect’ before I post, and because it defaults to posting but not publishing, so that is one more click in the minimal cycle. (Yes, I know there is a preference for this, but (1) why does it not just remember what I used last, and (2) why is the default to assume that I’m an idiot? The default should be that I meant what I said- post it!) Drivel fails here because it doesn’t exit after posting, and at least the first time I had to ‘show more options’ to choose a category. (Drivel should look to monkey journal to see how to do this with less widgetry.) The native Wordpress web form fails here because I have to launch the browser and then navigate to the correct form. Also loses points because the browser is much slower to launch than a dedicated tool.
Easily accessible formatting. gnome-blog wins here; bold, italic, and link. No fuss, no muss. BloGTK has so many things in the toolbar that it is hard to find those three key items. Drivel’s options are in a menu instead of a toolbar like every other text tool on earth, though it gets points for supporting ctl+b/ctl+i/ctl+u. If there were a shortcut for hyperlink, I’d probably forgive the lack of icons :) Kblogger appears to lack this, from what I can tell in the screenshots. Wordpress’s built in editor is pretty slick, though the dependence on the browser to open a new window (a slow operation) for certain things is suboptimal. Also still cluttered, but not overly so.
Inline Formatting Monkey-journal (thanks to gtkhtml), wordpress (thanks to the browser), and gnome-blog get this right- if I hit bold, I should see bold text, not . Drivel and BloGTK don’t.

Support for categories. This is why I have to stop using my beloved gnome-blog, which is perfect on the previous two categories. Drivel, BloGTK, and KBlogger support this, but I get a list, not a multiple-select, which is suboptimal. So the web form is the only thing that gets this completely right, which sucks :/

Support for multiple blogs. Am going to occassionally blog on two work blogs soon, so I’d like multiple blogs. Again, gnome-blog (and AFAICT kblogger) fail here. Drivel appears to fail here, though I’m not quite sure on that count. BloGTK definitely succeeds here, though it would be nice to behave better (aka, not have a blog dropdown) when I only have one blog.

I think that’s it. Bottom line: nothing really satisfies :/ Wordpress is ironically probably the closest to what I want feature-wise, but the lag involved in using the browser just drives me out of my mind. I think for the moment I’m going to use Drivel, but BloGTK is close, as are gnome-blog and monkey-journal- each probably needs only a little bit of love to get things Just Right. :)