PHEP 6: Community and Licensing Standards #44
Conversation
pheps/phep-9999.md
Outdated
|
|
||
| Projects at the bronze tier or above must use an [OSI-approved open source license](https://opensource.org/licenses). | ||
|
|
||
| Projects at the gold tier or above must either use the [BSD 3-clause](https://opensource.org/license/bsd-3-clause) or [Apache](https://opensource.org/license/apache-2-0) licenses, or include a detailed description of: |
There was a problem hiding this comment.
This is again very prescriptive and prefers the two licenses above. Does it really matter if people are using MIT or two-clause BSD? No, but that also should make the essay assignment really quick. Maybe this "must" should be the full list of permissive "popular and widely used" and have the exception process otherwise, but was trying to avoid getting bogged down.
There was a problem hiding this comment.
I think expanding this to 3-5 good options is fine at the silver tier. Maybe we include MIT and bsd-2-clause there? Perhaps a more restrictive list is preferred at the gold tier?
Also, there is no tier above gold tier -> "at the gold tier or above"
There was a problem hiding this comment.
Fixed the "or above" but the other discussion is still open...do we want something different for silver, or keep things simple?
pheps/phep-9999.md
Outdated
| * why relicensing is not possible, including any efforts taken to that end | ||
| * what steps will be taken to overcome the disadvantages of the license, including the ability to distribute via normal means, the ability to accept contributions, and the ability to be used as a component of other projects | ||
|
|
||
| Project reviewers will consider this rationale in evaluating the package for gold tier. It is still strongly recommended to use a permissive license from the OSI categomry "[Licenses that are popular and widely used or with strong communities](https://opensource.org/licenses?categories=popular-strong-community)", i.e. [BSD 2-clause](https://opensource.org/license/bsd-2-clause), [CDDL](https://opensource.org/license/cddl-1-0), [EPL](https://opensource.org/license/epl-2-0), [MIT](https://opensource.org/license/mit), or [MPL](https://opensource.org/license/mpl-2-0). This will be taken into consideration when evaluating the reason for the selection of license. |
There was a problem hiding this comment.
Yes, now I see the "categomry" typo, will fix in next push.
There was a problem hiding this comment.
ability to accept contributions without restrictions
There was a problem hiding this comment.
@rebeccaringuette , take a look and can you resolve if satisfied?
pheps/phep-9999.md
Outdated
|
|
||
| This includes development in a version controlled repository which is accessible to the public. PyHC uses git almost universally and most projects use GitHub, which facilitates much of the workflow around these activities. Using similar tools across packages helps integrate the PyHC community. | ||
|
|
||
| To keep development open, not just the code, most projects have a means to discuss design and other decisions in a way that allows for public visibility and input. This includes means of collecting user feedback, bug reports, feature requests, and other inputs. Providing all contributors access to the same or similar workflow as project developers, e.g. pull request and reviews, smooths contributions and breaks down distinctions between "internal" and "external" contributions. |
There was a problem hiding this comment.
@rebeccaringuette this feels like it might be a place for your comment to have contributions "allowed without additional legal processes" unless maybe that should go up in the "hard requirements" of the licensing standard?
There was a problem hiding this comment.
Add on to line 104 and copying from earlier text:
"Choosing a license without restrictions on the ability to distribute via normal means, the ability to accept contributions, and the ability to be used as a component of other projects further supports open development."
Seems like enough to me. What do you think?
There was a problem hiding this comment.
@rebeccaringuette , another request to resolve if the new language is properly incorporated?
…push date * Incorporate Rebecca Ringuette's wording on licenses that accept contributions without restrictions and related best practices.
|
@sapols : if this is ready for a number, can you assign one and I'll mark not-draft? I think this would be 5? (EDIT: 6. #32 should probably be 5, and I know I promised to work on that.) (posting phep 1 criteria here: |
|
Thanks @jtniehof, I assigned this PHEP number 6 |
|
I checked the language this morning. All seems fine. One thing that seems to be missing is the circumstances under which a given type of license can be considered to add to this PHEP, and what characteristics should that license have? Ideally there would be no restrictions on contributions or incorporation into other packages. Thoughts on adding text to this point? |
jtniehof
changed the title
That would be a matter of "write another PHEP and have another vote", I think...this is meant to be a static list. Would it make sense for me to expand a bit in the rationale of why these particular licenses? That would then be a potential guide in the future if for some reason people wanted to think about additional licenses. But I think ideally there would not be more licenses... |
|
Yes, I'd be interested in the rationale for why/why not these specific licenses. PySPEDAS is licensed under MIT -- it might not be a big deal to switch to one of the recommended licenses, but it would be nice to understand why the MIT license isn't preferred. |
|
I am quite interested in this from HDRL's perspective. For most software, it can be extremely difficult to change licenses if there are institutional processes. What is the list of software licenses that PyHC recommends, why are those licenses recommended, and why a few other common licenses are not recommended? For starters, here is a short list from HSSI generated with previous PyHC input:
Example text could be: In comparison, the current text prefers BSD 3-clause or Apache 2.0 licenses at the gold tier and highlights a few others. |
|
We should not recommend GPL since it is viral. Some institutions (like mine) do not allow us to release software with GPL. This then restricts how we can even use GPL software. Also, NASA in SPD-41a also suggests using a permissive license, so GPL does not fit with that recommendation. |
|
PyHC Package License Summary
Total Packages: 96 |
|
NASA SPD-41a (currently available here: https://science.nasa.gov/wp-content/uploads/2023/08/smd-information-policy-spd-41a.pdf ) |
* Add MIT to the short list * Expand on rationale * Note dual licensing
|
Sorry this took awhile, but updated draft from the fall meeting discussions is up. The rationale is a fair bit more descriptive now, and is explicit about what factors result in the inclusion/exclusion of any particular license. I don't know why the trailing whitespace failure. I can't find any in the phep 6 file; maybe it's in another existing file. |
5 participants
This PHEP updates the community (2, 12, 13, 15) and licensing (5) standards. Closes #33.
The big change is the licenses. I tried to come up with a good way to thread that needle, see some comments inline.
I would love a lot more examples of things that are done well in our projects.
EDIT: Candidate timeline. If people are able to provide feedback on this timeline it will greatly help me incorporate comments into drafts in a timely manner. There are a number of these trying to "come in to land" at the fall meeting and I appreciate not having to write them all at once.