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.

Sign up for GitHub

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

Jump to bottom

License unclear #1038

Closed
yurikhan opened this issue Jan 26, 2017 · 53 comments
Closed

License unclear #1038

yurikhan opened this issue Jan 26, 2017 · 53 comments
Assignees
@skullydazed

Comments

@yurikhan
Copy link

I have built a custom keyboard and am documenting it with the hope of getting it OSHWA-certified. One requirement is that the firmware is released under an open source license.

The TMK core is labeled as GPL2 or later, with some protocol/… files under Modified BSD license. The licenses are mentioned in pretty much every file’s header block.

Some of files in QMK do not have header blocks, and the root readme does not mention the license.

This may be interpreted as lack of any license for these files, and the default is to grant no rights to anybody. In turn, linking these with GPL2+-licensed tmk_core makes the resulting binary undistributable.

Please consider adding a LICENSE[.md] file to the root of the repository, or a License section to the top-level readme.md, and/or header blocks to all source files.
@ezuk
Copy link
Contributor

ezuk commented Jan 27, 2017

Great issue, thank you. The tl;dr here is that the licensing situation is a bit of a mess atm. I would like to get the whole project under MPL. It's mainly a question of how to go about it -- it's a legal issue and I'm not a lawyer. Is that something you might be able to assist with?

@skullydazed
Copy link
Member

This is my understanding of our licensing status:

  • TMK was unambiguously released under the GPL
  • As a fork of TMK any source code with no copyright/licensing statement automatically takes on the GPL
  • It is possible to release (or relicense) any file under another license, so long as that license is compatible with the GPL and the terms of the GPL are met when distributing the work as a whole
  • Unless copyright is explicitly assigned it is owned by whoever wrote a particular piece of code
  • To relicense requires written consent from all copyright holders

For the purpose of this issue I think we can clarify the licensing situation pretty easily. I think relicensing the work as a whole under the MPL is a separate issue (and a pretty major initiative.)

@ezuk
Copy link
Contributor

ezuk commented Jan 27, 2017

Thanks @skullydazed

So based on this, actually if we wanted to license as MPL it's relatively simple. We would need to contact TMK and get his written consent. If obtained, then that leaves large parts that @jackhumbert wrote and would be able to license. And then we would need to see what other major pieces are left behind if any.

Not saying we should address this right now but it actually sounds pretty doable?

@yurikhan
Copy link
Author

I am not a lawyer either, but my understanding is close to @skullydazed’s, except that I do not take it for granted that newly added files are automatically licensed under the GPL, in particular, files added after the deletion of the License clause from the top readme in 04a36ec.

As for relicensing under MPL, I would consider that unfortunate. That would enable the following scenario:

  • A vendor V builds a keyboard using QMK.
  • V then implements a desirable feature X as a separate source file. It builds a firmware consisting of QMK (MPL-licensed) and the new feature X (proprietary) and distributes it as a Larger Work.
  • Meanwhile, another feature Y is developed and added to QMK (MPL-licensed).
  • The user then cannot upgrade their firmware to include feature Y without either V’s assistance, forgoing feature X, or reimplementing feature X independently.

@fredizzimo
Copy link
Contributor

The license issue have been discussed a few times earlier, so I think we really should take an action.

However re-licensing under MPL is not that simple.

  1. For the GPLv2 code in TMK, we need to contact every contributor, not just TMK. They owns the copyright of the source and are the only ones that can change the license.
  2. The ChibiOS library we are using is unfortunately licensed under GPLv3, and unless we get a commercial license we can't change that. We can perhaps obtain a [free commercial license] (http://www.chibios.org/dokuwiki/doku.php?id=chibios:licensing:start) for it, but I doubt that's worth it. Another option would be to make a special fork for the ChibiOS keyboards, but that wouldn't be worth the hassle.

For new files I think the case is one of the two below. But I don't know which interpretation is the right one.

  1. I think new files added after the GPL license was removed are technically copyrighted by the committers. Therefore no one currently holds the rights to distribute QMK. If that's the correct interpretation, then on order to change the license, even to GPL they all would have to be contacted.

  2. The other interpretation is that since QMK is forked from TMK, it's automatically assumed that the additional QMK files are GPL licensed as well.

I assume you want MPL to give commercial vendors the right to use the code, and force them to provide their modifications back. As @yurikhan stated, it's unfortunately very easy for them to work around that. New features can freely be added to new files without QMK ever even knowing about them. Well maybe we would see the makefile changes to confirm that new features exist, but that's all . Also if they want to modify some small parts of existing features, they could quite easily just rewrite the whole file and replace it by their own version and don't have to give anything back. However for smaller bug fixes it's probably easier for them to contribute than to rewrite.

I personally hate GPL, and I'm not very found of MPL either, I think all open source should have permissive licenses but that's just my opinion. But the fact is that we currently are forced to distribute under GPLv3, due to ChibiOS and GPLv2 due to TMK. I haven't checked all libraries, so there could be more GPL code in use.

@ezuk
Copy link
Contributor

ezuk commented Jan 27, 2017 •
edited
Loading

I tend to agree with @fredizzimo. My concern specifically is about the configurator (http://configure.ergodox-ez.com). This is a Rails app that runs a compile in the background. For various reasons (business, technical, and security), I cannot open source this in the foreseeable future.

I think this is okay as QMK is not "integrated" into the app nor does it modify it -- just runs a shell command essentially. I.e this is not "linking" in the binary sense nor do we distribute a binary containing QMK. But like all of you guys, I'm not a lawyer.

Assuming this does not conflict with the GPL, I would be okay with GPL. The scenario @yurikhan described is indeed undesirable -- everything we do for the ErgoDox EZ goes right back into QMK and gets released as part of the codebase, and I think that's the way it should be.

@fredizzimo
Copy link
Contributor

I'm not a lawyer either, but this is my understanding.

Both GPLv2 and GPLv3 can be run as webservices, even without having to distribute the code. I'm almost completely sure about that as you can read about it from several different sources.

Also from the GPLv3 license

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

AGPL on the other hand would require you to distribute the source code for server-side software.

So even if the configurator itself contained GPL code it would be allowed. I think the makefiles, which it probably is using would fall under interpreter usage, so even then it would still not be considered as GPL.

It's also similar to a compiler, GCC is GPL, but still it can produce non-GPL binaries, so in that sense it should be OK too.

@skullydazed
Copy link
Member

except that I do not take it for granted that newly added files are automatically licensed under the GPL, in particular, files added after the deletion of the License clause from the top readme in 04a36ec.

I've been reading up this morning. The more I read the more the mud gets stirred up, and the picture isn't getting any less clear. :)

I think we should start by acknowledging that we're in a huge grey area. It would have been less ambiguous had we followed the GPL exactly, which has a couple clear guidelines to prevent this ambiguity. How we get from our current state to an unambiguous state is something of a mystery still, but here is the picture I'm developing. Please speak up if you think anything is incorrect here.

  • Is is common for projects to have a project wide license
  • The license text in the README was documentative, not declarative. In other words, it describes the policy but does not define the policy.
  • When that text from removed from the README, the policy about licensing did not change
  • At this point, the policy is undocumented but still in place. (IE, all participants acted in good faith that their contributions would continue under the GPL.)
  • Every file that explicitly lists a license is unambiguous
  • Legally speaking, any file that does not explicitly list a license is licensed under whatever the file's creator wants.
  • The file's author is under no obligation to publicize the license a file is offered under, it's incumbent on anyone else publishing to determine the license status themselves.

So I think the code that falls into the grey area described by @yurikhan is covered by GPL implicitly. I also think it would be better if it were explicit as it will avoid complications down the road. Given this, our process forward should be:

  • Create a top-level LICENSE file
  • The first person to create a file should go back and explicitly link to the top-level LICENSE.
  • Any file where the original author can not be found we will have to decide on a case by case basis

Some ideas we may want to consider, either for now or in the future as we grow:

  • Draw up some bylaws governing the qmk project, to make it a legally recognized unincorporated association
  • Have a provision assigning copyright of all contributions to qmk
  • Potentially modify the copyright provision so that people own the copyright to their contributed keymap while licensing it to us under the (L)GPL (or optionally BSD 2-clause)

Sources:

  1. https://meta.discourse.org/t/discourse-the-gpl-and-per-file-notice/7208
  2. http://stackoverflow.com/questions/845895/putting-license-in-each-code-file
  3. http://softwareengineering.stackexchange.com/questions/125836/do-you-have-to-include-a-license-notice-with-every-source-file
  4. http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
  5. http://wiki.osdev.org/Licensing

@fredizzimo
Copy link
Contributor

I think we could start by doing something like this
git log --pretty="%an %ae%n%cn %ce" --after <date> <path> | sort | uniq to get a list of people that have commited to specific <paths> for all of QMK and TMK. The <date> could be set to when QMK was started.

I don't think keymaps need to be included in the first stage, as they can probably be licensed separately.

Then a mail could be sent out asking if it's OK to change the license to GPL. If we are lucky then everyone will reply, but most likely a few people will be missing. But at least that would be a step much closer.

@skullydazed
Copy link
Member

Even limiting to the 04a36ec commit we have 64 authors, some who don't have email addresses outside of @users.noreply.github.com. Removing the obvious dupes (multiple emails for the same person) only gets us down to 55 or so.

zach-desktop:qmk_firmware zwhite$ git log --pretty="%ae%n%cn %ce" 04a36ec..HEAD quantum | grep -v ' ' | sort -u | wc -l
      60

For the people we won't be able to contact I think we will need to evaluate how significant their contribution is to determine whether we need to do more work before applying a license to their code.

@skullydazed
Copy link
Member

Using a little bit of code and the wiki I've put together a list of files in the quantum directory and enumerated the commits. In most cases I think it will be pretty easy to get the authors to agree:

https://github.com/qmk/qmk_firmware/wiki/License-Clarification

@ezuk
Copy link
Contributor

ezuk commented Jan 27, 2017

after reading this thread, I think going with the GPL sounds like the simplest idea.

skullydazed added a commit that referenced this issue Jan 27, 2017
@skullydazed
First pass at clarifying the license (#1038)
db774be
@skullydazed skullydazed mentioned this issue Jan 27, 2017
Merged
@skullydazed
Copy link
Member

skullydazed commented Jan 27, 2017 •
edited
Loading

I've identified the files that have only a single author, and with his permission have added GPL preamble to all the files owned by @jackhumbert in #1042. Anyone else on the single author file list (Wez Furlong, @IBNobody, @Potz, @kazufukurou (Artyom Mironov?), @h-youhei, kuel, and @fredizzimo) can help us out a lot by creating similar PR's for their own code, or commenting on #1042 to let me know I can add your files to the PR.

skullydazed added a commit that referenced this issue Jan 28, 2017
@skullydazed
Merge pull request #1043 from potz/patch-1
ec05f65 
Clarify license on abnt2 keymap (#1038)
skullydazed pushed a commit that referenced this issue Jan 28, 2017
@potibas @skullydazed
Clarify license on abnt2 keymap (#1038)
aac2d71
smt added a commit to smt/qmk_firmware that referenced this issue Jan 28, 2017
@smt
Merge branch 'master' into smt/planck
fa72689 
* master:
  Clarify license on abnt2 keymap (qmk#1038)
  replace jackhumbert with qmk
  Add gitter image, start update to qmk org
  Remove COLEMAK from preonic_keycodes enum
  layer defines to enum
  Update readme for smt Preonic keymap
  Add smt keymap for Preonic
  updated all the other keymaps to support the new changes.
  fix: infinity60 keyboard was not using quantum features.
  Compare Makefile with itself instead of using `--help`
@yurikhan
Copy link
Author

@fredizzimo, @skullydazed, thanks for working on this.

@ezuk, I agree with @fredizzimo’s assessment of the effect of GPL on the configurator; you are not required to distribute its sources, whether or not they contain GPL code, as long as you are not distributing copies of the configurator.

There is one small issue; when the user clicks the Download this layout button, you are distributing to them a GPL-covered program in Object code form. The Download source link gives them a C source file containing their layout only.

However, GPL2 §3 and GPL3 §6 require you to either give, or explain how to obtain, the Complete Corresponding source. In my understanding, that means all of the files that the user would need in order to independently produce that same .hex file. A link to the QMK repository would be Corresponding only if accompanied with a commit ID, and the Completeness requirement could be satisfied by having an instruction to the effect of “create a subdirectory in keyboards/ergodox/keymaps and put your keymap there named as keymap.c”.

@skullydazed
Copy link
Member

If your username is in this list you need to take action. We need everyone to indicate their consent to have their work licensed under the GPL. Please take a moment to either update the wiki page or place a comment in this issue telling us your stance.

@0xdec @algernon @Cdim @DidierLoiseau @eltang @ezuk @fredizzimo @h-youhei @heartsekai @IBNobody @jackhumbert @jakllsch @kuel @lindhe @matzebond @plgruener @priyadi @pvinis @Smilliam @sperochon @TerryMathews @Twey @vifon @vincent-pochet @wez @Wilba6582 @yangliu

@algernon
Copy link
Contributor

I was contributing under the assumption that the governing license is the GPL, so as such, I hereby declare that all the code I have contributed to QMK so far, can be placed under the GPLv2+.

(And while at this point unnecessary, I'll add that I would not consent to changing the license of code I contributed, except if changing to GPLv3+.)

@pvinis
Copy link
Contributor

pvinis commented Jan 29, 2017

i agree with @algernon, and i also edited the wiki.

@jakllsch
Copy link
Contributor

I contributed under the assumption of any of BSD/MIT, GPLv2, GPLv3. However, I do not consider my existing contributions of scancode remapping information significant/unique/original enough to justify a claim of copyright for myself.

@heartsekai
Copy link
Contributor

heartsekai commented Jan 29, 2017 via email

@skullydazed
Copy link
Member

Thanks to everyone that has signed off so far. As I write this we still need sign off from the following people:

@0xdec @Cdim @DidierLoiseau @eltang @ezuk @IBNobody @lindhe @matzebond @plgruener @priyadi @Smilliam @sperochon @TerryMathews @Twey @vifon @vincent-pochet @wez @Wilba6582 @yangliu

I'll update this list about once a day for the next few days and then start reaching out directly to stragglers.

@wez
Copy link
Contributor

wez commented Jan 29, 2017

Hey folks, just wanted to confirm that my contributions have been under the assumption that this project is licensed under a GPL v2 or v3 style license (as that seemed to be the prevailing thing).

@yangliu
Copy link
Contributor

yangliu commented Jan 30, 2017 via email

@lindhe
Copy link
Contributor

lindhe commented Jan 30, 2017

I'm all aboard having/making the code GPL (any version). I do not have time add that myself, as of now.

@skullydazed
Copy link
Member

Thanks to everyone who has signed off in the last 24 hours. We're still looking for sign-off from the following contributors:

@Cdim @eltang @ezuk @IBNobody @matzebond @priyadi @Smilliam @Twey @vifon @vincent-pochet @Wilba6582

@IBNobody
Copy link
Contributor

IBNobody commented Jan 30, 2017 via email

@skullydazed
Copy link
Member

skullydazed commented Feb 2, 2017 •
edited
Loading

Thanks to everyone who's signed off in the last 3 days. I've been on light duty since I pulled an abdominal oblique but I'm still working through this. We still need signoff from the following people:

@cdlm @eltang @Smilliam @Twey @vifon @vincent-pochet @Wilba6582

Next week I will start contacting anyone left via email.

@jordiorlando
Copy link
Contributor

@skullydazed Just FYI, you're accidentally tagging @Cdim when you should be tagging @cdlm (cdLm vs cdim). I looked back at the history to make sure that's the correct username, and changed it on the wiki page.

@skullydazed
Copy link
Member

@0xdec Thanks for noticing that and correcting the wiki! I've updated the list I copy and paste so I tag @cdlm properly next time.

@cdlm
Copy link
Contributor

cdlm commented Feb 3, 2017 •
edited
Loading

wakes up from long slumber away from his Planck

Sure, I'm OK with GPL :)
I need to catch up with recent updates too…

SjB added a commit to SjB/qmk_firmware that referenced this issue Feb 3, 2017
@SjB
Merge branch 'master' into sjb-keymaps
1f47121 
* master:
  Typo fixes
  Reverted Dockerfile to put the CMD back
  update my neo2 keymap
  [deadcyclo layout] Refactoring. Use custom functions and macros
  [deadcyclo layout] fixed failing tests
  race condition between oneshot_mods and tap_dance
  Clarify license on abnt2 keymap (qmk#1038)
  [deadcyclo layout] Added more unicode keys and ibus unicode compose trigger keys
  albert ergodox keymap
  replace jackhumbert with qmk
  Add gitter image, start update to qmk org
  Remove COLEMAK from preonic_keycodes enum
  [deadcyclo layout] Added lotsof new emojis and some new unicode keys
  Update readme for smt Preonic keymap
  Add smt keymap for Preonic
  [deadcyclo layout] Added unicode layer
  [deadcyclo layout] Added support for ergodox ez shine
  updated all the other keymaps to support the new changes.
  fix: infinity60 keyboard was not using quantum features.
  Compare Makefile with itself instead of using `--help`
@vifon
Copy link
Contributor

vifon commented Feb 9, 2017 •
edited
Loading

Sorry for the late response. I'm ok with GPL, sure. :)

EDIT: I'm not sure if the statement above is enough so:

I was contributing under the assumption that the governing license is GPL and I hereby declare that all the code I have contributed to QMK so far can be placed under GPLv2+.

@vincent-pochet
Copy link
Contributor

Sorry for the late response
I'm ok with GPL!

I have updated the wiki.

@skullydazed
Copy link
Member

Thanks again to everyone who has updated the wiki. We are down to 4 GitHub members and 2 people who don't seem to be on GitHub (anymore?). I will be reaching out over email to them directly tomorrow with this message: https://gist.github.com/skullydazed/c9fd96c5f97282dd66c83245d1af684e

The following people still need to sign off:

@eltang @Smilliam @Twey @Wilba6582

@skullydazed
Copy link
Member

I have sent email to the remaining contributors who have not yet signed off.

@wilba
Copy link
Contributor

wilba commented Feb 15, 2017

I agree that all my past TMK/QMK contributions (including the ones not attributed to me) can be licensed under GPL (any version).

@sboesebeck
Copy link
Contributor

Anything I wrote can be licensed under GPL if it not already is...

i just saw on the Clarification page, that there is an old email adress listed, not used anymore.... we should change that!

@skullydazed skullydazed self-assigned this Feb 15, 2017
@exiva exiva mentioned this issue Feb 25, 2017
Open
@kekumu
Copy link

kekumu commented Feb 26, 2017 •
edited
Loading

On a related note, it may be a good idea to implement a contributor's license agreement going forward: https://cla.github.com/. Usually better to be explicit rather than implicit.

Github even offers a tool that streamlines the whole process through pull requests: https://github.com/integrations/cla-assistant.

Edit: CLA assistant is not a Github project, it's 3rd-party. Others are called clabot and CLAHub.

@skullydazed
Copy link
Member

@kekumu That's a really neat idea. I think that's something we should dig into.

@NoahAndrews
Copy link
Contributor

If we do implement a CLA, I'm in favor of contributors at least maintaining ownership of the copyright to the code they write.

@TerryMathews
Copy link
Contributor

TerryMathews commented Feb 27, 2017 via email

@kekumu
Copy link

kekumu commented Feb 27, 2017

Some ideas we may want to consider, either for now or in the future as we grow:
2. Have a provision assigning copyright of all contributions to qmk
3. Potentially modify the copyright provision so that people own the copyright to their contributed keymap while licensing it to us under the (L)GPL (or optionally BSD 2-clause)

  1. This shouldn't be necessary unless there was a desire to change the license in the future, which seems unlikely given the issues with getting permission from all the tmk contributor's as well. GPL represents a certain FLOSS philosophy that contributors would probably not want changed in the future. Plus, some people can be turned off from the idea of assigning copyright to someone else.

  2. If a copyright grant was included in the CLA, it should definitely not be a transfer of copyright (speaking of both qmk itself and any keymaps). Also, keymaps could be licensed under any of the following compatible licenses: https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses.

@NoahAndrews
Copy link
Contributor

@kekumu

If a copyright grant was included in the CLA, it should definitely not be a transfer of copyright (speaking of both qmk itself and any keymaps). Also, keymaps could be licensed under any of the following compatible licenses: https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses.

One complication with allowing that is that most keymaps are going to be based on a large degree to the default keymap, which is GPL licensed. That means that all of those keymaps can't then be relicensed under something less restrictive. Better IMO to require GPL for everything for simplicity's sake.

@TerryMathews
Copy link
Contributor

TerryMathews commented Feb 27, 2017 via email

@jackhumbert
Copy link
Member

@TerryMathews some people write custom functions and keycode processors into their keymaps (at least that option exists) - I'd imagine those would be covered, wouldn't they?

@TerryMathews
Copy link
Contributor

TerryMathews commented Feb 27, 2017 via email

@skullydazed
Copy link
Member

Thanks for the feedback on keymaps everyone. It will be useful when we are ready to tackle those.

I've gone through the current code and set of signoffs and have updated #1042. at this point we have 3 files which are still unclear:

  • quantum/keymap_extras/keymap_plover.h
  • quantum/keymap_extras/keymap_russian.h
  • quantum/keymap_extras/keymap_unicode_cyrillic.h

I have tried contacting @Twey and @kuel both through github and through private email, but neither have responded. We will need to decide how to proceed from here. As I see it we have 2 options:

  1. Remove those files
  2. Assume the files have been GPL the whole time

Does anyone see a third option?

@Twey
Copy link
Contributor

Twey commented Mar 14, 2017

Apologies for slow reply.
I am fine with my contributions being considered GPL.

@skullydazed
Copy link
Member

Thanks @Twey!

That leaves us with only the keymap_russian.h and keymap_unicode_cyrillic.h files. At this time it appears they are not being used by any keymaps, so we can remove them without affecting any contributed keymaps. At some point in the future if someone wants to recreate them from original sources we can add them back in.

I'll wait one week to give everyone one final chance to weigh in and then I'll merge #1042.

@jackhumbert
Copy link
Member

I think we're ready-to-go on this now, right?

@skullydazed
Copy link
Member

I think we are! I just resolved the merge conflicts and if the CI looks good I'll merge #1042.

@skullydazed
Copy link
Member

@yurikhan I've just merged #1042 which should mean that all the core files are clearly licensed. I will begin working on the user-contributed keymaps next, but since you can easily remove those from your branch I believe this clears the way for you to pursue OSHWA certification. Do you have any concerns we haven't addressed yet?

@yurikhan
Copy link
Author

Thank you everyone. I do believe the license is unambiguous now and as long as newly added files get license blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@skullydazed skullydazed

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests