Notes on using Freedom to block digital distractions

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

I’ve been using 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.

Broader opens: on the relevance of cryptolaw for open lawyers

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


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:

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

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


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!

My teleconf setup

Several friends have asked about my camera/videoconferencing setup, so some notes on that.

Picture from my desktop camera. Lighting isn’t quite as even as I’d like (and as always in stills, my smile is goofy) but you can see the background blur clearly.


I’ve joked that for lawyers, a good videoconferencing setup is now like a good suit—sort of pointless but nevertheless can help make a good impression in a field where impressions, for better and for worse, matter.

I picked up the new book “Presenting Virtually” from Duarte and it starts with something that’s pretty basic, but also not always obvious—you can’t control networks, and often don’t control what presentation software you’re using. What you do control is your hardware, so make that the best you can.


I bought a Canon 77D to take baby pictures and… it was in a closet when the pandemic hit. I use it with a 24mm pancake lens. Canon provides a driver that lets you use the camera as a webcam.

Given the cost, I’m not sure this makes sense for most people to do unless they already have a compatible Canon laying around. But if you do have a supported one it works great!

As an alternative, friends speak very highly of this new Dell camera.


I cheat by having good natural light in my office and then supplementing it, rather than having to blast light all over to make up for the gap. This means my light was cheap; the primary criteria was being able to change the color (from a bright white to yellow-ish) so that things looked right.

The exact model I got is no longer available, but is basically similar to this one.

Pro tip for new-ish home workers: if you have two rooms, one dark and one bright, make your bedroom dark and cramped and your office big and light. The previous residents of our place made the reverse choice and I don’t understand it at all.


I have a Blue Yeti mic. I’m not sure I’d recommend it for most people. The audio quality is very good, but positioning it over a desk is finicky. (I use these for both my camera and mic, and they work once you get them set up, but they’re a pain.) In addition, it has a headphone jack—which is fine except it insists on reporting to the operating system that it is live even when it has nothing plugged in, so I frequently have to say “no, bad zoom, use the speakers that are actually speakers”.

If I were doing it over again, I’d get something designed more specifically for the home office use case. A friend swears by their Jabra 510, and this new thing from Logitech looks pretty interesting.

What I’m not doing (at least not yet)

I’m sorely tempted to get a teleprompter, but Stephen has mostly convinced me not to. In my experience, at this time, the bar is pretty low—having a good camera and light really does make things noticeably better for people on the other end, even if your eye contact isn’t perfect while doing a slide deck. So you can get a lot of bang for a lot less effort than Stephen spent. Still, tempting some days :)

Hope this is helpful!

A revised OSI “Open Source Licenses” page

When someone new to open source does a web search for “open source licenses”, the first page that comes up1 is – making it one of the most important resources for newcomers to open source.2

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

  1. other than an ad for, interestingly []
  2. 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 .com? other sites? Is there a tool that will do this sort of analysis automatically? []

Personal MPL acknowledgments

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.

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

A must-read on google

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.