jashkenas

The site is up, but is brand new and still in beta — what mobile OS/Browser combo are you using? We'd love to try and debug your white screen...

That's a fantastic question.

It's not ready yet, but we're hoping to roll out import pinning for notebooks soon.

Each notebook is versioned — every time you make a change and re-run the cell, a version is saved to the server. And every time you publish, that's a publication of a specific version of the notebook.

Our plan is to pin the version of any code you import from outside the notebook, including require(npm-module), import {value} from "other-notebook", and even the version of the Observable standard library that was current when you wrote the notebook.

Hopefully, that should provide a good foundation for robust notebooks that don't break as libraries change over time. Of course, you'll be able to re-pin a new version if you want to upgrade something.

Yes, something like that is in the roadmap.

We’ve been scrambling to get things ready enough for this initial launch, but Mike managed to get the Standard Library open sourced this morning: https://github.com/observablehq/notebook-stdlib

One of the next pieces we'd like to open-source is the Notebook Runtime — All of the JS that you need to take a blank webpage, and host a notebook within it.

After that, there's some file format details to figure out — hopefully a notebook can just be published and consumed as a standard ES Module. But then we'll be most of the way there.

Before this post fades from the front page, I just wanted to take a moment to link to some of the things folks have been publishing this morning:

Nick Strayer shows how t-SNE is similar (equivalent?) to a force-directed graph layout: https://beta.observablehq.com/@nstrayer/physics-based-t-sne

Jim Bumgardner published a tutorial that starts with drawing circles with canvas, then fibonacci spirals, then colorful sunflower seeds: https://beta.observablehq.com/@jbum/circles-spirals-and-sunf...

Kamil Slowikowski drew a lovely Barnsley Fern: https://beta.observablehq.com/@slowkow/barnsley-fern

Alan Palazzolo did a Mandelbrot fractal with randomized coloring: https://beta.observablehq.com/@zzolo/mandlebrot-set

Justin Palmer uses PROJ4JS to transform and scale a local map: https://beta.observablehq.com/@caged/local-map-projection-wi...

Yes, and single interactive cells as well.

A notebook already runs in a sandboxed iframe, and is able to load its dependencies there (libraries, data, values from other notebooks). So we're in quite good shape to be able to do that soon.

Right, we didn't have the URL yet last night. Thanks! Fixed.

Yes. We use <iframe>s with the sandbox attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...) to uh ... sandbox away the running JavaScript.

If you inspect them, you'll see that those frames are hosted on observableusercontent.com instead of observablehq.com.

It's a similar security model to how raw files on GitHub are served from githubusercontent.com.

Yes, it's absolutely worth exploring further — and we definitely have notions for ways to further expose and make interactive the running state of the notebook.

But for starters: You can do something similar to expose the internal state of loops and flow-control constructs by just using JavaScript's generators.

Here's an extremely simple example that slowly yields the value of a loop's `i` variable:

https://beta.observablehq.com/@jashkenas/flow-control-demo-w...

If you remove the delay, it'll instead yield `i` at 60fps.

I'm afraid that we're running into a database error at the moment. We're on it...

Edit 1: Deploying the fix now...

Edit 2: ... and we're back.

I would have loved something like this while learning to program as well. I mean ... the Ruby REPL was fun, but this sort of thing is just so much more tactile and visual.

We haven't had time to produce as many demo notebooks as we might have liked, but these notebooks really aren't D3-specific in the slightest. They're a reactive flavor of JavaScript, and anything that produces a value or can be rendered to the DOM will work.

For example, here are a whole mess of Plotly charts: https://beta.observablehq.com/@jashkenas/plotly-js

Here are some (wild) WebGL, Three.js and regl sketches: https://beta.observablehq.com/collection/webgl

And here are some simple native inputs you can use to control your sketches: https://beta.observablehq.com/@jashkenas/inputs

Remember — a "slider" here isn't anything special. It's just a chunk of DOM that produces a number as a value. It can be replaced with anything else you can imagine that produces a number as a value. There's no API there ;)

And good place to drop few links, if you'd like to cut to the chase.

The finished notebook from the screencast (which you can fork): https://beta.observablehq.com/@jashkenas/earthquakes

And a fancier version that spins, reuses the canvas element instead of re-rendering it from scratch, projects the quakes as circles on the surface of the sphere, and offers a bunch of other options to configure (like if you'd like to chart the past day, week or month of quakes): https://beta.observablehq.com/@jashkenas/quakespotter-0-1

A little emphasis, focusing on the aftermath from the SEC's July report on the DAO:

> "Following the issuance of the 21(a) Report, certain market professionals have attempted to highlight utility characteristics of their proposed initial coin offerings in an effort to claim that their proposed tokens or coins are not securities. Many of these assertions appear to elevate form over substance. Merely calling a token a “utility” token or structuring it to provide some utility does not prevent the token from being a security."

Let's keep digging in!

1. I feel entirely the opposite way about the appeal of an MIT-style license that includes a patent grant. It's not primarily about making the author feel comfortable — as the author probably doesn't have patents, and doesn't intend to. It's about giving the user of the software confidence. Because the user has no idea what patents the author may or may not hold. At this moment, this is playing out to dramatic effect in Facebook's open source projects — you can see an example here: https://github.com/facebook/graphql/issues/351

Being able to give users of my software fuller confidence under the Lil License also makes me more interested in using it as an author. It's a virtuous cycle.

2. I'm afraid I still don't quite see the issue you're describing here. If I'm following correctly, the hypothetical case is a contributor who writes a bit of code that exercises a patent that she has a license to, but not permission to sublicense, and then wants to submit that code to an LIL-licensed project. If she's not allowed to sublicense, then she can't contribute that code. She wouldn't be able to contribute it to an Apache project either.

3. It might be. I think that its width is more suitable for most open source projects than the narrower Apache and MPL, but that's something that would make for a good discussion. I'll open a ticket.

4. Again, we're talking past each other a bit. This isn't really trying to appeal to the Facebooks of the world — it's trying to appeal to us regular folk. That I might be able to convince people without patents to use the license is not irrelevant, it's exactly the point. Those people are the target audience. From a user's point of view, the patent grant is still important — because I never know for certain when an author may or may not hold a patent on the code.

5. If I grant you usage rights to a patent, I grant you a license to make, use, sell, import and otherwise transfer implementations of the invention described in that patent. If you think we need to spell out all of those words explicitly, perhaps throwing in "have made" and "offer to sell" as well, feel free to open a ticket and we'll talk about it further.

I can't help you out with a history of lawsuits to cover damages from faulty open source software, but here's a great little link to explain the legal reasoning for the need for the disclaimer:

https://oss.kemitchell.com/#contract-law

Quickie TL/DR; OSS is ultimately a product offered under a license. Without a warranty disclaimer, if the code proved to be shoddy, unfit for use, buggy, or crashed and damaged your business — you would have the ability to sue: I offered you a product that claimed to do be able to do a thing, and it didn't.

Right — I think this is the central point I'm trying to make:

If you want a license where every noun in the license is rigorously defined at the top, where every possible use of the software is spelled out explicitly, and where every eventuality is considered in advance, then the Lil License isn't for you. It's not supposed to be. We already have Apache 2.0 and MPL 2.0 for that, and they're great. Use 'em.

Instead, the goal here is to cover the bases we know we need to cover in 2017 (contributions and patents), while remaining as simple as or simpler than MIT — which is the license that everyone actually uses. It's a different goal.

Thanks for the list of concerns, it's very much appreciated. If you care enough to open any of them up as an issue on Github, it would be great to discuss them there. But for now, in short:

1. Yes. If you actually own a patent portfolio that you value highly, you may want to use a custom, narrowly worded grant. This license might not be for you. This license is for the 50+% of open source projects currently using MIT.

2. I don't quite follow the problem you're outlining here. The Apache license tries to scope its patent license only to actions that "necessarily infringe" on the Work and the Contributions to it. I'm not sure how you mean for (sub)licensing to fit in.

3. The patent grant is intentionally simpler and broader than, say, Apache. There's no clawback provision, and in short, it gives you: "usage rights to any patents the authors may hold on the software." It doesn't give you the right to use the authors' unrelated patents. The balance here is struck to give more protection and confidence to the user of the open source, not to rigidly protect the potential software patent holder. I think that's the right way to lean.

4. This rhetoric around offensive and defensive uses of software patents is what's keeping Facebook in such hot water with GraphQL and React right now. The only way to use a software patent against someone is offensively — it's a MAD-style threat of legal action. If you want mutually assured patent annihilation, then don't use LIL to release open-source software that uses your patents. It's not a great mix.

5. In US patent law, you can sell your patent, prevent other people from making use of it, or license usage rights to it. The latter is what we're doing in this case. (https://www.legalzoom.com/articles/selling-your-patent-what-...)

6. That is a great question. And it would be good to eventually have a wiki page, detailing compatibility with various alternative popular licenses. As a permissive license (more permissive than Apache), my best guess is that it would be generally compatible — but we should look into it further.

  > Person as in what, a natural person?

Person as in a legal person. This includes entities like corporations, organizations, representatives and so on: http://legal-dictionary.thefreedictionary.com/person

  > but it doesn't cover anything about patents used by contributors...

It tries to. Any change contributed to the project grants permission to incorporate that change under the same terms of the license, which includes the patent grant. This is how people generally tend to behave with open source.

  > May? That [...] should really be changed to [...] will

I also considered "will" and "shall" and "grants permission to" and a few other options, but "may" fits most precisely and succinctly. Submitted contributions aren't necessarily going to be merged into the project, but they may be, and if they are, the act of submission back to the project grants permission to incorporate them under the same terms of the license.

http://legal-dictionary.thefreedictionary.com/may

The intent is to provide users of the software with full confidence that by using the software, they will not be held liable for infringing on the patents that the authors of and contributors to the software might hold on the software.

Other licenses, like Apache, include patent grant withdrawal clauses, where you can lose the right to use the patent if you initiate a lawsuit.

The notorious Facebook BSD+PATENTS license includes a similar withdrawal of patent grant, but for any Facebook patent, not just something related to the software in question, and also only if you sue Facebook or a subsidiary — the Apache withdrawal applies to "any entity".

Here, there are no withdrawal provisions, hopefully giving you that full confidence as a user. As an author, if you have a patent on something, and then you release an open source project under LIL that uses that patent, you give up the right to sue anyone for infringing on your patent by using your open source project, period.

I think that's more in the spirit of open source.

Let's do it. I think it's mostly a matter of picking not just a qualified lawyer, but one of the best possible lawyers for the job: ideally, someone well known who has dealt with OSS licenses and lawsuits in the past.

I've opened a ticket for it: https://github.com/jashkenas/lil-license/issues/3

Thanks for the thoughts. I considered those two issues in the drafting — revocability, and contributor submission licensing — but they can certainly be discussed further.

Do you mind opening a ticket on the Github repo to discuss them? (If you don't have time, I might do it.)

Thanks for the suggestion. I was trying to be friendly with the tone of the FAQ. Perhaps too friendly. I'll try to make the drafting process more clear.

Thanks for the correction. I've made the change in the FAQ to not describe License Zero as an open source license. On its own website, it's very careful not to.

The argument against is that someone who then encounters the code without the notice will have no idea what license the code is under. They won't be aware of the BSD rights and disclaimers that otherwise should apply to them.

What we do here instead is explicitly say that you can include the Lil License text, or link to it instead — as we tend to do in these modern times.

It may be pretty powerful, but I'm uncomfortable believing that it really should be. For starters, every lawyer has a different opinion, a different style of preferred phrasing, and a different understanding of what open source software is. Ultimately the parties involved are you, your users and your contributors. Most of us don't have lawyers.

That said, I think it might be effective to put some short legal opinions, from experts in this particular field, into the FAQ. If anyone's listening: that would make for a great pull request.

The goal here is to make this thing as shipshape, watertight and bulletproof as possible, while remaining "simpler than MIT". Then it becomes the license I would have always wanted to use.

A couple of lawyers looked at it — but of course, their opinions varied. None took issue with the normally-cased warranty disclaimer.

But I certainly did think about it before using lowercase. The reasoning is this: The Uniform Commercial Code requires language opting out of implied warranties to be "conspicuous". In short, you can't bury the warranty disclaimer in the fine print. In a dozen-page long plain text license, putting the disclaimer in all caps might be a way to try and make it conspicuous. I enjoy Kyle Mitchell's take on this:

"Lawyers have long suffered under the delusion that writing anything in ALL-CAPS meets the conspicuous requirement. That isn’t true. Courts have criticized the Bar for pretending as much, and most everyone agrees all-caps does more to discourage reading than compel it."

In the Lil License, the warranty disclaimer is in normal type because the license is short, and it's meant to be read. It's a conspicuous part of the license. You noticed it right away ;)

Github is fairly aggressive these days about alerting you to put a standard license in your repository.

But they still remain with the problem that most folks choose the user-friendly MIT (I would, and 9 out of 10 of the top projects do). This leaves them with an issue: It's not clear that contributions submitted to an MIT project grant permission to incorporate those contributions under the same terms. We understand it socially, but it's not legally explicit.

Github has been trying to address this in their Terms of Service, by saying that simply by using the site, you agree that "inbound=outbound": https://help.github.com/articles/github-terms-of-service/#6-...

But the Github TOS isn't really the right place to be legislating that. For more, see: https://writing.kemitchell.com/2017/02/16/Against-Legislatin...

I love ISC — but you're quite on point. It also says nothing about any patents potentially held by the authors.

See this HN comment from a year ago for a fuller exploration of how that can be problematic: https://news.ycombinator.com/item?id=12597488

Friends, I totally get the initial instinct to think "Aieeee! Not another amateur open source software license! Those things breed like flies!"

But if you wouldn't mind taking two minutes to read the text of the license before giving in to that feeling — I think you'll find that it might put you more at ease than what you're currently using — if you're using MIT.

Like MIT and ISC, it's short and sweet and comprehensible, and like Apache it tries to establish common standards around potential patent use and contributions back to the codebase. It hits a sweet spot that, for me, doesn't exist in anything currently on the OSI's long list of licenses.

I did run it by a couple of lawyers and a couple of open source developers before publishing it this morning. But I don't believe that review should matter too much to you: An OSS license is an agreement between the author and the user of the software. If they can both easily understand it to mean the same thing, then we can feel that we're on solid ground. That's why we use MIT today.

Totally. And if it's a terrible idea, then it will die a quiet death, and that will be fine. But there's a little more here than just "don't try this at home."

The Apache license is a wonderful license. If you want to use it, you absolutely should use it.

But people don't use it. They prefer to use something they can understand, something that doesn't have to be interpreted by a legal team, and something that they can feel comfortable imposing on the users of their code.

According to a 2015 survey conducted by Github, MIT and BSD simple licenses are nearly five times more often used than Apache. Out of the top ten most starred open source projects, nine of them use MIT/BSD, and only one uses Apache.

Clearly, there's a desire — in the actual practice of sharing open source — for something that explains your legal and social obligations in as plain an English as we can muster, while still being crystal clear in legal terms.

That may be true, but with that attitude, we'll all still be using MIT in 2047.

The hope here is for it to become a standard license in short order, if people find it useful. That includes SPDX submission, OSI approval, and then inclusion in Github's licensing apparatus.

Specifically, I'd like to think that corporations would find it significantly more comfortable to use software under LIL than under MIT: They won't have to worry as much about unknown patents held by the authors, and they won't have to worry about future legal disputes with third-party contributors. Both of those are significant issues today — this very week, even.

That said, if you want something permissive, but lawyered-up and bulletproof, use Apache. This isn't intended to compete with Apache. It's intended to compete with what folks actually use and love, which is MIT.