licensing


2
Feb 12

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

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

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

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

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

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

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


24
Jan 12

Nominated for OpenSource.com People’s Choice Award

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


22
Aug 11

Making HTML Legal Documents (Like MPL) Look Good

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 timeis, 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 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). 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.
  • 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.


17
Apr 11

looking for a programming analogy- if there is one

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?


31
Mar 11

MPL Beta 2- as FAQ

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

FAQ, by photosteve101/planetofsuccess.com, used under CC-BY

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!]


24
Mar 11

Joining W3C PSIG as an Invited Expert

Just a note to say that I’ve been invited to join the W3C‘s Patents and Standards Interest Group as an Invited Expert. I’m pretty pleased by this and am looking forward to contributing immediately. Invited Experts speak for themselves, not other organizations, so I will not be representing Mozilla or anyone else, but hopefully I’ll be able to add something to the discussion on my own and help move W3C and the open web forward.


25
Mar 10

patent 101

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


11
Mar 10

Updating the MPL

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

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.


29
Apr 09

me on gizmodo on the realDVD case

Gizmodo says in a post today:

Testing the waters with a low-stakes product isn’t a bad idea in itself, but RealDVD is the wrong low-stakes product for the job. Real claims that Facet copies DVDs to an internal HDD, but offers absolutely no means by which these files could be shared—they’re DRMed, disconnected from the outside world a locked in an actual box. RealDVD, on the other hand, copies films to your PC’s drive and wraps them in iTunes-style DRM, which allows playback on up to five machines. That opens opens a piracy angle for the MPAA—one that could conceivably swing the case in their favor, killing RealDVD and precluding production of Facet for reasons that don’t even apply to it.

On some instinctive level, I see where Gizmodo is coming from here. You never want to give courts a reason to dislike you when you’re walking in their doors, and ‘piracy’ is certainly going to make courts a little skeptical, even if the ‘piracy’ is of a very limited sort that hundreds of millions engage in every time they use their ipod.

At the same time, once you look at it a little more deeply, RealDVD is probably a perfectly fine case for Facet- two big features of the law at issue make it very unlikely that the courts would decide any differently for one product or the other. They sink or swim together.

First, Real is very wisely making very loud noises about the chilling effects on product innovation that the DMCA has here. Since Sony, courts have been told to be very concerned about this issue, and generally, they have been. Even in Grokster, where the Supreme Court absolutely creamed Grokster, the justices were very careful to say that they didn’t want to discourage all innovation- only innovation that was imagined, implemented, and marketed as piracy gear. So Real is getting off on the right foot- focusing on personal use and innovation.

More importantly, the law in this particular case makes it clear that piracy doesn’t matter- so the (relatively) subtle difference between what the two Real products do after the copy takes place aren’t something the court should pay much attention to. There are two relevant sections of the DMCA:

17 USC 1201(a)(1)(A) No person shall circumvent a technological measure that effectively controls access to a work protected under [the copyright act].

17 USC 1201(a)(2) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that … (B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title;

Take a quick read of that first part. If you “circumvent” a “technological measure”, the law as written doesn’t care if you’re doing it to ‘pirate’ or to find the author’s email address so you can send him a billion dollars. You’ve violated the DMCA, period. So both Real products are essentially the same – from the perspective of the law – on this score. The second restriction is similar- it is illegal to sell a system whose core reason for being is focused around DMCA violation. We don’t ask what the non-circumventing functionality is (does it use the copies to club baby seals or save orphans?). We only ask whether it has ‘limited commercially significant purpose’ other than the ‘circumvention.’ Again, the Real products, while different from a consumer (and maybe PR) perspective, violate (or don’t violate) the law in roughly the same way.

Given the importance of innovation, and the irrelevance of piracy to the DMCA, this is probably a perfectly fine test case- maybe not ideal, but as good as they are going to get given the flaws in the law they are trying to get around.


19
Apr 09

all the cool kids are writing about the google book search settlement

Samuelson

Picker

Grimmelman

Perhaps some day before the case settles I’ll actually be able to read them all. In the meantime linking here so that I can find them all later.


This work by Luis Villa is licensed under a Creative Commons Attribution-ShareAlike 3.0 United States.