Older blog entries for louie (starting at number 658)

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.

Syndicated 2011-08-22 14:02:01 from Luis Villa » Blog Posts

Donated to the Ada Initiative

I’m excited to say that (with Krissa’s support and approval) I donated today to the Ada Initiative’s Seed 100 Campaign.

The Ada Initiative Seed 100 campaign: donate in June to support women in open technology and cultureFree 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.

Syndicated 2011-06-23 02:33:45 from Luis Villa » Blog Posts

Regular internet detox tips?

Over the past few years I’ve heard a few friends talk about plans to get off the internet for one day a weekend, one weekend a month, etc. Each of the past two years I’ve tried to take 3-4 days off the internet, and both times it has been rejuvenating- I come back feeling pretty invigorated, focused, etc. But that feeling didn’t last too long last year and I doubt it will this year.

Small waterfall on the side of a trail off Skyline Drive, Virginia, May 2011

 

 

So … do any friends who have tried similar things have tips or thoughts on how to do an internet detox on a more regular basis and actually make it both effective and sustainable? I imagine that the “make it sustainable” part inevitably involves advice on how to handle email, work, twitter, etc. while you’re gone. Twitter and greader I’m actually pretty good with just “mark it read and move on” but that’s much harder with email for me.

Syndicated 2011-05-13 19:28:29 from Luis Villa » Blog Posts

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?

Syndicated 2011-04-17 16:43:47 from Luis Villa » Blog Posts

Brilliant.

Saw this for the first time on my drive to work yesterday:

Not every venture is about capital, by Fligtar, used under CC-BY-NC-SA

Congrats to all my friends on a very solid release and on reinvigorating their important message of public service.

Syndicated 2011-04-01 14:57:57 from Luis Villa » Blog Posts

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

Syndicated 2011-03-31 13:42:17 from Luis Villa » Blog Posts

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.

Syndicated 2011-03-25 04:31:13 from Luis Villa » Blog Posts

Other Ways to Slice Revenue Pies

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

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.

Syndicated 2011-02-28 06:25:41 from Luis Villa » Blog Posts

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.

Syndicated 2011-01-07 04:01:00 from Luis Villa » Blog Posts

offline no-keyboard rss reader?

So… I’m in the market for a way to read RSS feeds offline, with no keyboard; i.e., some sort of tablet or kindle-like device. Ideally it should be cheap and reliable (reliable in the sense that I can pick it up every morning while still groggy, take it to a concrete bunker with no wifi, and fully expect that I will have 45-60 minutes worth of reading on it- something should download feeds overnight without me thinking much about it after initial setup. ) Other features (ebooks, app stores, what have you) are a plus but not necessary. Ideally would sync with Google Reader, but am willing to compromise on that.

Options I’m looking at right now:

  • wifi-only ipad + reeder: $499+$5. Biggest downside: Apple. Also size: not sure that my intended use case will really work well with the weight of the iPad.
  • Samsung Galaxy Tab + google reader app: $599 + free. Downsides: $100 more than ipad + 3″ less screen + OS everyone admits is not ready for tablets. Will make me less likely to buy an actually good 2nd gen Android tablet. Upside: Google Reader app looks solid; Android is (relatively) the Good Guys in this OS battle.
  • nook ($149/$249) or kindle ($139): would be ideal-ish (less weight, more readability), except I don’t see any great rss reading options. Any suggestions on that?

Are there other options I’m missing? Less popular/more hackable e-reader devices? Other tools?

Some things that aren’t options:

  • phone: I read a lot on my phone already, I don’t want to add to that and screw up my eyes even more.
  • instapaper -> (kindle|ipad): instapaper is slick, but to go through a lot of feeds quickly, not a handful of lovingly pre-selected content slowly.

Thanks in advance, oh broad intarwebs…

Syndicated 2010-12-08 04:59:39 from Luis Villa » Blog Posts

649 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!