License followup

[julianstirling]

I realize that the LICENSES directory had several licenses in it. However, I and others use a LICENSES directory for hardware projects because there is no single license that properly covers documentation, hardware, and software. So you end up with three licenses for the project, with a clarification in the README.

Example LICENSES directory

Mention of multiple licenses in the readme (scroll down to bottom of the readme for the licenses section)

People also seem to be passionate about licenses, and license changes can be contentious.

Originally posted by @jmwright in https://github.com/Wakoma/nimble/issues/62#issuecomment-2120477345

[julianstirling]

I agree people are passionate. Unfortunately, I am one of them, but passionate for removing complications!

I also feel strongly that hardware should be covered by hardware licenses and that assembly instructions for hardware are part of the description of the hardware. They really really should be under the same license, as they are essential to the hardware and inseparable from it, just like a doc-string is inseparable from a its Python function and therefore has the same license.

The issue we were fixing in PR #62 was having hardware creating code licensed under the AGPL which stops us licensing the hardware under CERN-OHL.

I 100% agree that actual software needs to be under a software license. I normally handle this by separating into two repositories. For example: OpenFlexure Microscope Hardware and OpenFlexure Microscope Software. I worry about relying on headers, I am happy with a license file per folder or a clear explanation of what is under what license. But I prefer repository separation.

Nimble has no software, but we will be making a web-interface and server code. I can see that these really do want to be under a different license. Probably possibly AGPL.

I would personally suggest we make a repo called "Nimble Configuration Server" (or something similar) and move the server into that repo. That repo could always sub-module the main nimble repo to make it easier to develop. Or we can check it out in CI?

@jmwright would you be happy with this? What license should the server use?

[jmwright]

Nimble has no software, but we will be making a web-interface and server code.

I would argue that utilities like this count as software.

Also, CadQuery scripts (like OpenSCAD) fall into a weird category where they are both software and hardware source files. CadQuery files are good at capturing design intent when used properly, and essentially contain the necessary information to build a thing (can generate manufacturing/assembly drawings), but are still programming source code at their core.

I would personally suggest we make a repo called "Nimble Configuration Server" (or something similar) and move the server into that repo.

Making it a separate repo sounds fine to me. I don't have a preference on the server license (AGPL vs something similar).

I don't know that we will agree on the single-license-file-to-rule-them-all argument, but I don't want to get us bogged down either. Licensing is a kind of holy war that I do not have the spare energy for. We need to keep moving, and I feel like we are in a "good enough" position for now, but I do think it is good to leave space for discussion and change (if needed) in the future.

[julianstirling]

I agree that holy-wars are not what we want. Code CAD does occupy an interesting space where it is both softwarey and hardwarey. I think my point would always be as that if the result from the code is something that will be physically made. Then you should use a hardware license as it covers what happens to that physical object. The CERN OHL defines this as:

'Complete Source' means the set of all Source necessary to Make a Product, in the preferred form for making modifications, including necessary installation and interfacing information both for the Product, and for any included Available Components. If the format is proprietary, it must also be made available in a format (if the proprietary tool can create it) which is viewable with a tool available to potential licensees and licensed under a licence approved by the Free Software Foundation or the Open Source Initiative. Complete Source need not include the Source of any Available Component, provided that You include in the Complete Source sufficient information to enable a recipient to Make or source and use the Available Component to Make the Product.

I think CadQuery and OpenSCAD fit well into this.

You make a good point that devices_json_updater.py is different and may want a different license.

My gut feeling is that the complexity of licensing within a repo is 2^(n), where n is the number of extra licenses. If we really do need extra licenses, that is OK. But they should be added with caution, and carefully discussed so everyone is happy, hopefully thus avoiding a Holy War.

[julianstirling]

I am closing this once the bulk of the orchestration and the server is separated from the CAD, as this makes the licensing is more clearly separatd. There are still some project specific stand-alone utilities may want their own license at some point. As these stand alone and are quite simple they are probably best under permissive licenses to minimise license complexity.