Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

figure out a license #426

Open
slingamn opened this issue Sep 30, 2020 · 10 comments
Open

figure out a license #426

slingamn opened this issue Sep 30, 2020 · 10 comments

Comments

@slingamn
Copy link
Contributor

The status quo is that the copyright to specifications is owned by their authors. There doesn't seem to be any explicit licensing arrangement governing how specs can be distributed or modified. This leads to uncertainty in several situations, e.g., whether reviving and rewriting an abandoned draft specification requires the permission of the original author.

The objective here is to eliminate this uncertainty by figuring out a license that will govern all contributions to the ircv3-specifications repository (and, if necessary, procedures for ensuring that contributions are "signed off" by their authors).

@RyanSquared
Copy link
Contributor

RyanSquared commented Sep 30, 2020

From my own understanding, I believe that CC-BY-SA should be applicable. After some discussion with @jwheare, he mentioned he's going to be getting some proper legal advice to make sure that this covers what we would like it to cover (or to find a more suitable license), and not introduce anything that we wouldn't like introduced.

My reason for suggesting CC-BY-SA is that it seems to consider the things that we consider appropriate, and does not introduce too much extra baggage on top that would not be required by most other licenses. However, concerns were raised about the license being "viral" (which is an appropriate consideration). I also chose this license because it is one of the most recognizable licenses for written copyright works that aren't code, and therefore are more legally understandable by the average person.

In addition to this, I will be seeing if I can contact a lawyer to see what will need to be done to relicense old specifications. If we were to get a signoff by all contributors for a file, that file can then be covered by the license (as has happened with the Linux kernel in the past). However, we need to consider the case where a contributor is unreachable, and what can happen with a file at that point, and whether or not an unreachable maintainer can have their own copyright replaced by one administrated by the IRCv3 working group. As far as I can tell, it is legally questionable at best. The best case scenario would to be to license it with a subset of the chosen IRCv3 license that disallows distribution for commercial purposes, to avoid the case of suing by the legal copyright owner in case of damages lost due to commercial use.


(and, if necessary, procedures for ensuring that contributions are "signed off" by their authors)

I believe this would be necessary by default, if we were to assume that all the content in the repository is covered by the license.

@RyanSquared
Copy link
Contributor

RyanSquared commented Sep 30, 2020

A suggested proposal from IRC was to use a Creative Commons Attribution Generic license (CC-BY), which I am also fine with. This means that proprietary or nonfree documentation for services can quote the specifications without having to worry about "free use" laws.

@RyanSquared
Copy link
Contributor

RyanSquared commented Oct 1, 2020

Licenses that have been considered on IRC are (in no particular order)

  • CC0
  • CC-BY
  • CC-BY-SA
  • MIT
  • BSD 2-clause

A shallow review of all licenses (this is not legal advice, I'm not a lawyer, and I'm definitely not your lawyer):

CC0 / "No Rights Reserved"

CC0 [gives] creators a way to waive all their copyright and related rights in their works to the fullest extent allowed by law. CC0 is a universal instrument that is not adapted to the laws of any particular legal jurisdiction, similar to many open source software licenses. And while no tool, not even CC0, can guarantee a complete relinquishment of all copyright and database rights in every jurisdiction, we believe it provides the best and most complete alternative for contributing a work to the public domain given the many complex and diverse copyright and database systems around the world.

https://creativecommons.org/share-your-work/public-domain/cc0/

Summary: https://creativecommons.org/publicdomain/zero/1.0/
Legal Text: https://creativecommons.org/publicdomain/zero/1.0/legalcode

CC-BY / "By Attribution General"

This license allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use.

https://creativecommons.org/about/cclicenses/

Summary: https://creativecommons.org/licenses/by/4.0/
Legal Text: https://creativecommons.org/licenses/by/4.0/legalcode

CC-BY-SA / "By Attribution, Share Alike"

This license allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use. If you remix, adapt, or build upon the material, you must license the modified material under identical terms.

https://creativecommons.org/about/cclicenses/

A point for consideration is that works that do not DERIVE FROM the project (i.e. subsections or extractions that are VERBATIM and UNMODIFIED) are not required to be licensed under the same license. See section 3(b) of the legal text, and note the restriction of application of ShareAlike for ONLY "Adapted Materials" (defined in section 1(a)).

Summary: https://creativecommons.org/licenses/by-sa/4.0/
Legal Text: https://creativecommons.org/licenses/by-sa/4.0/legalcode

MIT

Legal Text: https://opensource.org/licenses/MIT

BSD 2-clause

Legal Text: https://opensource.org/licenses/BSD-2-Clause

Points for consideration for MIT and BSD 2-clause licenses:

  • The MIT license and BSD 2-clause license makes reference to "source code", where the IRCv3 specifications are most likely closer to a literary work.
  • The BSD 2-clause license creates a distinction between "binary" and "source" can cause complications when determining whether compiled Markdown (the format of specifications as of this issue) is a "binary".

@slingamn
Copy link
Contributor Author

slingamn commented Oct 1, 2020

+1 for CC-BY (someone who may or may not endorse CC-BY noted that it is the license used for the HTML5 living standard, which seems like an excellent precedent).

@jwheare
Copy link
Member

jwheare commented Oct 1, 2020

Turns out we have a license of sorts that all specs are published with:

Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.

This was added as a template boilerplate in April 2015 with #141 and ircv3/ircv3.github.io#1

Prior to that change, most specs had this text within each markdown file directly.

These are the specs that didn't have that text, that are still published today, with their authors at the time:

core/message-tags-3.2.md (@DarthGandalf, Stéphan Kochen, @kylef)
core/monitor-3.2.md (Lee Hardy, Kiyoshi Aman, William Pitcock)
extensions/account-tag-3.2.md (@grawity)
extensions/extended-join-3.1.md (Kiyoshi Aman)
extensions/sasl-3.1.md (Jilles Tjoelker, William Pitcock)
extensions/server-time-3.2.md (Stéphan Kochen, @DarthGandalf, @kylef)
extensions/userhost-in-names-3.2.md (@grawity)

These were effectively given a license uplift on that date, it's not clear if all copyright holders gave permission at the time.


  1. One option we have is to just keep this license, and be done with it. If so I'd like to get explicit approval from the following that they are happy with this:

@grawity, @DarthGandalf, @kylef.
William Pitcock made the change so their approval can be assumed.
I don't know if Stéphan Kochen, Jilles Tjoelker, Kiyoshi Aman, Lee Hardy are still active on IRC/github and can be contacted.

  1. If instead we want to change the license (CC-BY seems a relatively sensible option) we would need approval from more people (everyone who's contributed to any spec at all). Are there any pressing reasons to push for a license change, or does the existing text cover our needs for a license?

We want the specs to be open, editable, forkable and re-publishable and not be vulnerable to authors revoking their work in future. A popular license like CC-BY has the advantage of being well recognised and "trusted" and written by lawyers, but it is general purpose and may be overkill.

  1. Whatever license we choose (or stick with), we should mention prominently in CONTRIBUTING.md that by contributing to the specifications you agree to license your work under the license.

  2. A note on attribution/copyright notices. CC doesn't replace copyright, it just enables sharing copyrighted works. So author copyrights wouldn't go away if we switched. But we can specify a preferred attribution style "IRCv3 Contributors" or the like.

@slingamn
Copy link
Contributor Author

slingamn commented Oct 1, 2020

If instead we want to change the license (CC-BY seems a relatively sensible option) we would need approval from more people (everyone who's contributed to any spec at all).

How difficult would it be to adopt CC-BY for all future spec contributions, without making it retroactive?

@RyanSquared
Copy link
Contributor

If instead we want to change the license (CC-BY seems a relatively sensible option) we would need approval from more people (everyone who's contributed to any spec at all).

How difficult would it be to adopt CC-BY for all future spec contributions, without making it retroactive?

I see no reason why we can't say that all further contributions are CC-BY, or signed off to the IRCv3 organization.

@jwheare
Copy link
Member

jwheare commented Oct 1, 2020

How difficult would it be to adopt CC-BY for all future spec contributions, without making it retroactive?

Not difficult, but I'm more concerned about whether it's necessary or desirable. Is CC-BY materially better than what we have? I'm not convinced. Would having split licensing be confusing or cumbersome? Probably.

@RyanSquared
Copy link
Contributor

How difficult would it be to adopt CC-BY for all future spec contributions, without making it retroactive?

Not difficult, but I'm more concerned about whether it's necessary or desirable. Is CC-BY materially better than what we have? I'm not convinced. Would having split licensing be confusing or cumbersome? Probably.

Looking at the license currently provided,

Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.

It looks like this has equivalent permissions, just without the "legalese" of the CC-BY license. I don't think we gain anything by using CC-BY. My reasoning for using it was that it seemed common enough in my ecosystems that people would know they can use it just by the name, but I see no way for people to misinterpret the above license.

@slingamn
Copy link
Contributor Author

slingamn commented Oct 2, 2020

I don't think intellectual property concerns of any kind are a pressing concern for IRCv3. However, I don't think the status quo addresses the primary motivating concern for this issue: ensuring that all contributors (including to draft PRs) have consented to licensing their work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants