Mention copyleft in license guide! #189
Conversation
No comma Co-authored-by: Inessa Pawson <[email protected]>
Co-authored-by: Inessa Pawson <[email protected]>
There was a problem hiding this comment.
@sneakers-the-rat Important points and excellent explanation of a rather complex topic! I made a few minor suggestions to clarify some parts of the text. Feel free to disregard those that you don't find helpful.
thanks to @InessaPawson Co-authored-by: Inessa Pawson <[email protected]>
lwasser
added
enhancement-feature
|
Looks good to me on a quick skim! Nice work! Do we want to mention things like the Affero GPL as a further copyleft license, that prevent companies from taking your software and running it as a service w/o releasing the source? https://www.gnu.org/licenses/why-affero-gpl.en.html |
I think it would be worth expanding this out into a separate "reference" style page that addresses the history and purposes for different licenses, that's something that I don't know of a concise reference for really. I think in this page it might be a little bit too much detail - i feel like "there are permissive and copyleft licenses" and the top-level differences between them, but yes, the cool thing about our guides being websites is we can make infinitely many extra pages <3 |
|
@lwasser Would you please review? The htmlproofer complaints seem unrelated to this PR. |
|
ok!! i'll put this on my list to review this week! thanks @willingc for pinging me! |
|
@all-contributors please add @ctb for code, review |
|
I've put up a pull request to add @ctb! 🎉 |
|
@sneakers-the-rat i suspect the conflicts here relate to the pr's i merged yesterday where you fixed our requirements and such. can you kindly rebase when you have a chance? in the meantime i'll review today/tomorrow! |
| In other words, copyleft licenses prohibit someone taking your work, making a proprietary version of it, and redistributing it without providing the source code so others can do the same. | ||
| Copyleft licenses are "sticky" in that they are designed to ensure that more free software is created. |
There was a problem hiding this comment.
| In other words, copyleft licenses prohibit someone taking your work, making a proprietary version of it, and redistributing it without providing the source code so others can do the same. | |
| Copyleft licenses are "sticky" in that they are designed to ensure that more free software is created. | |
| This makes copyleft licenses "sticky" in that they are designed to ensure that more free software is created. If your work has a copyleft license, it prohibits someone taking it, making a proprietary version of it, and redistributing it without providing the source code for others to use and share. | |
There was a problem hiding this comment.
i'm not sure if this is quite right but just trying to simplify the words a bit :)
There was a problem hiding this comment.
Hmm ya you're right there needs to be a little more glue between these ideas bc it's not quite clear how they encourage more free software from this alone. I think the order of explaining what they are -> what 'stickiness' means makes sense, but maybe like "This requirement makes copyright licenses "sticky" - they are designed to encourage more free, copyleft licensed software to be created."
There was a problem hiding this comment.
i think i follow!! i updated the revision.
|
|
||
| The difference between copyleft vs. permissive licenses is an important cultural divide in free and open source software (e.g., see {footcite}`hunterReclaimingComputingCommons2016`, {footcite}`gnuprojectWhatFreeSoftware2019`, {footcite}`gnuprojectWhatCopyleft2022`), | ||
| that you should be aware of when choosing your license - the lineage of copyleft represents the "free" part of "free and open source software". | ||
| Free and open source software is intrinsically political, and it is important to be aware of power dynamics in computing as well as the practical problems of license compatibility (discussed below). |
There was a problem hiding this comment.
This is al great @sneakers-the-rat , thank you!! I have a few thoughts and questions here.
- i think for someone who is new to software and OSS the political part will seem "out of no where" and potentially scary even tho it is truth. i wonder if there is a way to make this statement a bit more clear to someone that is new. i feel like there is a leap here from - let's add a license to your package to - there are power dynamics at play and licenses can be play a role in these dynamics. i'm not sure what language we should use but i just wonder if we can make this more clear to someone who is newer to the space. It's especially confusing as projects like numpy ahd choosealicense.org suggest that we use MIT. so i'd be asking - well it seems like everyone should use GNU then. Why are we using MIT? why are we suggesting MIT.
do you see where i'm going here? can we adjust to consider those types of questions and thoughts / concerns? (honestly i'm thinking the same right now as we decided on MIT as a community but copyleft does sound compelling the way it's described here.
There was a problem hiding this comment.
Maybe we can say something like "This set of tutorials is primarily intended to teach you to program, but an important part of learning to be a programmer is learning about the history and culture of open source software. Licensing is a decision about who can do what with your code, which is intrinsically political ... {rest of text} ... there are legitimate differences in goals and context for open source software, and each category of licenses has their uses, supporters, and detractors"
There was a problem hiding this comment.
i think that makes a lot of sense to frame it . do you want to make that change to the file? This is also making me think that we should either have a blog post on this topic (probably preferred) OR add a page to the guide about the culture of open source software. Or both. that way we can link to that content rather than adding too much to individual pages. how about that? i can open this as a new issue in this repo and we can decide whether it should be a blog or a page in the guide. and maybe we can get the community to help write it if someone starts it.
i'll open the issue now and we can discuss separately
| Below is a highlight of this text which outlines license that are compatible | ||
| with the modified BSD license that SciPy uses. | ||
|
|
||
| > Other licenses that are compatible with the modified BSD license that SciPy uses are 2-clause BSD, MIT and PSF. Incompatible licenses are GPL, Apache and custom licenses that require attribution/citation or prohibit use for commercial purposes. | ||
|
|
||
| To coordinate with other packages in our scientific ecosystem, we also recommend | ||
| If your primary goal is for your code to be used by other, major packages in the scientific ecosystem, we also recommend |
There was a problem hiding this comment.
see this conflicts with the breakout above. and i totally understand why we want that breakout above. but a new user will be confused by this after reading about copyleft! so how can we create a text bridge between the two?
There was a problem hiding this comment.
how do you mean? like we should have a parallel "otherwise, if your goal is..." for copyleft? I read it as previous section recommending permissive licenses, and then this section further explaining why that would be the case - there are lots of major packages that use permissive, and if you use copyleft then your work can't be used in them. can you tell me more about what's reading as discordant?
There was a problem hiding this comment.
it conflicts with the recommendations that the scientific community is making already. as a reader i see - pyopensci suggests MIT, scipy suggests using licenses that are compliant with the rest of the scientific ecosystem. and then now we're talking about copyleft which actually aren't compliant with the ecosystem. there is cognative dissonance here as a reader trying to make a decision
| @@ -75,14 +90,40 @@ If you borrow code from other tools or online sources, make | |||
| sure that the license for the code that you are using also complies | |||
| with the license that you selected for your package. | |||
|
|
|||
| A useful way to think about license compatibility is the distinction between **"inbound"** and **"outbound"** compatibility. | |||
There was a problem hiding this comment.
i feel like some of this would be useful above. what is we thought about re-organizing this page jonny?
at the top we have
Where to store your license
Use open permissive licenses when possible
what is instead we do something like this
## Where to store your license
keep text as is
##Types of licenses: permissive vs copyleft
explain inbound vs outbound restrictions here to frame the text below
### Overview of permissive licenses
### Overview of copyleft licenses (make your breakout into this section)
## How to chose a license
* we suggest mit or bsd-3 for compatibilty with the scientific Python ecosystem
* scipy text as a reference
## Following license guidelines
more about how to follow and how that impacts permissive vs copyleft (which by now it's clear how these are different). and yo've already explain inbound vs outbound permisions above so you can just have a little table even and demonstrate how the licenses are different.
There was a problem hiding this comment.
I think this should probably come after we give definitions of what the categories of licenses are, but i'm definitely game to making a separate section for each type, that is def clearer and might help above comment re: ordering.
I see this thought as being part of all three 'what are the types of licenses,' 'why might i choose one vs another,' and 'how do i follow license guidelines' so idk! I think it's nicely paired with the example of stack overflow. so i could see this part going one of a few places...
- Where to store license
- Types of licenses
- permissive
- copyleft
- comparison <--- maybe here???
- choosing a license
- suggestion
- scipy thing
- considerations to weigh <--- maybe here???
- following license guidelines
- when you can and can't use software given your license <--- maybe here???
- stack overflow example
i don't rly have a strong preference, but i think you're right maybe sooner is good :)
There was a problem hiding this comment.
i think what you have above is fine. i just think all of the overview should be in one section and then choosing should be it's own section with limited additional info but definitely a considerations section
| This is the purpose of copyleft licenses, to ensure that derivative works remain free and open source. | ||
| They have fewer **inbound** restrictions - a GPL-3 licensed package can include any other permissively licensed and most copyleft licensed packages. | ||
|
|
||
| | Compatible | Dependency <br> ("Inbound") | Your Package | Downstream Package <br> ("Outbound") | |
There was a problem hiding this comment.
OMG you have a table - yes! i was thinking a table would be great. myst tables are pretty create btw. simpler syntax / easier to read :)
There was a problem hiding this comment.
you mean the list table directive? i can swap it to that if you'd prefer :)
There was a problem hiding this comment.
yes list or any of those directives i find to be easier to read / fix edit :)
There was a problem hiding this comment.
Opened #416 as a task for post-merge.
There was a problem hiding this comment.
@sneakers-the-rat this is awesome. I feel like we just need to reorganize a bit now that we have new important concepts introduced!! i love it all, let's just clarify so we don't scare off new users. So i'm suggesting a reorg that allows us to introduce concepts higher up on the back such as
permissive vs copy left and
inbound vs outbound permissions.
then it will be easier to digest i think lower down and flow better.
are we swapping rolls for this pr 😆?! i love it!
Co-authored-by: Leah Wasser <[email protected]>
agreed :) replied above thinking about places to move that section!
may all hierarchies be forever fluid <3 |
|
here is the current rendered page i think a clean reorganiation is the key piece as right now a new user is going to be really confused. but i also think we have a lot of great information in this pr!! |
|
ok let's see - what do we need to do to get this PR merged? I think
|
| @@ -75,14 +90,40 @@ If you borrow code from other tools or online sources, make | |||
| sure that the license for the code that you are using also complies | |||
| with the license that you selected for your package. | |||
|
|
|||
| A useful way to think about license compatibility is the distinction between **"inbound"** and **"outbound"** compatibility. | |||
| This is the purpose of copyleft licenses, to ensure that derivative works remain free and open source. | ||
| They have fewer **inbound** restrictions - a GPL-3 licensed package can include any other permissively licensed and most copyleft licensed packages. | ||
|
|
||
| | Compatible | Dependency <br> ("Inbound") | Your Package | Downstream Package <br> ("Outbound") | |
There was a problem hiding this comment.
Opened #416 as a task for post-merge.
|
Good with that if others are :) |
There was a problem hiding this comment.
awesome @willingc thank you!! i've wanted to get back to this one. let's merge. thank you @sneakers-the-rat we can always sprint on the other issues at a later date. in fact maybe that's what we need to do periodically is organizing packaging guide sprints to look for updates and to merge open prs. thank you both.
Currently the license guide only mentions permissive licenses without discussing what the alternative might be. I think this is a relatively balanced discussion that provides some links to further readings and also grounds the discussion in some history. Software is political! and we should at least mention copyleft, even if we have elected to recommend permissive licenses - I think we should do so in a way that anyone who reads our guides can make an informed choice.
sphinxcontrib-bibtex