Normalise licensing for projects in the IndieWeb GitHub org.

[Zegnat]

I am opening this issue here because there is no other centralised repository for organisation issues. (Asked about this on IRC.)

---

Below is a table of all 28 current repositories in the IndieWeb GitHub organisation, the licence they are made available under, and links to issues that were opened because of the licensing.

Many of those issues were opened by @marclaporte on several of the Apache licensed PHP projects is because he ran into trouble including these libraries in other projects. He suggests re-licensing or dual-licensing the respective repositories with MIT, so it would allow him to include these libraries. Through @sebsel I found the issue on indieweb/php-comments and asked why not make the move to CC0?

I would like to use this as a central issue to discuss wether it would be worth it to move all code in the IndieWeb GitHub organisation to the same licensing.

Personally, I would like to see a dual-licensed configuration of CC0 1.0 Universal and MIT. Why dual-license something that gets pledged to the public domain? Because some countries may not allow perpetualy signing away rights. Offering companies the easy out with a secondary licence might be the best thing to do, a bit like SQLite selling licences (read their reasons for obtaining a licence).

There is an important precedent for the move to CC0 on the php-mf2 repository.

What are people’s opinions on this?

---

Repo	Licence	Licensing issues
IndieWeb Week Website	CC0 1.0 Universal‡
IndieAuth Client	Apache License, Version 2.0 + MIT	#9
php-mf2	CC0 1.0 Universal	#76
WordPress IndieWeb	MIT
link-rel-parser-php	Apache License, Version 2.0	#5
Comments Presentation	Apache License, Version 2.0	#13
verify-me	Apache License, Version 2.0
Webmention Client (PHP)	Apache License, Version 2.0 + MIT	#30
chat.indieweb.org	Apache License, Version 2.0
Webmention Client (Ruby)	Apache License, Version 2.0
IndieWebify.me	none
2016.indieweb.org	none
This Week in the IndieWeb	Apache License, Version 2.0
blank-gh-site	none
rel-me	MIT*
Microformats2 (ruby)	CC0 1.0 Universal
indieweb.org	CC0 1.0 Universal
Indie Web Camp branding	CC0 1.0 Universal
php-mf2-shim	BSD 3-Clause License†
LinkRelParser (Ruby)	CC0 1.0 Universal
Representative H-Card Parsing	Apache License, Version 2.0	#1
Date Formatter	Apache License, Version 2.0	#6
php-original-post-discovery	MIT
wiki	Unlicense
jf2 validator	Apache License, Version 2.0
IndieWebCamp Assets	none
mynameisme.org	none
newBase60py	CC0 1.0 Universal

*: The licence had to be taken from composer.json. †: Guessing 3-Clause, did not do a full text comparison. ‡: The repo is available under CC0, but all contributions are dual-licensed CC0 and OWFa 1.0.

Notes:

• php-mf2-shim talks mentions MIT in its composer.json but provides the BSD licence.

[marclaporte]

Hi Martijn!

Thank you for preparing this.

I agree it would be better to have a recommended license for all IndieWeb (sub)-projects.

If / once this license is agreed upon, we could ask all contributors to agree to this for new contributions. And then, we can take the time to go back to all previous contributors to ask if they can agree to the new license. This takes time, so the sooner we start, the better.

As a reference, here is the saga of the license change for Bootstrap: https://github.com/twbs/bootstrap/issues/2054

Best regards,

[tantek]

I'd lean toward CC0 since that's consistent with the wiki(s) (including microformats.org), and could live with dual licensing with MIT since that seems to add something for some folks?

One nice feature of the CC0 / wiki-compat is that code / examples can be freely copy/pasted from the indieweb repos vs the wikis without worry.

[Zegnat]

One nice feature of the CC0 / wiki-compat is that code / examples can be freely copy/pasted from the indieweb repos vs the wikis without worry.

That’s definitely an important point :+1:

Also, as I thought about this during chat and not when I was writing the issue above: it would be good to decide on the texts of LICENSE.md and CONTRIBUTING.md before opening requests on the other repos. Basically “a template to copy” (— tantek).

[petermolnar]

This might come handy as simple comparison between the most common licenses: https://choosealicense.com/licenses/ Unfortunately it excludes CC.

[dg01d]

Looking over the table, it appears that the Apache License 2.0 is the most popular. Moving from that to MIT would mean losing the "Patent Protection" clause of the ALv2.0:

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Its important to understand that this isn't a case of just changing some words - these are issues that people may have a fundamental belief in.

In respect of the possible dual-licensing of the indieweb content under CC0 & MIT, there might be some issues with this approach. CC0 expressly does not grant patent rights:

No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.

Obviously the MIT License predates software patents, so does not address the issue. The problem may arise in that a court, when reviewing a matter involving code rights might look to the alternative license for guidance on the question of patents - in that case, they could reasonably assume that patent rights were not granted.

[Zegnat]

This might come handy as simple comparison between the most common licenses: https://choosealicense.com/licenses/ Unfortunately it excludes CC.

Creative Commons (and thus CC0) is explicitly only listed under Non-Software Licenses by choosealicense.com. But as per the CC0 FAQ, it is fine to use CC0 for software even when other Creative Commons licences should not be used.

choosealicense.com seems to prefer Unlicense for the Public Domain dedication. While both Unlicense and CC0 are seen as “free software licenses” by the FSF, they recommend the latter:

If you want to release your work to the public domain, we recommend you use CC0. CC0 also provides a public domain dedication with a fallback license, and is more thorough and mature than the Unlicense.

Looking over the table, it appears that the Apache License 2.0 is the most popular. Moving from that to MIT would mean losing the "Patent Protection" clause of the ALv2.0

Note that the main idea is moving to CC0, not MIT. Both to match the wiki and just to generally allow anyone to do anything with IndieWeb code.

The only reason I bring up MIT is because waiving all rights and dedicating something to the public domain is hard. It might even be impossible in some jurisdictions. And while CC0 tries to fix this by also being a licence next to being a waiver, people might feel more at ease if they can opt for a more accepted minimal licence. This might also be essential for people in countries like Norway, where copyright to public domain works goes to the state and certain industries’ overseers can charge levies.

This is basically copied from SQLite, who offer a commercial licence for those who do not want to rely on public domain code. Except it makes no sense for IndieWeb to start selling licences.

Does “Patent Protection” make any sense in code to which the creators (try to) waive their rights? Can you even still patent a specific solution you came up with, if that solution has already been dedicated to the Public Domain? I am tempted to say no, but obviously I am not an IP lawyer.

[dg01d]

IAAL&IANYL. That said: the CC0 licence specifically retains patent rights to the creator. There are different 'levels' of Intellectual Property, the CC0 treats those differently. It releases copyright and related ownership rights to the Public Domain, it does not release patent & trademark rights. While the CC & FSF state that its fine for software, the OSI balked at calling it an open licence for just that reason. Please understand that I'm not advocating against the CC0, just trying to establish the differences and what is and isn't assigned. The situation you posit is exactly what the CC0 was designed to do: release datasets to the public domain while retaining patent ownership of the methodologies to create and indeed extract the data from raw scientific inputs. It wasn't designed for software at all.

[voxpelli]

Just noticed that Google doesn't permit their employees to patch repositories with CC0 licenses, so unless a Google employee goes through the special process of claiming personal copyright for patches to such a project then they can't patch them: https://opensource.google.com/docs/patching/#stuff-you-cant-do

I don't know if other companies have similar policies, anyone knows?

Perhaps @willnorris can give some more insight or feedback into this and whether it becomes a problem for people working at eg. Google to have CC0 here?

[Zegnat]

That’s interesting. I think the give away is the first line of the page about personal projects:

As part of your employment agreement, Google most likely owns intellectual property (IP) you create while at the company.

With Google owning the rights to the code you write, it is easy to understand why they wouldn’t allow you personally dedicating the code to the Public Domain. (You wouldn’t even be able to do so, Google would have to do that for you.)

You are not allowed to sign CLAs either, which I expect is for the same reason: CLAs usually require you to assign your copyright to a company/organisation/foundation to make sure an author doesn’t go missing when something like a relicense comes up (think VLC), but if Google owns your rights you can’t personally sign them away.

Contributing patches to other places is probably OK because those involve licensing your rights, not giving them up to someone else (or to the public domain). Google will still own the code written.

Fun fact, Google themselves do accept CC0 and Unlicense for use in their projects as “unencumbered”. (If you read on they address the issue with other public domain dedications, which I hope we addressed by allowing companies to use any code under MIT.)

Google is definitely not the only company with such a clause in their contract. Make sure to always check your open-source contributions with your company!

[willnorris]

That's correct, Google's concern is primarily with patching CC0 projects, not with using them. It has to do with restricting the ability to relicense the code, which is a concern unique to the language in CC0.

I'm increasingly becoming a fan of the 0-Clause BSD (aka the Free Public License) for cases like these where you really don't care about attribution.

[dg01d]

Yes, I quite agree. Note that the OSI calls this the "Free Public Licence"

Having been a long-standing MIT proponent, I've started using the FPL/0BSD instead.

[Zegnat]

The 0-Clause BSD is really interesting to me. I think I will be following @dg01d in using it instead of MIT.

We had a discussion on the IndieWeb development channel about the license and @dg01d was kind enough to share his notes on the difference between MIT and 0BSD. When reading the chat logs, please note that this was an informal chat and nothing in there should be taken as legal advice no matter the speaker’s credentials.

[marclaporte]

Just bumping this. The sooner we decide, the sooner we start, the sooner it will be done :-)