You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -41,6 +46,17 @@ We generally suggest that you use a permissive, license that is [Open Software I
41
46
[submitting your package to pyOpenSci for peer review](https://www.pyopensci.org/about-peer-review/index.html), then we require an OSI approved
42
47
license.
43
48
49
+
:::{admonition} Copyleft licenses
50
+
The other major category of licenses are ["copyleft" licenses](https://en.wikipedia.org/wiki/Copyleft).
51
+
These are licenses that require that anyone that uses your work redistributes it with the same (or greater) rights to modify, copy, share, and redistribute it.
52
+
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.
53
+
Copyleft licenses are "sticky," in that they are designed to ensure that more free software is created.
54
+
55
+
The difference between copyleft vs. permissive licenses is an important cultural divide in free and open source software (eg. see {footcite}`hunterReclaimingComputingCommons2016`, {footcite}`gnuprojectWhatFreeSoftware2019`, {footcite}`gnuprojectWhatCopyleft2022`),
56
+
that you should be aware of when choosing your license - the lineage of copyleft represents the "free" part of "free and open source software."
57
+
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).
58
+
:::
59
+
44
60
### How to choose a license
45
61
46
62
To select your license, we suggest that you use GitHub's
@@ -54,18 +70,17 @@ process.
54
70
:::{admonition} License recommendations from the SciPy package
55
71
[The SciPy documentation has an excellent overview of licenses.](https://docs.scipy.org/doc/scipy/dev/core-dev/index.html#licensing). Once of the key elements
56
72
that these docs recommend is ensuring that the license that you select is
57
-
complementary to license used in the core scientific Python ecosystem.
73
+
compatible with licenses used in many parts of the scientific Python ecosystem.
58
74
Below is a highlight of this text which outlines license that are compatible
59
75
with the modified BSD license that SciPy uses.
60
76
61
77
> 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.
62
78
63
-
To coordinate with otherpackages in our scientific ecosystem, we also recommend
79
+
If your primary goal is for your code to be used by other, major packages in the scientific ecosystem, we also recommend
64
80
that you consider using either BSD or MIT as your
65
81
license. If you are unsure, the MIT license tends to be a simpler easier-to-understand option.
66
82
:::
67
83
68
-
69
84
## Important: make sure that you closely follow the guidelines outlines by the License that you chose
70
85
71
86
Every license has different guidelines in terms of what code
@@ -75,6 +90,31 @@ If you borrow code from other tools or online sources, make
75
90
sure that the license for the code that you are using also complies
76
91
with the license that you selected for your package.
77
92
93
+
A useful way to think about license compatibility is the distinction between **"inbound"** and **"outbound"** compatibility.
94
+
"Inbound" licenses are those that cover the software you plan to include in your package.
95
+
Your package is protected by an "outbound" license.
96
+
97
+
**Permissive licenses** like BSD and MIT have few **outbound** restrictions - they can be used in any way by downstream consumers, including making them proprietary.
98
+
This is why they are favored by many businesses and large packages that want to be able to be used by businesses.
99
+
Permissive licenses have more **inbound** restrictions - they can't use software that requires more freedoms to be preserved than they do, like copyleft licenses.
100
+
A package licensed with MIT needs to take care when including or modifying a package licensed under the GPL-3.
101
+
102
+
**Copyleft licenses** like GPL-3 have more **outbound** restrictions - they require more of packages that include, use, modify, and reproduce them.
103
+
This is the purpose of copyleft licenses, to ensure that derivative works remain free and open source.
104
+
They have fewer **inbound** restrictions - a GPL-3 licensed package can include any other permissively licensed and most copyleft licensed packages.
:::{admonition} An example of how a license determine how code can be reused
79
119
:class: note
80
120
@@ -83,6 +123,7 @@ Let's use stackOverflow as an example that highlights how a license determines h
83
123
[Stack overflow uses a Creative Commons Share Alike license.](https://stackoverflow.com/help/licensing). The sharealike license requires you to use the same sharealike license when you reuse any code from stackoverflow.
84
124
85
125
This means that technically, if you copy code from the Stack Overflow website, and use it in your package. And your packages uses a different license such as a MIT license, you are violating Stack Overflow's license requirements!
126
+
This would not be true with a GPL licensed package - `GPL-3` packages can include code licensed by `CC-BY-SA` {footcite}`creativecommonsShareAlikeCompatibilityGPLv32015`.
86
127
87
128
🚨 Proceed with caution! 🚨
88
129
:::
@@ -98,3 +139,8 @@ These files - we need to understand if that date releases auto populates or forc
0 commit comments