-
Notifications
You must be signed in to change notification settings - Fork 80
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
Comments
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.
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. |
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. |
Licenses that have been considered on IRC are (in no particular order)
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"
Summary: https://creativecommons.org/publicdomain/zero/1.0/ CC-BY / "By Attribution General"
Summary: https://creativecommons.org/licenses/by/4.0/ CC-BY-SA / "By Attribution, Share Alike"
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/ MITLegal Text: https://opensource.org/licenses/MIT BSD 2-clauseLegal Text: https://opensource.org/licenses/BSD-2-Clause Points for consideration for MIT and BSD 2-clause licenses:
|
+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). |
Turns out we have a license of sorts that all specs are published with:
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) These were effectively given a license uplift on that date, it's not clear if all copyright holders gave permission at the time.
@grawity, @DarthGandalf, @kylef.
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.
|
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. |
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,
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. |
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. |
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).
The text was updated successfully, but these errors were encountered: