search

nengo / nengo-bones

A template for making a new Python project in the Nengo ecosystem
https://www.nengo.ai/nengo-bones/
Other
3 stars 0 forks source link

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

Open tbekolay opened 5 years ago

tbekolay commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

hunse commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.