-
Notifications
You must be signed in to change notification settings - Fork 0
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
CONTRIBUTING.rst shouldn't have CAA text for MIT licensed repos #56
Comments
I would keep this explicit, mostly for clarity. Any project on Github is open-source, unless we upload precompiled binaries or something. |
That's not true, just because the source is viewable doesn't mean it has an approved open source license attached to it. |
By analogy, just because you read a book doesn't mean you have the right to then copy and sell that book. |
There are all kinds of open source licenses, though, giving all different permissions in regards to what you can and cannot do with the source code. Really, the only common denominator that I see is that the source code is open. For example, our Nengo license gives some groups of people (academics) freedom to modify and distribute our source code for some (non-commercial) purposes. I would call that open-source, but not free and open-source. |
I understand that this is how most people think, but there is an actual strict definition of what open source means: https://opensource.org/osd , see also the annotated version https://opensource.org/osd-annotated The Nengo license is definitely not an open source license; the fact that Nengo source happens to be publicly viewable doesn't make it open source, just like a book being in a library doesn't mean it's free for anyone to copy and sell. |
I'm not sure if that's how most people think. I think a lot of people think that open-source and FOSS are synonymous, but personally I don't. The definition you've attached certainly seems to be referring to FOSS, since the first point is about freedom. Either way, the fact that the term open-source is unclear to many people one way or another suggests to me that we should avoid it. I don't see any drawback to being explicit about the license in |
Sure, we can keep it explicit. I think that the majority of people in the open source community are quite aware of the OSI definitions, outside of it perhaps not. Nengo Bones is really just used by us so it was just an attempt to make a two-item enumeration into a boolean flag but if the flag name is unclear then we can keep it as two strings. |
Currently
CONTRIBUTING.rst
unconditionally includes a paragraph that contributors needs to sign a CAA. That's true for Nengo licensed projects, but not for MIT licensed projects, so we should remove that text if the project is MIT licensed.I think when doing this, we should also move the license to the general section of
.nengobones.yml
so that we don't have to remember to specify the license inlicense_rst
,setup_py
,contributing_rst
and other places that might change based on the license.We might also consider changing this from "mit" and "nengo" to a boolean "open source" as I don't think we have plans to use non-MIT licenses for open source projects, or non-Nengo licenses for non-open source projects.
The text was updated successfully, but these errors were encountered: