Qmk_firmware: License unclear

Created on 26 Jan 2017  Â·  53Comments  Â·  Source: qmk/qmk_firmware

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.

Most helpful comment

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

All 53 comments

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?

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.)

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?

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.

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.

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.

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.

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

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.

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.

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

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

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.

@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”.

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

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+.)

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

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.

I can't edit the website now. I assume all i did there is GPL or similar.

Thanks
Kind Regards
Joan Lustenberger

Get Outlook for iOShttps://aka.ms/o0ukef


From: skullydazed <[email protected]notifications@github.com>
Sent: Sunday, January 29, 2017 07:26
Subject: Re: [qmk/qmk_firmware] License unclear (#1038)
To: qmk/qmk_firmware <[email protected]qmk_firmware@noreply.github.com>
Cc: heartsekai [email protected]lustenberger.joan@outlook.com>, Mention <[email protected]mention@noreply.github.com>

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 eitherupdate the wiki pagehttps://github.com/qmk/qmk_firmware/wiki/License-Clarification or place a comment in this issue telling us your stance.

@0xdechttps://github.com/0xdec @algernonhttps://github.com/algernon @cdimhttps://github.com/cdim @DidierLoiseauhttps://github.com/DidierLoiseau @eltanghttps://github.com/eltang@ezukhttps://github.com/ezuk @fredizzimohttps://github.com/fredizzimo @h-youheihttps://github.com/h-youhei@heartsekaihttps://github.com/heartsekai @IBnobodyhttps://github.com/IBnobody @jackhumberthttps://github.com/jackhumbert@jakllschhttps://github.com/jakllsch @kuel @lindhehttps://github.com/lindhe @matzebondhttps://github.com/matzebond@plgruenerhttps://github.com/plgruener @priyadihttps://github.com/priyadi @pvinishttps://github.com/pvinis@Smilliamhttps://github.com/Smilliam @sperochonhttps://github.com/sperochon @TerryMathewshttps://github.com/TerryMathews@Tweyhttps://github.com/Twey @Vifonhttps://github.com/Vifon @vincent-pochethttps://github.com/vincent-pochet@wezhttps://github.com/wez @Wilba6582https://github.com/Wilba6582 @yangliuhttps://github.com/yangliu

-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/qmk/qmk_firmware/issues/1038#issuecomment-275896807, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ARApXJWHrfmhXlj9KVSGXSsPwomNes4xks5rXDEjgaJpZM4Lu3qX.

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.

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).

All I did there is under GPL or similar licenses.

Thank you.

Yang

Yang Liu, Ph.D

On 30 Jan 2017, at 4:07 AM, Wez Furlong notifications@github.com wrote:

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).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/qmk/qmk_firmware/issues/1038#issuecomment-275941978, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq022tFarH6W0Kl2d7_4kL0CiEMyrGkks5rXPGTgaJpZM4Lu3qX.

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

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

I thought I did...

On Mon, Jan 30, 2017, 12:47 PM skullydazed notifications@github.com wrote:

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

@cdim https://github.com/cdim @eltang https://github.com/eltang @ezuk
https://github.com/ezuk @IBNobody https://github.com/IBNobody
@matzebond https://github.com/matzebond @priyadi
https://github.com/priyadi @Smilliam https://github.com/Smilliam @Twey
https://github.com/Twey @Vifon https://github.com/Vifon
@vincent-pochet https://github.com/vincent-pochet @Wilba6582
https://github.com/Wilba6582

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qmk/qmk_firmware/issues/1038#issuecomment-276152782,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFl50MYe8mCeb6FwFO2cNlI6tIda74LVks5rXjBYgaJpZM4Lu3qX
.

@IBNobody If you have and I missed it somewhere I apologize. I'll add your signoff right now.

I'm sharing my work under the GPL, signing off here.

@eltang can't sign here since he can't make any comments - wanna reach out to him over email?

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.

@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.

@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.

wakes up from long slumber away from his Planck

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

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+.

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

I have updated the wiki.

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

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

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

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!

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.

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

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

I would prefer GPL. I, for one, have no interest in contributing code to
someone who doesn't wish to contribute back.

On Feb 27, 2017 9:57 AM, "Noah Andrews" notifications@github.com wrote:

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qmk/qmk_firmware/issues/1038#issuecomment-282743041,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4VBRmx3f2N-dSHcY52ckc5X4cv9ggIks5rguQqgaJpZM4Lu3qX
.

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

  1. Have a provision assigning copyright of all contributions to qmk
  2. 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.

@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.

Keymaps probably aren't copyrightable under Feist Publications, Inc., v.
Rural Telephone Service Co

On Feb 27, 2017 12:26 PM, "Noah Andrews" notifications@github.com wrote:

@kekumu https://github.com/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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qmk/qmk_firmware/issues/1038#issuecomment-282788908,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4VBeeJjOuYY3de7GQxAxMLkQgFOT8Dks5rgwcogaJpZM4Lu3qX
.

@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?

Sure. Logic generally is copyrightable. The actual arrangement of keys
likely is not.

On Feb 27, 2017 12:44 PM, "Jack Humbert" notifications@github.com wrote:

@TerryMathews https://github.com/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?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qmk/qmk_firmware/issues/1038#issuecomment-282794013,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4VBWJZDz06wcD-QJKVzchpFquCEEQnks5rgwt5gaJpZM4Lu3qX
.

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?

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

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.

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

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

@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?

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MarkuBu picture MarkuBu  Â·  3Comments

jmagee picture jmagee  Â·  3Comments

kb3dow picture kb3dow  Â·  3Comments

michaeldauria picture michaeldauria  Â·  3Comments

drashna picture drashna  Â·  3Comments