-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Change to a more appropriate license #131
Comments
Hi, Thanks for sharing this. I understand the confusion. Here is why I did this:
Ultimately, I'd like to avoid a scenario like Captura: MathewSachin/Captura#405 (comment) Unfortunately, I don't know any license that would prevent this. What do you think about? Any idea of how we could change the license with respect of the above? Perhaps we should write a custom license? I think one of the challenges here is to define what is a Thanks :) |
Indeed, you're right. There is no OSI-approved license that would meet those conditions. There are some non-commercial licenses that would prevent someone from selling the code, but nothing that limits it to only forks where nothing is changed. I think you really have two choices. One would be to create a custom license, that includes these terms. There are some drawbacks to this. Your license would no longer be recognized by GitHub, and it would no longer conform to an OSI-approved license, which could hinder its discovery and adoption in some places. Also, it would only apply to versions of code to which the new license is applied -- all the older versions can't be retroactively changed, so a really committed person could just fork the older version and re-release. (They would not be able to backport changes made after the license change, though, since those changes are bound by the new license terms.) The other alternative is to change it from a requirement to a recommendation. I think it would perfectly reasonable to say "I'm using a license that permits redistribution and commercial use without changes, but I would really prefer you not, and if you believe you have a strong reason to do so, kindly reach out to discuss with me first." The problem is that you can't legally enforce these restrictions with an MIT license (and it's even harder still to enforce a concept of "added value" - does obfuscating the code without making any changes provided added value?) But changing the wording gives you a chance to outline your concerns without appearing to contradict the license, and may even give you an opportunity to relicense the code for other purposes should the need arise. |
Hi @kswartz26 , These are great ideas, thank you for sharing! I updated the README in the following PR: #133 Can you please let us know what you think about it? Thank you so much for your help with this! We really appreciate :) |
I think that looks great, and definitely resolves the conflict. Very glad this was helpful to you! |
Thank you very much! :D I will merge this change then. |
You have chosen to release this code using an MIT License. The license reads, in part:
But then you also write in the README:
That request is contrary to the terms of the license. You can't offer the code under a license with a set of terms, then tell people you don't want them to follow those terms.
If you do not want people to sell the code, please choose a different license. You may want to consider a CC-BY-NC license if you don't want someone to sell it. I'm not aware of any standard license, however, that prohibits someone from forking and renaming a project, without making changes.
The text was updated successfully, but these errors were encountered: