Please add a license statement to the repository and the source code files

[wucke13]

I assume everything in the kernel will be GPL 2, for the user-space maybe something more libre like LGPL would be advisable?

[JHentges]

We would intend dual MIT/GPLv2 for all kernel sources, yes, just to avoid dirtying the kernel inconveniently.
Our preferred license terms, which we are considering for use with the userland sources, is located here: accesio.com/software-licenses. I'm interested in any feedback you have.
(Note review has found two errors in the current online version; please be gentle)

[wucke13]

Disclaimer: IANAL. Here are my thoughts:

We would intend dual MIT/GPLv2 for all kernel sources, yes, just to avoid dirtying the kernel inconveniently.

Assuming that the kernel sources were written from scratch (as opposed to by copying in-kernel code and modifying it) to suit your needs, then that should be feasible. If however the kernel sources are derivatives from in-tree kernel code, than I believe, going exclusively with GPLv2 would be the only legal way (as you can not simply re-license a derivative work of somebody else's copyright).

Our preferred license terms, which we are considering for use with the userland sources, is located here: accesio.com/software-licenses. I'm interested in any feedback you have.

I read them, and I find them to be quite reasonable. From a business perspective, I take no offense with them.

I'm also doing some Linux distro maintaining every now and then, and from that perspective one thing stings: The license does impose a restriction on the use, which would trigger the free software foundation to mark it as unfree. Consequently, I would have trouble pushing the userspace code into most distributions repositories, as unfree software is usually not liked there due to legal concerns of breaking unfree licenses when re-distributing it as a package (as Linux distributions do, all the time).

From that perspective, I would prefer for the userspace if there is a dual license:

• The existing license is fine for businesses that e.g. want to ship a product which contains ACCES I/O hardware, without tainting their product with a copy-left open source license like the GPL.
• Additionally, I would like the user-space to be offered under a copyleft license (like the GPL), such that Linux distributions have no remorse distributing it. (But, when e.g. a competitor would use the code under the GPL, they would have to provide their derivative works under GPL too, of course).

---

If you want to go the A+ way, I suggest to use the reuse tool to set up the license stuff. It can automatically annotate all your source codes with a license + copyright header, automatically downloads the licenses texts into a subdir of your repo and basically makes sure that you follow best practices on communicating the licenses (and copyright) info for your project.

My way would be:

reuse annotate --copyright 'ACCES I/O Products, Inc.' --license GPL-2.0-only Makefile *.c *.h *.sh

# optionally remove the GPL-2.0-or-later
reuse annotate --copyright 'ACCES I/O Products, Inc.' --license LicenseRef-WITH-ACCES --license GPL-2.0-or-later  apcilib/{Makefile,*.{h,c,cpp}}

# Stackoverflow makes everything after 2018 cc-by-sa-4.0
reuse annotate --copyright 'Stack Exchange, Inc.' --license  'CC-BY-SA-4.0' --year 2019 apcilib/kbhit.inc --style c

# to get the license texts into `LICENSES/`
reuse download --all

# And add the text for the WITH-ACCES license
$EDITOR LICENSES/LicenseRef-WITH-ACCES.txt

# Finally check if something is still missing
reuse lint

I took the liberty to just do this, here is a PR: #31 . Please let me know if you would prefer the GPL2+ to be removed from the userspace code.

[JHentges]

Thank you for your insights.

If however the kernel sources are derivatives from in-tree kernel code, than I believe, going exclusively with GPLv2 would be the only legal way (as you can not simply re-license a derivative work of somebody else's copyright).
APCI is indeed wholly "from scratch" - we've been evolving it for our customers since the 2.4 kernel era. (OTOH e.g., our AIOUSB-Linux module incorporates code from fxload thus wouldn't be dual-licensed.)

Thank you for pointing me towards the reuse tool; I'd not encountered it, very helpful.

Note: our accesio.com/software-licenses used to include CC-BY-SA as an option but I read some years back that Creative Commons prefers their licenses not be used for software so we pulled it. I'd certainly target this if we generated docs (doxygen et al).

We can't use the pull as-is because we've not updated the WITH-ACCES license to fix the mistakes (referring to absent Section B, for example; or the plausibly implicit assertion denying use of the source sans-ACCES-hardware during development), but thank you very much. Your info has moved us much closer to getting our code in line with best practices.