Incorporate feedback into legal.md

_articles/legal.md

@@ -12,15 +12,15 @@ related:
 
 ## Understanding the legal implications of open source
 
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this legal crash course you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
 
 ## Why do people care so much about the legal side of open source?
 
 Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
 
 In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
 
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly state these permissions in a document called a license.
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
 
 These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
 
@@ -40,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec
 
 You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
 
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the [most popular open source licenses](https://libraries.io/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
 
 When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
 
@@ -60,17 +60,17 @@ Otherwise, picking the right open source license for your project depends on you
 
 Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
 
-* **"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).
+Dependencies with **permissive licenses** like [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) allow you to license your project however you want.
 
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+
 You may also want to consider the **communities** you hope will use and contribute to your project:
 
 * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors and the ability to use the project in proprietary software. In this case, the permissive [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) or the limited copyleft [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (and them) covered.
 * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
 
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive or limited copyleft license so your project can be used in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
 
 When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
 
@@ -86,7 +86,7 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 **Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
 
-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 pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). 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.
 
 ## Does my project need an additional contributor agreement?