Skip to content
This repository has been archived by the owner on Mar 25, 2018. It is now read-only.

RFC 004: licensing #7

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

RFC 004: licensing #7

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
aad3398
RFC 004: licensing
steveklabnik Jan 10, 2016
f659eda
Add alternative: all rights reserved
steveklabnik Jan 10, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions text/0004-licensing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# Licensing

intermezzOS will use “open source” licensing, rather than “free software”
licensing.

Specifically, the book will be under the CC0, and the code will be under
MIT/Apache 2.0.

## Details

There are two major forces: open source and free software. There are details
between the two, but the biggest comes from what ‘freedom’ means. The crux of
the choice is this:

> Should someone be allowed to create a closed-source version of intermezzOS?

Given the goals of intermezzOS, primarily, that learning resources should be
available as widely as possible, I believe the answer to this question is ‘yes’.

This is a slightly counter-intuitive conclusion. Wouldn’t forcing it to always
be open mean that things would be more open? In a certain sense, this might be
true, but it would restrict what students can do with this material, and that
makes me uneasy. Furthermore, the boot code is derived from @phil-opp’s, and
that’s currently licensed under MIT/Apache 2.0.

I personally tend to prefer free software, but am not religious about it. I
think that this project is significantly different from the projects that
make me prefer it, and so it’s worth using the more liberal license.

Furthermore, as a Rust project, most of the Rust world is using MIT/Apache 2.0.
Continuing in that tradition makes sense, and makes it easier to use IP across
the ecosystem.

## Drawbacks

If someone were to create a proprietary intermezzOS and make piles of cash off
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this allow someone to simply go to a publisher and say "please print this github repo" and then earn lots of $$$? That sounds unfair.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By being open source, this is already generally true. They must acknowledge where it's derived from, but other than that, it's okay.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or rather, right now, everything is 'all rights reserved', which is weird, because it means that strictly speaking, even forks aren't exactly legal?

Any open source license will open us up to this issue. Where the GDFL would kick in is this situation:

  1. someone forks the repo, makes proprietary changes, and publishes a book about it.

At this point, what happens diverges:

  1. Under this proposal, well, nothing.
  2. If we chose the GFDL, they would be required to give a copy of the source to anyone who purchased it from them, which those people are then also free to re-publish.

of it, I would be sad.

## Alternatives

We could make the opposite choice and choose the GPL + GFDL. This would require
relicensing the code, as well as licensing the book. And it may drive off some
potential contributors.

We could make everything still be “all rights reserved”, as it is now. This makes
some things very murky; is a fork unacceptable then? It’s also a bit inconsistent
to have open source code, but not an open source book, though people do do it.