Changing license to CERN OHL-P?

[jcmolloy]

@thomasmboa @Fadanka are you happy to change the license to a hardware one like CERN OHL-P?

[thomasmboa]

@jcmolloy are we talking about the incubator or its fork the shaker incubator?

[jcmolloy]

The standard incubator that is described in this repository. At the moment you're using the GNU GPL.

…

On Sun, Jul 5, 2020 at 1:07 PM thomasmboa ***@***.***> wrote: @jcmolloy <https://github.com/jcmolloy> are we talking about the incubator or its fork the shaker incubator? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGXYTLY4HCCF23QHR2TKCTR2BUHVANCNFSM4OQSFQSQ> .

[thomasmboa]

it is ok for me to change only if @amchagas has a different opinion....GNU GPL is limited to software (program/code) while CERN OHL-P offer the same freedom and includes "both firmware and any software that normally comes with the hardware or other item as well as software used to test it."

[amchagas]

Hi!
I think the original idea back then was that GNU GPL was for the repo itself and software (as when the repo started there was no hardware yet). and the reason for it, instead of say MIT, was the hope for derivatives coming out as open source tools as well, which as far as I understand (and might be wrong) is not the case for more permissive things.
That said, I have no issues with changing the license, just curious why CERN OHL-P and not CERN-OHL-S or W?

[jcmolloy]

I figured GPL was the license when the repo was initiated! A license for the documentation, software and hardware would be ideal, GNU GPL wasn't designed for documentation but there is another GNU license for that if you want to stick to the same suite: https://www.gnu.org/licenses/fdl-1.3.en.html. I would preference CC-BY personally because it's compatible with the most other licenses.

Which CERN license is up to the project team, I suggested CERN OHL-P because I think it is simpler to understand and for hardware like this where there are simultaneously few degrees of freedom in the general design but many, many ways to implement it, there is close to zero risk of enclosure of the hardware by similar closed projects (which would be one reason to go reciprocal) and most people who find it are likely to be into open hardware in some way and therefore likely to publish openly anyway, or not and would likely not publish their modifications at all. Having said that, the same arguments point to the exact flavour of hardware license not really mattering in this case!

I like permissive licensing and reliance on norms for reciprocity as opposed to viral licensing terms, but that is a personal preference so whatever Thomas, you and the team think best meets the goals of the project is good with me 😄

We are publishing a paper which will reference the incubator and this repo, which is why I'm asking questions!

[amchagas]

Thanks for your thoughts Jenny. As you mention, in a way, people sharing will share, and people closing up things and make poor use of available OSH will always be there.
@thomasmboa I'm also happy with whatever you and the team working more actively on this decide!