Copyright and software licenses

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?

4 Likes

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.

5 Likes

Codepen has an interesting take:

In short: public Pens are MIT Licensed, private Pens are owned by you with no implicit license.

https://blog.codepen.io/legal/licensing/

Good to know, Iā€™ll avoid codepen now :slight_smile:

1 Like

@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?

1 Like

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.

7 Likes

Thank you so much @Fil for sharing your thoughts on this! Extremely insightful.

2 Likes

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!

4 Likes

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.

@curran Mind pointing your link directly to the page? :slight_smile:

2 Likes

Good stuff! Updated my link to the page.

An interesting case study:

The original is unlicensed. The port is MIT licensed.

1 Like

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!

2 Likes

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.

2 Likes

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.

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

1 Like

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.

2 Likes

Closing the loop here: we shipped support for licensing notebooks today. Feedback welcome.