GPLV3 Pl0x - License change
DevDeckardCain opened this issue · comments
### TLDR (too long, didn't read);
MIT is fine is you're interested in commercialization and would want to, at some point in the future, branch off and take the code with you. My personal opinion is, I'm not cool with this. I don't want to spend hundreds of hours getting something somewhere so that other people can more easily start companies, but I'm also not opposed to other people making money, so long as they pull their weight.
### For those that prefer video format:
Comparing licenses:
https://d.tube/#!/v/devdeckardcain94/zgn7xdo88dh
Linus Torvalds' opinion:
https://d.tube/#!/v/itsdevdc94/33gqoaw1pir
Comparison between multiple licenses:
https://d.tube/#!/v/itsdevdc94/zp2psx3zidv
Others:
https://d.tube/#!/v/itsdevdc94/9v9p83kmew5
https://d.tube/#!/v/itsdevdc94/9v74ls0hu3e
### Overview:
This will be a long, and ultimately very important conversation. What I want to begin discussing is a change from the MIT license to either GPLV3 (preferred) or GPLV2. The reasons for this is, I personally don't want to write open source code so that someone else could take it and start a company.
It is in my belief that DTube should be communal, as in no one company should be able to just take our code, make it better and release their own DTube completely separate from us. I'm not opposed to making money, but I do think that if someone wants to make money off of something, it shouldn't be off the backs of the community.
The proposed change in license wouldn't restrict business form happening, but would instead protect the core of what we all value (the DTC and the webui). Should these two things be protect with a license which would ensure that anyone who makes changes must publish those changes. This would ensure that if some company came around and wanted to take what we have and expand upon it, they would be more than welcome to do so through the API using whatever licenses they want, but if they want to touch the core in any way (not using the REST API), then they must pull their weight and send those changes to us for approval / disapproval (we don't have to accept the changes they make, we just have to have the option of getting them).
An additional thing to consider when considering GPL, is the FSF (fsf.org), who will hire lawyers and fight on your behalf should someone violate the license.
By no means am I saying my way or the highway, perhaps through more dialectic we can decide on something altogether different, but I do feel this discussion is incredibly important as some developers don't like working on projects with certain licenses, so we need to be sure that the license we have is there for good reason.
I don't think this is necessary. Avalon is application specific, those who wish to fork Avalon should be able to do so as long as the copyright notices are retained. They will likely have to make substantial changes or else they would obviously look like DTube knockoffs and will unlikely to gain any traction.
I would prefer to retain the MIT license as it is less restrictive. The DTube meteor frontend is GPLv3 as it should be as it is directly user-facing unlike Avalon.
If I understand the difference correctly, GPLv3 would essentially restrict the 'fork and make it close-source / proprietary' option.
If someone wants to use avalon to open their own blockchain, I believe most people will want to have an open network, where anyone can join and open a node, so it will likely be open-source, which means that both licences are the same in this case.
Conversely, if a group of people wanted to run a new avalon chain close-sourced, either:
1- they would need to obfuscate and package the code to have a single executable for people wanting to run a node
2- they would want to run a private/hidden blockchain
I totally would like to forbid 1) because I don't like the idea of people running obfuscated/proprietary software on their machines. However I'm not sure if 2) has any utility, I don't see any concrete example of that ever happening.
Soooo, all in all I think it does not change much, just restricts the case of 1) and I would be in favor.
I don't think this is necessary. Avalon is application specific, those who wish to fork Avalon should be able to do so as long as the copyright notices are retained. They will likely have to make substantial changes or else they would obviously look like DTube knockoffs and will unlikely to gain any traction.
I would prefer to retain the MIT license as it is less restrictive. The DTube meteor frontend is GPLv3 as it should be as it is directly user-facing unlike Avalon.
Avalon isn't really application specific at all, since all it is is a blockchain with an API. I agree that DTubes web interface would be branded, but that's a separate project.
Less restrictive in what ways and to whom?
If I understand the difference correctly, GPLv3 would essentially restrict the 'fork and make it close-source / proprietary' option.
If someone wants to use avalon to open their own blockchain, I believe most people will want to have an open network, where anyone can join and open a node, so it will likely be open-source, which means that both licences are the same in this case.
Conversely, if a group of people wanted to run a new avalon chain close-sourced, either:
1- they would need to obfuscate and package the code to have a single executable for people wanting to run a node
2- they would want to run a private/hidden blockchainI totally would like to forbid 1) because I don't like the idea of people running obfuscated/proprietary software on their machines. However I'm not sure if 2) has any utility, I don't see any concrete example of that ever happening.
Soooo, all in all I think it does not change much, just restricts the case of 1) and I would be in favor.
You can totally fork, it's just you would inherit the GPLV3 license and won't be able to change it. This would mean that if I forked a project that has GPLV3, I won't be able to change the license to the fork, but won't have to adopt any new code (still allowing hard forks).
Even if its GPLV3, that doesn't mean you can't obfuscate other things together with this (your companys proprietary API etc) and it would only require you to publish changes if you make changes to the base, so if we make it modular (through REST), then anyone can make their own propriety program that uses the GPLV3 REST API.
Closing this due to no consensus from contributors