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:
From Janelia Farm FlyEM Project: Open Source Licenses and their Compatibility.
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.
The original is unlicensed. The port is MIT licensed.
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.
Iām interested in porting techniques en-masse out of Observable and into Open Source, MIT Licensed plain vanilla JavaScript code, to overcome some of these limitations.
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.