Update legal.md #3086
Update legal.md #3086
Conversation
- Simplify the legalese in a few places - Add more links to licenses and data behind various claims - Add more descriptions for different classes of licenses. - Improve internal linking within the article.
thehale
temporarily deployed
to
Pages Preview
GitHub Actions
Inactive
| On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. | ||
| * **"Permissive" licenses** give you permission to use, modify, and share the library without any conditions on how you license your project. Common permissive licenses include [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause). | ||
| * **"Limited copyleft" licenses** (sometimes called "weak copyleft") are similar to permissive licenses -- generally your project can use whatever license you want -- but modifications to the library itself must be shared under an identical/compatible license. Common limited copyleft licenses include the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and the [LGPL](https://choosealicense.com/licenses/lgpl-3.0/). | ||
| * **"Strong copyleft" licenses** also give you permission to use, modify, and share the library, but only if your project uses an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses). Common strong copyleft licenses include [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), and [AGPLv3](https://choosealicense.com/licenses/agpl-3.0). | ||
|
|
There was a problem hiding this comment.
The long parentheticals defining each class of license break the reader's concentration. By re-writing in bullet point form, there's more space to explain without creating a wall of text, and it matches the layout of the following communities section.
I also added details about "limited copyleft" licenses to bring greater awareness to their unique properties. I deliberately chose the term "limited copyleft" to emphasize the limited reach of their copyleft provisions (the distinguishing characteristic of these licenses). The more common term is "weak copyleft", but I have seen that term prompt faulty impressions that such licenses somehow only provide "weak/less-enforceable" copyright protections.
There was a problem hiding this comment.
Get the parens aren't ideal but feel like the bullets make it less obvious what the connection between dependencies' licenses and your project are. And I don't think it's really necessary to introduce the concept of limited or weak copyleft at this point.
There was a problem hiding this comment.
Good feedback. My edits shift the focus back towards the ramifications of a dependency's license on the larger project.
I still think it's helpful to briefly distinguish between strong/limited copyleft licenses since their requirements for downstream project licensing differ so widely. That was a big point of confusion for me when I started out in open source. Additionally, including the distinction here prepares the reader to understand the discussion a few paragraphs later of why some companies want a "strong" copyleft license.
The linked article about the "additional rules" of limited copyleft licenses is from FOSSA, a blog about open-source licensing. I am not affiliated with them, just a fan of their detail and approachability.
thehale
force-pushed
the
legal_tweaks
branch
from
59e64ac to
8af36b8
Compare
thehale
temporarily deployed
to
Pages Preview
GitHub Actions
Inactive
|
Tagging @karasowles while I'm on leave! I believe she scheduled a followup call with all the writers. Cc @leereilly |
There was a problem hiding this comment.
Hi @thehale, sorry this PR has languished - It didn't register on our automation. This all looks great and I appreciate your commentary on why you made the edits you did. You mentioned adding a reference to a copyright/attribution project, do you want to add that inline before merge? If so, go ahead and do so - if not, I'll merge this as-is. Thank you!
|
Thanks! I'll add the link by this weekend, then move the PR out of draft status. |
Git Authorship is a project that helps maintainers identify the individuals who have committed code present in the current version of the project. Added with the permission of @ahpook to avoid "self-promotion" concerns since this is one of my own projects. The commented section at the end of the article discusses ideas for future additions to this article.
thehale
force-pushed
the
legal_tweaks
branch
from
8af36b8 to
fff435d
Compare
thehale
temporarily deployed
to
Pages Preview
GitHub Actions
Inactive
| On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. | ||
| * **"Permissive" licenses** give you permission to use, modify, and share the library without any conditions on how you license your project. Common permissive licenses include [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause). | ||
| * **"Limited copyleft" licenses** (sometimes called "weak copyleft") are similar to permissive licenses -- generally your project can use whatever license you want -- but modifications to the library itself must be shared under an identical/compatible license. Common limited copyleft licenses include the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and the [LGPL](https://choosealicense.com/licenses/lgpl-3.0/). | ||
| * **"Strong copyleft" licenses** also give you permission to use, modify, and share the library, but only if your project uses an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses). Common strong copyleft licenses include [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), and [AGPLv3](https://choosealicense.com/licenses/agpl-3.0). | ||
|
|
There was a problem hiding this comment.
Get the parens aren't ideal but feel like the bullets make it less obvious what the connection between dependencies' licenses and your project are. And I don't think it's really necessary to introduce the concept of limited or weak copyleft at this point.
_articles/legal.md
Outdated
|
|
||
| Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. | ||
| Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- [see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. |
There was a problem hiding this comment.
I suggest putting "see below" in brackets here too as you did below.
| Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- [see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. | |
| Alternatively, you can have contributors agree in advance via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. |
There was a problem hiding this comment.
Originally, I only linked up the existing text. In the latest edits, I took your re-write a few steps further to remove redundant clauses.
e.g. "under certain conditions" and "beyond those allowed ..." are already implied by the need for a separate contract.
|
@thehale it's a friendly Open Source Friday ping on this PR! Looks like all the comments have suggestions that would be straightforward to batch-commit - could you click through them and update your branch? We can iterate further in the future but I'd love to get this merged and closed out. 🚀 ❤️ |
|
I'm going to go ahead and merge this, if there are future iterations we want to make on this doc let's do so in a fresh PR. Cheers all 🚀 |
On July 31, 2023 @abbycabs asked me to review the legal article on Open Source Guides for tweaks and improvements.
This PR...
For now, I'm keeping this in draft status to (1) allow for more discussion about the changes and (2) give time to flesh out the new litigation section (if we decide to pursue it).
Checklist
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.