law


17
Mar 12

On the Importance of Per-File License Information

After the release of MPL 2, the first request for MPL 2.1 came from someone who didn’t want to put copyright headers in individual files. The issue has recently reared its head in Apache as well, and I recently was asked related questions by a GPL user as well.

The main reasons given for not using per-file headers are two-fold:

  1. They’re awkward in short files. Many programming frameworks these days (most notably rails) are encouraging creation of many short files, so this is becoming a bigger problem than it was when per-file headers were first created.
  2. They’re not considered very relevant in languages or frameworks that are library-centric, especially those with package managers that are heavily used (like ruby’s gems). Again, many modern language frameworks include tooling that encourages this approach, so some developers are thinking “why can’t I just express the license once per library?”

The case for per-file copyright headers is put well, and succinctly, by Larry Rosen:

“[O]ur goal is to pass on any important IP information that might be useful … in the place(s) [downstream licensees] are most likely to find it.”

Larry’s comment makes two assumptions that I want to flesh out and support.

First, Larry assumes that the place where people are “most likely to find” licensing information is in per-file headers. It is true that in the best case scenario in many modern languages/frameworks, library-level is a great place to put licenses – in normal use, they’ll get seen and understood. But lots of coding in the wild is not “normal use.” I review a lot of different codebases these days, and files get separated from their parent projects and directories all the time. And then you have to use fairly complex (and often expensive) tools to do what should be a simple task- figure out what the license is. So, yes, modern frameworks should in theory reduce the need for per-file licensing information – but in practice, that is often not the case.

Second, Larry assumes that you actually want people to use your code. Lots of publishers of open source code seem surprisingly unconcerned by this, unfortunately. The functional, practical benefits of open source all start with someone else reusing your code, so if you’re publishing open source code at all, you should be concerned about making it easy for people to use the code you publish. Again, putting licensing information in each file can help make this easier, by making it easier for people to figure out their rights and responsibilities. (This is particularly true if you want commercial uptake, since so many commercial users of open source are getting more conservative about using source code that is not properly labeled and licensed.)((Larry also perhaps assumes you want people to respect your license when using your code; that is a surprisingly complex topic that I will try to address some other day.))

So, yes: if you want people to find your licensing information, and  to use your code, per-file headers are the way to go. They may not be ideal but they really are worth the effort.


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.


6
Jan 11

Changing Jobs

Today was my last day as an employee of the Mozilla Corporation. I’m leaving to work at the law firm of Greenberg, Traurig. This was not an easy decision for me to make, but I’m pretty sure that it is the right one, both for me and for Mozilla.

Why?

Mozilla has been terrific for me. Working with happy, dedicated, passionate people is always a joy, and I’ve learned a ton from my teammates in legal and from Mitchell. I particularly can’t say enough good things about my boss, Harvey- he’s been a tremendous mentor to me. And of course Mozilla is exactly the kind of job I went to law school to get- directly helping hackers ship world-class software. Leaving today was hard- I’ll miss my coworkers, and I realized over the past few days that some of them may even miss me ;)

So why am I leaving? It’s because I want to continue to improve as a lawyer, and for a variety of reasons, the time-tested route for that is through a law firm. I’ve been learning a lot at Mozilla, but I will have even more opportunities to gain experience and improve my skills at Greenberg. Eventually, this will make me a better lawyer for any client I will have in the future.

What does this mean for the MPL?

We will still ship the new MPL in a reasonably short time frame, for two reasons. First, we’re almost done- go check out the beta, and/or read lwn’s solid article on the process. Second, our primary outside counsel on the project (Heather Meeker) will be my new boss at Greenberg. Both Heather and I are deeply invested in the new MPL, and we want to see it done (and done right!). So we will continue to work with Harvey and Mitchell to complete the new license, and my new address won’t change our focus or the license’s priorities.

What does this mean for this blog?

The blog has been quiet-ish in the past year, and will likely remain so, with more of a focus on personal life and technical questions than legal questions. This isn’t because Greenberg has put any pressure on me, but because I expect to have less time to write, and because some of the lawyerly virtues I’m working on are discretion and brevity… neither of which work together too well with the blog :) But hopefully I’ll still have interesting things to say from time to time.

Contacting Me

As usual, if you’ve got any questions – particularly about the MPL – let me know. My new email address will be [click here]@gtlaw.com, and my personal email address ([click here]@tieguy.org) will continue to work too.


15
Jul 10

100 Words for my Friends Taking the Bar Exam

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.


30
Jun 10

Some Followup Thoughts on Bilski

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:

  1. 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.)
  2. 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.
  3. 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.


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