Skip to content
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

Open
tbekolay opened this issue Aug 9, 2019 · 7 comments
Open

CONTRIBUTING.rst shouldn't have CAA text for MIT licensed repos #56

tbekolay opened this issue Aug 9, 2019 · 7 comments

Comments

@tbekolay
Copy link
Member

tbekolay commented Aug 9, 2019

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 in license_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.

@hunse
Copy link
Collaborator

hunse commented Aug 9, 2019

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.

I would keep this explicit, mostly for clarity. Any project on Github is open-source, unless we upload precompiled binaries or something.

@tbekolay
Copy link
Member Author

tbekolay commented Aug 9, 2019

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.

@tbekolay
Copy link
Member Author

tbekolay commented Aug 9, 2019

By analogy, just because you read a book doesn't mean you have the right to then copy and sell that book.

@hunse
Copy link
Collaborator

hunse commented Aug 9, 2019

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.

@tbekolay
Copy link
Member Author

tbekolay commented Aug 9, 2019

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.

@hunse
Copy link
Collaborator

hunse commented Aug 9, 2019

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 .nengobones.yml.

@tbekolay
Copy link
Member Author

tbekolay commented Aug 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants