How does / should copyright work here? Prose could default to the author, and have options for Creative Commons. But how does that mix with imported code with various licenses, and cells from other Observable docs?
This is covered in some detail in the terms of service, most specifically the license grant to other users in section 5. The gist of it is that by publishing a notebook, you agree to allow others to view, fork and import it into other notebooks.
Importantly, this license grant only applies to usage on Observable. If you want to allow people to use your code outside of Observable, say to copy-and-paste your code into their app, then you should associate a LICENSE with your notebook.
We haven’t yet established a standardized convention for declaring a license, but I’m imagining something like what you see on my Altered World notebook which uses MIT-licensed code by Gerard Ferrandez. It has a cell named
LICENSE whose value is an SPDX short identifier, and a comment containing the full license text.
Codepen has an interesting take:
In short: public Pens are MIT Licensed, private Pens are owned by you with no implicit license.
Good to know, I’ll avoid codepen now
@Fil I’m curious, what is it about CodePen’s policy that makes you want to avoid it?
Would CodePen be more appealing if they allowed users to choose any license for their public works?
This doesn’t seem to solve any problem except CodePen’s.
As an author: choosing what I do with my “creations” is one of the few freedoms I have. CodePen imposing its views is restricting that freedom. I guess it’s enough to say “bleh”.
As a consumer of code: As the license has been set by the platform, I’m not sure that the author is willingly licensing their code. For me, it voids the license:
- Morally, it might be the the author didn’t read the Terms and Condition, so I can’t know for sure they’ll be happy if I reuse their code with all these specific freedoms.
- Legally, I wouldn’t know… for example, maybe they copied it from somewhere else and didn’t notice they were “infringing”—just having some code that shows up with a default (non-deliberate) license attached does not guarantee that the contents is properly licensed.
Ah, here’s an example that might help to demonstrate the problem:
The code below is a rather straightforward implementation of Robert Gray’s “Exact Transformation Equations For Fuller’s World Map,” Cartographica , 32(3) (1995).
It is our pleasure to put it in the public domain.
I wrote this paragraph very specifically and deliberately so that it would solve a specific IP issue that was “forbidding” for this projection (because the code of Gray’s original implementation was explicitely non-free, I developed and shared a new implementation solely based on his scientific paper). Wouldn’t have been contradictory with the CodePen forced-licence scheme?
I think the correct approach is: each author (deliberately) selects their own license for each of their creations. The ToS are minimally engineered to allow the service to exist: the service is allowed to store the contents, show it to users, make backups, and so on.
That’s what most platforms do, and when they go beyond that, there’s often a backlash.
If the platform wants to give a general direction so that the service is more lively, friendly, communist etc, they can add affordances such as the possibility to select a default license for new creations, a menu with default licenses to choose from, etc.
In the case of Observable, there’s an added proviso in the ToS that other users are allowed to fork the contents if they have access to it (public or shared). This is important but arguably not vital for the service, and there might be some cases where it would be nice to be able to opt out.
Thank you so much @Fil for sharing your thoughts on this! Extremely insightful.
The act of forking and changing license turns out to be quite the rabbit hole.
I came across this today and it blew my mind, thought it might be of interest here:
Would be neat to visualize that graph in Observable!
The Wikipedia article has even more charts (CC licenses among them). I agree that a choose-a-license style wizard with compatibility filtering could be an interesting project. I’m also curious to see how aspects like library consumption (e.g. linking, API use) would be represented.
Good stuff! Updated my link to the page.
An interesting case study:
- This Observable notebook: d3.interpolateZoom by @Fil was ported to
- this CodeSandbox: react-d3-animation-with-hooks by @clhenrick.
In this case the original should have been licensed with “cc-by-sa-4.0”, as are the other docs I wrote for d3 on observable. Fixing it now. Thanks!
Good catch Curran, I didn’t notice the license file in codesandbox, nor that it defaults to MIT. I can attempt to change it to unlicensed if this is problematic.
Not sure that’s possible. You’ll either violate the original license or codesandbox.io’s terms. Your best bet might be to check if MIT is compatible with the CC license.
Edit: Actually, you’ll violate the terms regardless.
Speaking as the owner of the notebook in question (@fil’s D3 documentation effort was sponsored by Observable), I see no issue whatsoever with @clhenrick’s work. I’m not even sure I consider it “reuse” of the code in that notebook, given that it is a novel implementation; I see very little overlap between the two implementations, and any trivial duplication would not be copyrightable. I’m thrilled to see novel adaptations of D3 techniques being shared.
But putting that aside, if you have questions as to whether a particular usage is appropriate, I would ask that you contact the respective owner of the notebook rather than speculate here in the forums.
It was my impression that we’re trying to find some general guidelines beyond “ask the author to relicense”. Do you feel that this discussion has no place in Observable’s forum? Or are merely trying to avoid FUD and uneducated guesses?
Yep. I welcome discussion on, say, how Observable could formalize license specifications for notebooks, such as a
LICENSE cell versus metadata, and what either of those should look like.
My main concern in doing so is the licencing model of the code content within Observable. My current approach is clean-room reimplementation of everything from scratch, since most of the content in Observable seems to be “unlicensed” (meaning all rights reserved by the author, plus granting Observable users the right to fork & modify the work within Observable but not outside Observable). I’d guess clean-room reimplementation is what companies are doing as well, when they find some cool technique implemented inside Observable and want to use it in their product.
You could always try contacting a notebook author and asking them about licenses.
My impression is that most (but perhaps not all) authors who do not include an explicit license are still intending their code to be freely usable by others, and would be willing to slap an MIT-type license on, offer an explicit license to you, or at least discuss licensing the code.
clean-room reimplementation of everything from scratch
Clean-room re-implementation means that the person doing the re-implementation has never touched or looked at the original code. To do it up to the standards of corporate lawyers my understanding is that you’d want to get one person who looks at a notebook to write a spec, and then someone different (who has never visited the notebook in question, and learns no other information about it) to take that spec and make an implementation from it. Deep pocketed corporations worried about copyright infringement lawsuits but who need to e.g. implement some API for interoperability with some other deep-pocketed corporation’s proprietary product can afford to hire a team of engineers to do this kind of thing, even though it is generally pretty difficult and inefficient.
I am guessing you are not actually doing this.
If you are really worried about liability for copyright infringement then contacting the authors would probably be considerably safer than what I am guessing your current method is. (Disclaimer: I am not a lawyer or an expert in copyright law.)
I’d guess clean-room reimplementation is what companies are doing as well
Anecdotally many companies nowadays are in practice pretty sloppy about copyright infringement, and just copy/paste their way through problems and hope nobody ever notices.
Closing the loop here: we shipped support for licensing notebooks today. Feedback welcome.