Luis VillaRamblings on software, law, and the spaces in between.

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

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.

1. If you don’t like this, I suggest channeling your energy into writing a true cross-distro Linux build and installation process. [↩]

In the same vein as my earlier commentaries on Google comes this piece by James Grimmelman. He doesn’t comment on the actual substance of the net neutrality announcement. Instead he focuses on process, and his description of how google does things seem so dead on to me into how google that I think I’ll be citing repeatedly in the future. I won’t quote; it is worth reading the whole, fairly brief thing.

The one thing I’d add to what James says is that Google’s process actually usually works quite well; for every Wave, Buzz, and verizon deal, there are several things that work well. When it works poorly, we should generally allow the market to discipline them, as it has with Wave. The reason the net neutrality issue is so important is that it could represent a new barrier to entry, making those market mechanisms less effective and leaving us more at google’s mercy when their processes go bad in the way James describes.

It is extremely satisfying when you can see your work turn directly into a working product. I just played with last night’s test version of firefox, and as per roc’s blog post, it indeed contains the video support whose licensing I (and others here) were working on last week. In an ideal world, lawyers should play a very small role in product development, and in this case we were probably involved more than anyone wanted us to be. But that wasn’t to be, so I am proud I helped get it done, and done right, and that all firefox users will benefit from it in the future.

Hello Cambridge-based lazyweb! I am looking at network Acceptable Use Policies (AUP) for guest wifi networks, and I have been told that MIT’s AUP for their guest wifi network is particularly terrific- short, simple, etc. Can someone in Cambridge who happens to stumble by MIT check into the network and copy/paste the text and email me? I’d owe you a beer next time I’m in the Commonwealth. Thanks!

[edit later: it appears that MIT has removed the acceptable use policy from their guest wireless network. I applaud them for it. Thanks to the couple of people who tried to get me the AUP only to find that it is no longer required!]

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?

“We are working well when we use ourselves as the fellow creatures of the plants, animals, materials, and other people we are working with. Such work is unifying, healing. It brings us home from pride and from despair, and places us responsibly within the human estate. It defines us as we are: not too good to work with our bodies, but too good to work poorly or joylessly or selfishly or alone.” –Wendell Berry, The Unsettling of America

“The strongest “copyleft” … is having a vibrant and active community” –Shaver, of shaverfacts fame, in mozilla.governance

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

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.

1. One of the many, many ways in which software patents are broooooooken. [↩]

I’d love a thunderbird plugin (or really just a feature) that says “you were bcc’d on this email- are you sure you want to reply to all and accidentally disclose that you were bcc’d?”

(And yes, of course that means I did that today- pretty sure the first time in a very long career of email that I’ve done that. Doh.)