-
Notifications
You must be signed in to change notification settings - Fork 10
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
License followup #63
Comments
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. 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? |
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.
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. |
I agree that holy-wars are not what we want.
I think CadQuery and OpenSCAD fit well into this. You make a good point that 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. |
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. |
Originally posted by @jmwright in #62 (comment)
The text was updated successfully, but these errors were encountered: