From 94a698e87c23edfd794bba9a5256fcab28f0d836 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Thu, 11 Aug 2016 14:41:14 -0500 Subject: [PATCH 01/23] Start review of legal article From 6251982eb80126b71e6622573b7cc68f4ba56766 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 09:11:53 -0700 Subject: [PATCH 02/23] source+license --- getting-started/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/getting-started/index.md b/getting-started/index.md index 4ec3b7c9ae7..892681c98be 100644 --- a/getting-started/index.md +++ b/getting-started/index.md @@ -9,7 +9,7 @@ So you’re interested in making your project open source? Congratulations! 🎉 Before we get into the details of running and managing an open source project, let’s talk about what open sourcing a project actually means. -## Public projects on GitHub are not open source +## Public projects on GitHub without a license are not open source When you publish a project on GitHub, you have the option to make the repository **private** or **public**. A public repository is not automatically open source unless you pick a license that grants a certain set of rights to people who might interact with your project. @@ -17,9 +17,9 @@ Open source licenses grant permission to everyone to use, modify, and share lice Public repositories on GitHub [comply with GitHub’s Terms of Service](https://help.github.com/articles/open-source-licensing/), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) -## Open source is more than just a license +## Open source is more than just source code with a license -Open source is defined by its legal protections and freedoms. In terms of culture, open sourcing a project has come to mean much more. +Open source is [defined by](https://opensource.org/osd) source code with legal protections and freedoms. In terms of culture, open sourcing a project has come to mean much more. There are many reasons why a person or organization might want to open source a project. Some examples are: From d303ce47a97f0497d1bcee0b88e8882c74f83985 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 09:22:00 -0700 Subject: [PATCH 03/23] comply with->covered by TOS, slightly more intuitive links --- getting-started/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/index.md b/getting-started/index.md index 892681c98be..c9ba65e69b9 100644 --- a/getting-started/index.md +++ b/getting-started/index.md @@ -15,7 +15,7 @@ When you publish a project on GitHub, you have the option to make the repository Open source licenses grant permission to everyone to use, modify, and share licensed software for any purpose, subject to certain conditions, depending on the license. -Public repositories on GitHub [comply with GitHub’s Terms of Service](https://help.github.com/articles/open-source-licensing/), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) +Public repositories on GitHub are covered by [GitHub’s Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to [include an open source license](https://help.github.com/articles/open-source-licensing/). For example, someone cannot legally use your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) ## Open source is more than just source code with a license From 1d146face460be0f2e43d9d3201e650c184bf53e Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 09:42:38 -0700 Subject: [PATCH 04/23] rm superfluous at best jargon --- getting-started/branding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/branding.md b/getting-started/branding.md index 9951c961341..fa7ba3c242b 100644 --- a/getting-started/branding.md +++ b/getting-started/branding.md @@ -15,7 +15,7 @@ Pick a name that is easy to remember and, ideally, gives some idea of what the p Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. For example, some of your users might be employees; you don’t want to make them uncomfortable when they have to explain your project’s name to coworkers! -## Avoiding namespace conflicts +## Avoiding name conflicts Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov). From eee2d92e364ca493c544f132d89209035861fa73 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 10:11:25 -0700 Subject: [PATCH 05/23] rm individual license mentions --- getting-started/preparing.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/getting-started/preparing.md b/getting-started/preparing.md index 510c0c3dfc6..82b3ad72acb 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -12,7 +12,7 @@ Every open source project should include the following: * Contributing guide * Code of conduct -As a maintainer, these components will help you communicate expectations, manage contributions, protect your legal rights, and make sure that you and your contributors have a positive experience. The more you can document for your readers up front, the less work you’ll have to do later on. +As a maintainer, these components will help you communicate expectations, manage contributions, protect your, contributors’, and users’ legal rights, and make sure that you and your contributors have a positive experience. The more you can document for your readers up front, the less work you’ll have to do later on. ## Choosing a license @@ -20,14 +20,7 @@ An open source license guarantees that others can use, copy, modify and contribu Legal work is no fun. The good news is there are many licenses available that you can copy and paste into your repository. It will only take a minute to protect your hard work. -There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that comply with the generally accepted definition of open source. Some licenses you’ll commonly hear about are: - -* [MIT License](http://choosealicense.com/licenses/mit/) -* [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/) -* [Mozilla Public License 2.0](http://choosealicense.com/licenses/mpl-2.0/) -* [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/) - -When you create a new project on GitHub, you are given the option to select a license. Including one of these licenses will make your GitHub project open source. (Different licenses carry slightly different permissions. You can use [http://choosealicense.com](http://choosealicense.com) to find the right license for you.) +When you create a new project on GitHub, you are given the option to select a license. Including one of these licenses will make your GitHub project open source. (You can use [http://choosealicense.com](http://choosealicense.com) to find the right license for your project.) If you have other questions or concerns around the legal aspects of managing an open source project, we've got you covered: [The legal side of open source](../legal/) @@ -54,6 +47,7 @@ As a maintainer, READMEs are an opportunity to clarify your goals in public. If When you include a README file in the root directory, GitHub will automatically display it on your project repository’s homepage. It will be the first thing someone sees when they arrive. + ## Setting your contributing guidelines A CONTRIBUTING file tells your audience how to participate in your project. For example, you might want to tell your reader how to create an issue, file a bug report, test fixes, or format code. @@ -76,6 +70,7 @@ Codes of conduct help protect not just your participants, but yourself. As you m In addition to communicating your expectations, you should describe what happens if someone violates the code of conduct, and where someone can report such behavior. We recommend placing a CODE_OF_CONDUCT file in your root directory. + ## What’s next? Now that you have these four files in the root directory of your project, you’re ready to open source your project! Click "publish" and pat yourself on the back. Then continue on to the next section. We’ve got work to do. From 01096e96fa4ce2e147b0ff9ac7b665743e7c0b8b Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 10:14:54 -0700 Subject: [PATCH 06/23] you are not a project, a file does not actively solicit --- getting-started/preparing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/preparing.md b/getting-started/preparing.md index 82b3ad72acb..45d593b214c 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -54,7 +54,7 @@ A CONTRIBUTING file tells your audience how to participate in your project. For In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions. Remember that no two open source projects are alike. Write down rules that work best for you and your lifestyle. For example, you may want to convey that you are only accepting certain types of contributions, tell participants how long they should expect to hear a response from you, or explain how (or how not) to get in touch with you. -If you are a community project, you can use the CONTRIBUTING file to actively solicit the types of contributions you’re looking for. Using a warm, friendly tone and offering specific contribution suggestions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. +The CONTRIBUTING file is a place to clearly state the types of contributions you’re looking for. Using a warm, friendly tone and offering specific contribution suggestions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. You should reference your CONTRIBUTING file in your README. In your README, give your audience a quick overview of how contributions work, then link to the CONTRIBUTING file for more information. From 18757d491596968e2ab9d0f014f42ecfaaf562da Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 10:29:56 -0700 Subject: [PATCH 07/23] write->establish coc... - vision, philosopy etc if project has one bigger scope than CoC - mention contributor covenant - behavior, bigger scope than just communication --- getting-started/preparing.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/getting-started/preparing.md b/getting-started/preparing.md index 45d593b214c..2babb6fc882 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -60,15 +60,15 @@ You should reference your CONTRIBUTING file in your README. In your README, give If you place your CONTRIBUTING file in the root directory, GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. -## Writing a code of conduct +## Establishing a code of conduct -Finally, a code of conduct helps set ground rules for communication among your project’s participants. The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Angular Code of Conduct](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md) are two good examples. +Finally, a code of conduct helps set ground rules for behavior of your project’s participants. This is especially valuable if you’re launching an open source project for a community or company. -A code of conduct is a place to convey the values or philosophy that define your project. This is especially valuable if you’re a community or company launching an open source project. +In addition to communicating your expectations, you should describe what happens if someone violates the code of conduct, and where someone can report such behavior. We recommend placing a CODE_OF_CONDUCT file in your project’s root directory. -Codes of conduct help protect not just your participants, but yourself. As you maintain your project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive about these expectations reduces the likelihood that you, or others, will become fatigued with your project later on. You can read more about enforcing codes of conduct [here](../../troubleshooting/conduct/). +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Angular Code of Conduct](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md) are two good examples. The [Contributor Covenant](http://contributor-covenant.org/) is a code of conduct used by [many projects](http://contributor-covenant.org/adopters/). -In addition to communicating your expectations, you should describe what happens if someone violates the code of conduct, and where someone can report such behavior. We recommend placing a CODE_OF_CONDUCT file in your root directory. +Codes of conduct help protect not just your participants, but yourself. As you maintain your project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive about these expectations reduces the likelihood that you, or others, will become fatigued with your project later on. You can read more about enforcing codes of conduct [here](../../troubleshooting/conduct/). ## What’s next? From 36b9bd02ab5b0b70983095abb9f6427cdb8c5532 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 10:37:33 -0700 Subject: [PATCH 08/23] less stale link, essential link --- getting-started/preparing.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/getting-started/preparing.md b/getting-started/preparing.md index 2babb6fc882..d315bdc57bb 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -82,7 +82,7 @@ Sometimes, it will take a long time before people notice your open source projec ### Further reading * Licenses - * [https://github.com/blog/1530-choosing-an-open-source-license](https://github.com/blog/1530-choosing-an-open-source-license) + * [https://help.github.com/articles/open-source-licensing/](https://help.github.com/articles/open-source-licensing/) * [http://choosealicense.com](http://choosealicense.com) * READMEs * [http://tom.preston-werner.com/2010/08/23/readme-driven-development.html](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) @@ -96,6 +96,7 @@ Sometimes, it will take a long time before people notice your open source projec * [https://github.com/nayafia/contributing-template](https://github.com/nayafia/contributing-template) * [http://mozillascience.github.io/working-open-workshop/contributing/](http://mozillascience.github.io/working-open-workshop/contributing/) * Codes of conduct + * [http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations](http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations) * [http://contributor-covenant.org/](http://contributor-covenant.org/) * [https://github.com/django/code-of-conduct](https://github.com/django/code-of-conduct) * [https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) From 7655d8e57e97c3988ce56cf641bcff0266b51c3e Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 10:40:54 -0700 Subject: [PATCH 09/23] pertinent link, rm not final finally --- getting-started/setting-expectations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/getting-started/setting-expectations.md b/getting-started/setting-expectations.md index 80ff9073e5e..855a77d8806 100644 --- a/getting-started/setting-expectations.md +++ b/getting-started/setting-expectations.md @@ -13,7 +13,7 @@ Let’s start by defining your goals. Simply put: *why are you open sourcing thi There is no one right answer to this question. You may find that you have multiple goals for a single project, or that different projects have different goals. The most important thing is to be honest with yourself. -Here are some examples of reasons why people open source their work: +Here are some examples of [reasons](http://ben.balter.com/2015/11/23/why-open-source/) why people open source their work: * An individual wants to show off his or her portfolio * An individual or company wants others to use what they’ve created @@ -33,7 +33,7 @@ If you’re hoping to get feedback on something you’ve created, consider askin ## Figure out what others need from you -Finally, open sourcing a project is a two-way street. People who use your project will probably ask you for things, too. +Open sourcing a project is a two-way street. People who use your project will probably ask you for things, too. Try to anticipate these needs beforehand so you can add them to your project from the beginning. Successful open source projects try to document as much as they can in public. Much like reusable pieces of code, reusable information means less people need to ask you the same questions over and over again. (That means less work for you!) From ec8f0fed7b5954cd9cf39b1eb7abcecae2a59bca Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 11:50:59 -0700 Subject: [PATCH 10/23] wording --- getting-started/legal.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index ccb09510b28..1eb6b897ec7 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -9,30 +9,30 @@ Thankfully, you don’t have to start from scratch. This section will make sure **(Do we need a legal disclaimer for this piece?)** ## Table of Contents - 1. [Why do I need an open source license?](#why-do-i-need-an-open-source-license) 2. [Which open source license is appropriate for me?](#which-open-source-license-is-appropriate-for-me) 3. [Do I need a contributor agreement in addition to my open source license?](#do-i-need-a-contributor-agreement-in-addition-to-my-open-source-license) -4. [I’m a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) +4. [I’m at a company open sourcing a project. What does my legal team need to know?](#intimidatinga-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) + ## Why do I need an open source license? -When you publish a creative work (which includes code), your work is under copyright by default. Unless you include a license that specifies otherwise, nobody can copy or modify your work without being subject to copyright law. +When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), nobody includes you. -An open source license guarantees that others can use, modify and share your project. It protects both you and anybody else who might interact with your project. +An open source license guarantees that everyone can use, modify and share your project. It protects both you and anybody else who might interact with your project. -Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work is otherwise copyrighted unless you add an open source license. +Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work otherwise comes with no permissions unless you add an open source license. ## Which open source license is appropriate for me? -There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that comply with the generally accepted definition of open source. Here is a breakdown of three of the most common licenses. +There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that conform with the generally accepted definition of open source. Here is a breakdown of three of the most common licenses. -* **For individuals releasing an open source project with no deeper interests,** consider the [MIT License](http://choosealicense.com/licenses/mit/), which is simple and permissive. People can use your project for whatever they like, as long as they provide attribution back to you and don’t hold you liable for anything. -* **For companies releasing an open source project,** consider the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/). The Apache 2.0 license is appropriate for project owners who are concerned about patents. It provides an express grant of patent rights from contributors. -* **For those who care about keeping their code in the public domain,** consider the [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/), which is a copyleft license. That means anyone who distributes your code, or a derivative of your work, must make the source available under the same terms. It also provides an express grant of patent rights from contributors. +* **For individuals releasing an open source project with no deeper interests,** consider the [MIT License](http://choosealicense.com/licenses/mit/), a short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code. +* **For companies releasing an open source project,** consider the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/), also a permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code. +* **For those who care about keeping their code open source,** consider the [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/), which is a strong copyleft license with permissions conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Copyright and license notices must be preserved. Contributors provide an express grant of patent rights. -If your open source project isn’t software, consider a Creative Commons or other type of license that’s tailored for media. You can read more about choosing a non-software license [here](http://choosealicense.com/non-software/). +If your open source project isn’t software, one of the above licenses will still work, but you can also read about open licenses for domains such as open source hardware design, data, books, music, video, documentation, and fonts [here](http://choosealicense.com/non-software/). When you create a new project on GitHub, you are given the option to select a license. Including one of the above licenses will make your GitHub project open source. If you’d like to see other license options, check out [Choose a License](http://choosealicense.com) to find the right license for you. @@ -55,11 +55,14 @@ You can also consider using a DCO, which is less cumbersome than signing an agre If you are a company open sourcing a project, there are a few legal aspects you may want to consider. + * **Existing Intellectual Property (IP):** Consider whether there is anything existing in the project that might fall under company IP, which you would not want to make available to the general public. If so, you could open source the rest of your project, but keep the IP private. * **Future Patents:** If you are concerned that there may be patents associated with your project later on, use an open source license that provides patent protections (such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/)). * **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects, especially if you expect employees to maintain the project. A clear corporate policy will reduce confusion among your employees and encourage them to make open source contributions during work hours. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). * **Trademarks:** Double check that your project’s name does not conflict with any existing trademarks. If you use your own company trademarks in the project, check that it does not cause any conflicts. + + These are starting points for conversation. Be sure to run any open source project by your legal team before proceeding! ## I’m using others’ open source code. What does my legal team need to know? @@ -74,10 +77,10 @@ If you use others’ open source code to create anything that could be considere To learn more about the implications of different open source licenses, [TLDRLegal](https://tldrlegal.com/) is a great resource. + ### Further reading * [http://choosealicense.com](http://choosealicense.com) -* [https://tldrlegal.com/](https://tldrlegal.com/) * [https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) * [https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/](https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/) * [https://www.joyent.com/blog/broadening-node-js-contributions](https://www.joyent.com/blog/broadening-node-js-contributions) From aa27772db4eb3a83caec536522153db781ed2ca0 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Mon, 15 Aug 2016 14:21:28 -0500 Subject: [PATCH 11/23] Fix merge conflict --- getting-started/preparing.md | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/getting-started/preparing.md b/getting-started/preparing.md index 400145c55a2..abb3b9adf4f 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -82,13 +82,8 @@ Sometimes, it will take a long time before people notice your open source projec ## Further reading * Licenses -<<<<<<< HEAD - * [https://help.github.com/articles/open-source-licensing/](https://help.github.com/articles/open-source-licensing/) - * [http://choosealicense.com](http://choosealicense.com) -======= - * [Choosing an Open Source License](https://github.com/blog/1530-choosing-an-open-source-license) by Phil Haack + * [Open source licensing](https://help.github.com/articles/open-source-licensing/) * [ChooseALicense.com](http://choosealicense.com) ->>>>>>> origin/gh-pages * READMEs * [Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) by Tom Preston-Werner * [Awesome README](https://github.com/matiassingers/awesome-readme) @@ -101,15 +96,8 @@ Sometimes, it will take a long time before people notice your open source projec * [Contributing Guides: A Template](https://github.com/nayafia/contributing-template) by @nayafia * [Wrangling Web Contributions: How to Build a CONTRIBUTING.md](http://mozillascience.github.io/working-open-workshop/contributing/) * Codes of conduct -<<<<<<< HEAD - * [http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations](http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations) - * [http://contributor-covenant.org/](http://contributor-covenant.org/) - * [https://github.com/django/code-of-conduct](https://github.com/django/code-of-conduct) - * [https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) - * [https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines/](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines/) -======= + * [Code of conduct evaluations](http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations) from the Geek Feminism wiki * [Contributor Covenant](http://contributor-covenant.org/) * [Django Code of Conduct](https://github.com/django/code-of-conduct) * [HOWTO design a code of conduct for your community](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) by Valerie Aurora * [Docker community guidelines](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines) ->>>>>>> origin/gh-pages From 6441d5accc502e163c4f682d0d2982b75b307b3e Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Mon, 15 Aug 2016 14:25:06 -0500 Subject: [PATCH 12/23] Fix link --- getting-started/legal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index 68d87a60420..1d7dd418467 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -12,7 +12,7 @@ Thankfully, you don’t have to start from scratch. This section will make sure 1. [Why do I need an open source license?](#why-do-i-need-an-open-source-license) 2. [Which open source license is appropriate for me?](#which-open-source-license-is-appropriate-for-me) 3. [Do I need a contributor agreement in addition to my open source license?](#do-i-need-a-contributor-agreement-in-addition-to-my-open-source-license) -4. [I’m at a company open sourcing a project. What does my legal team need to know?](#intimidatinga-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) +4. [I’m at a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) From 5ffcb80c21c26344ee453c85b5e7d9414b2171f4 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Mon, 15 Aug 2016 14:26:15 -0500 Subject: [PATCH 13/23] Fix lint warnings --- getting-started/legal.md | 5 +---- getting-started/preparing.md | 2 -- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index 1d7dd418467..6da0d93ffdd 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -9,13 +9,13 @@ Thankfully, you don’t have to start from scratch. This section will make sure **(Do we need a legal disclaimer for this piece?)** ## Table of Contents + 1. [Why do I need an open source license?](#why-do-i-need-an-open-source-license) 2. [Which open source license is appropriate for me?](#which-open-source-license-is-appropriate-for-me) 3. [Do I need a contributor agreement in addition to my open source license?](#do-i-need-a-contributor-agreement-in-addition-to-my-open-source-license) 4. [I’m at a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) - ## Why do I need an open source license? When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), nobody includes you. @@ -55,14 +55,11 @@ You can also consider using a DCO, which is less cumbersome than signing an agre If you are a company open sourcing a project, there are a few legal aspects you may want to consider. - * **Existing Intellectual Property (IP):** Consider whether there is anything existing in the project that might fall under company IP, which you would not want to make available to the general public. If so, you could open source the rest of your project, but keep the IP private. * **Future Patents:** If you are concerned that there may be patents associated with your project later on, use an open source license that provides patent protections (such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/)). * **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects, especially if you expect employees to maintain the project. A clear corporate policy will reduce confusion among your employees and encourage them to make open source contributions during work hours. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). * **Trademarks:** Double check that your project’s name does not conflict with any existing trademarks. If you use your own company trademarks in the project, check that it does not cause any conflicts. - - These are starting points for conversation. Be sure to run any open source project by your legal team before proceeding! ## I’m using others’ open source code. What does my legal team need to know? diff --git a/getting-started/preparing.md b/getting-started/preparing.md index abb3b9adf4f..dc139488e32 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -47,7 +47,6 @@ As a maintainer, READMEs are an opportunity to clarify your goals in public. If When you include a README file in the root directory, GitHub will automatically display it on your project repository’s homepage. It will be the first thing someone sees when they arrive. - ## Setting your contributing guidelines A CONTRIBUTING file tells your audience how to participate in your project. For example, you might want to tell your reader how to create an issue, file a bug report, test fixes, or format code. @@ -70,7 +69,6 @@ The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [An Codes of conduct help protect not just your participants, but yourself. As you maintain your project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive about these expectations reduces the likelihood that you, or others, will become fatigued with your project later on. You can read more about enforcing codes of conduct [here](../../troubleshooting/conduct/). - ## What’s next? Now that you have these four files in the root directory of your project, you’re ready to open source your project! Click "publish" and pat yourself on the back. Then continue on to the next section. We’ve got work to do. From daad3f0571a79566719c10a7777f2951ee7e9d16 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 17:55:23 -0700 Subject: [PATCH 14/23] CLA section edits --- getting-started/legal.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index 6da0d93ffdd..0a584d7b945 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -10,9 +10,9 @@ Thankfully, you don’t have to start from scratch. This section will make sure ## Table of Contents -1. [Why do I need an open source license?](#why-do-i-need-an-open-source-license) -2. [Which open source license is appropriate for me?](#which-open-source-license-is-appropriate-for-me) -3. [Do I need a contributor agreement in addition to my open source license?](#do-i-need-a-contributor-agreement-in-addition-to-my-open-source-license) +1. [Why does my project need an open source license?](#why-does-my-project-need-an-open-source-license) +2. [Which open source license is appropriate for my project?](#which-open-source-license-is-appropriate-for-my-project) +3. [Does my project need a contributor agreement in addition to its open source license?](#does-my-project-need-a-contributor-agreement-in-addition-to-its-open-source-license) 4. [I’m at a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) @@ -24,7 +24,7 @@ An open source license guarantees that everyone can use, modify and share your p Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work otherwise comes with no permissions unless you add an open source license. -## Which open source license is appropriate for me? +## Which open source license is appropriate for my project? There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that conform with the generally accepted definition of open source. Here is a breakdown of three of the most common licenses. @@ -36,20 +36,19 @@ If your open source project isn’t software, one of the above licenses will sti When you create a new project on GitHub, you are given the option to select a license. Including one of the above licenses will make your GitHub project open source. If you’d like to see other license options, check out [Choose a License](http://choosealicense.com) to find the right license for you. -## Do I need a contributor agreement in addition to my open source license? +## Does my project need a contributor agreement in addition to its open source license? -Some open source projects, particularly when companies are involved, require a contributor agreement. These are legal agreements that must be signed by a contributor before they can make changes to the project. +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. -Contributor agreements are used when the project owner wants to protect themselves, and their users, from future copyright claims from contributors. There are two major types of contributor agreements: +An additional agreement adds a variable amount of overhead to accepting contributions, depending on the project and implementation, ranging from minimal for simple agreements that only affirm, with a single click, that the contributor has the rights necessary to contribute under the project open source license, to open-ended, for complex and asymmetric agreements that need legal review and sign-off from contributors’ employers. -* [Contributor License Agreement (CLA)](https://www.apache.org/licenses/icla.txt): A CLA explicitly grants the project owner the right to distribute all contributions made by the contributor, either by assigning copyright or granting an irrevocable license. Some projects specify that CLAs only need to be signed for “non-trivial changes”: for example, fixing a significant bug rather than a small typo. -* [Developer Certificate of Origin (DCO)](http://developercertificate.org/): A DCO certifies that the contributor has the right to make their contribution and that they allow the project owner to use it in other distributions. Unlike a CLA, which must be explicitly signed, a DCO is required as a signature when the contribution is submitted, or is part of the project’s contribution policy. +Here are some situations for which you may need to deploy an additional contribution agreement for your project: -There are some concerns associated with CLAs in particular. CLAs can be perceived as not friendly to the project’s community. They can also create a lot of administrative work for the project owner. Finally, CLAs increase the barrier to community participation by adding more paperwork than some believe is necessary. +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps based on a feeling that bare open source licenses cannot be robust in theory, even though they are in practice. If this is the only concern, an additional contributor agreement that affirms the project open source license should suffice. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is an example of such a light additional contributor agreement. For some projects, a [Developer Certificate of Origin](http://developercertificate.org/) can be an even lighter alternative. +* Your project is under an open source license such as MIT that does not include an express patent grant, and you need a patent grant from all contributors, some of who may work for companies with large patent portfolios that could be used to target you or the project’s other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement] is an example of such an agreement. -Many projects that use a CLA are concerned about patents. If you have patent concerns, consider adopting a license with patent protections instead, such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/), in which contributors expressly grant patent rights. - -You can also consider using a DCO, which is less cumbersome than signing an agreement and provides similar benefits to a CLA. If your project is on GitHub, include the DCO in your CONTRIBUTING.md file, which is automatically referenced when someone submits a pull request. Or you can require that contributors include the DCO as a signature when they submit a pull request. +If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. ## I’m a company open sourcing a project. What does my legal team need to know? From b79ca97a043e2068ece8cbb9bd74657bb62afbb2 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 17:59:21 -0700 Subject: [PATCH 15/23] fix internal link --- getting-started/legal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index 0a584d7b945..74d7d1f69da 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -16,7 +16,7 @@ Thankfully, you don’t have to start from scratch. This section will make sure 4. [I’m at a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) -## Why do I need an open source license? +## Why does my project need an open source license? When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), nobody includes you. From 0c62362b78c7410965c9f98c041233eb5285d78c Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Mon, 15 Aug 2016 18:03:26 -0700 Subject: [PATCH 16/23] fix warnings --- getting-started/legal.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index 74d7d1f69da..4e30edf3f36 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -12,7 +12,7 @@ Thankfully, you don’t have to start from scratch. This section will make sure 1. [Why does my project need an open source license?](#why-does-my-project-need-an-open-source-license) 2. [Which open source license is appropriate for my project?](#which-open-source-license-is-appropriate-for-my-project) -3. [Does my project need a contributor agreement in addition to its open source license?](#does-my-project-need-a-contributor-agreement-in-addition-to-its-open-source-license) +3. [Does my project need an additional contributor agreement?](#does-my-project-need-an-additional-contributor-agreement) 4. [I’m at a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) @@ -36,7 +36,7 @@ If your open source project isn’t software, one of the above licenses will sti When you create a new project on GitHub, you are given the option to select a license. Including one of the above licenses will make your GitHub project open source. If you’d like to see other license options, check out [Choose a License](http://choosealicense.com) to find the right license for you. -## Does my project need a contributor agreement in addition to its open source license? +## Does my project need an additional contributor agreement? Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. @@ -46,7 +46,7 @@ Here are some situations for which you may need to deploy an additional contribu * Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps based on a feeling that bare open source licenses cannot be robust in theory, even though they are in practice. If this is the only concern, an additional contributor agreement that affirms the project open source license should suffice. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is an example of such a light additional contributor agreement. For some projects, a [Developer Certificate of Origin](http://developercertificate.org/) can be an even lighter alternative. * Your project is under an open source license such as MIT that does not include an express patent grant, and you need a patent grant from all contributors, some of who may work for companies with large patent portfolios that could be used to target you or the project’s other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement] is an example of such an agreement. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example of such an agreement. If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. From efd97130a79c5e99c25a8b7851b01fb39af61448 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Tue, 16 Aug 2016 11:08:41 -0700 Subject: [PATCH 17/23] @aitchabee feedback https://github.com/github/open-source-handbook/pull/20#pullrequestreview-4865 --- getting-started/index.md | 2 +- getting-started/legal.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/getting-started/index.md b/getting-started/index.md index c9ba65e69b9..e98a33220dc 100644 --- a/getting-started/index.md +++ b/getting-started/index.md @@ -15,7 +15,7 @@ When you publish a project on GitHub, you have the option to make the repository Open source licenses grant permission to everyone to use, modify, and share licensed software for any purpose, subject to certain conditions, depending on the license. -Public repositories on GitHub are covered by [GitHub’s Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to [include an open source license](https://help.github.com/articles/open-source-licensing/). For example, someone cannot legally use your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) +Public repositories on GitHub are covered by [GitHub’s Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to [include an open source license](https://help.github.com/articles/open-source-licensing/). For example, someone cannot legally use any part of your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) ## Open source is more than just source code with a license diff --git a/getting-started/legal.md b/getting-started/legal.md index 4e30edf3f36..a2284250612 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -18,7 +18,7 @@ Thankfully, you don’t have to start from scratch. This section will make sure ## Why does my project need an open source license? -When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), nobody includes you. +When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), "nobody" starts including you. An open source license guarantees that everyone can use, modify and share your project. It protects both you and anybody else who might interact with your project. From 9040bbafe9bbd06ba1f45256770f632abbf83f3e Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Tue, 16 Aug 2016 16:11:27 -0700 Subject: [PATCH 18/23] rewrite "which license" section --- getting-started/legal.md | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index a2284250612..e0b50535dd2 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -13,7 +13,7 @@ Thankfully, you don’t have to start from scratch. This section will make sure 1. [Why does my project need an open source license?](#why-does-my-project-need-an-open-source-license) 2. [Which open source license is appropriate for my project?](#which-open-source-license-is-appropriate-for-my-project) 3. [Does my project need an additional contributor agreement?](#does-my-project-need-an-additional-contributor-agreement) -4. [I’m at a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) +4. [What does my company’s legal team need to know?](#what-does-my-companys-legal-team-need-to-know) 5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) ## Why does my project need an open source license? @@ -24,17 +24,24 @@ An open source license guarantees that everyone can use, modify and share your p Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work otherwise comes with no permissions unless you add an open source license. +Also, the licenses of your project’s dependencies, the communities you hope will use your project, or your employer’s policies may effectively require your project to use an open source license, even a specific open source license. We’ll cover these situations below. + ## Which open source license is appropriate for my project? -There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that conform with the generally accepted definition of open source. Here is a breakdown of three of the most common licenses. +If you’re starting from a blank slate, it’s hard to go wrong with the MIT License. It’s short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You’ll be able to release the project under a different license if and when your situation calls for doing so. + +Otherwise, the appropriate open source license for your project depends on your situation and objectives. + +Your project very likely has or will have **dependencies**. For example, if you’re open sourcing a Node.js project, you’ll be using libraries from the Node Package Manager (npm). Those dependencies will each have an open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. + +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. + +You might have in mind 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 a license popular in the relevant community. For example, MIT is the most popular license for [npm libraries](https://libraries.io/npm). Do you want your project to be most appealing to large businesses that want to have an express patent license from all contributors? Apache 2.0 has you (and them) covered. Or do you want your project to be most appealing to contributors who do not want to allow their contributions to be used in closed source software? GPLv3 or (if they also do not wish to contribute to closed source services) AGPLv3 will go over well. -* **For individuals releasing an open source project with no deeper interests,** consider the [MIT License](http://choosealicense.com/licenses/mit/), a short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code. -* **For companies releasing an open source project,** consider the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/), also a permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code. -* **For those who care about keeping their code open source,** consider the [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/), which is a strong copyleft license with permissions conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Copyright and license notices must be preserved. Contributors provide an express grant of patent rights. +Your **company** may have specific licensing requirements for projects it open sources. For example, it may require a permissive license so that the company can use your project 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 objectives for your project related to standards, social responsibility, or transparency, any of which could provide a rationale for a particular licensing strategy. Talk to your company’s legal department (also see below). -If your open source project isn’t software, one of the above licenses will still work, but you can also read about open licenses for domains such as open source hardware design, data, books, music, video, documentation, and fonts [here](http://choosealicense.com/non-software/). +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](http://choosealicense.com) to find the right license for your project, even if it [isn’t software](http://choosealicense.com/non-software/). -When you create a new project on GitHub, you are given the option to select a license. Including one of the above licenses will make your GitHub project open source. If you’d like to see other license options, check out [Choose a License](http://choosealicense.com) to find the right license for you. ## Does my project need an additional contributor agreement? @@ -50,7 +57,7 @@ Here are some situations for which you may need to deploy an additional contribu If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. -## I’m a company open sourcing a project. What does my legal team need to know? +## What does my company’s legal team need to know? If you are a company open sourcing a project, there are a few legal aspects you may want to consider. @@ -71,11 +78,11 @@ Other open source licenses, like the MIT license, are very permissive. They may If you use others’ open source code to create anything that could be considered company IP, you will want to read the terms of the license carefully to understand your patent rights. -To learn more about the implications of different open source licenses, [TLDRLegal](https://tldrlegal.com/) is a great resource. ## Further reading * [ChooseALicense.com](http://choosealicense.com) +* [Over 70 approved licenses](https://opensource.org/licenses/alphabetical) that conform with the generally accepted definition of open source * [A Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) * [Introducing The Docker Developer Certificate Of Origin](https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/) by Nick Stinemates * [Broadening Node.js Contributions From e3cea091699d056d07bd1af9b0a14f2e6c6ab5e6 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Tue, 16 Aug 2016 16:13:32 -0700 Subject: [PATCH 19/23] fix dupe blank lines warning --- getting-started/legal.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index e0b50535dd2..dfe415626d6 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -42,7 +42,6 @@ Your **company** may have specific licensing requirements for projects it open s 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](http://choosealicense.com) to find the right license for your project, even if it [isn’t software](http://choosealicense.com/non-software/). - ## Does my project need an additional contributor agreement? Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. @@ -78,7 +77,6 @@ Other open source licenses, like the MIT license, are very permissive. They may If you use others’ open source code to create anything that could be considered company IP, you will want to read the terms of the license carefully to understand your patent rights. - ## Further reading * [ChooseALicense.com](http://choosealicense.com) From 3353b2197e30da1c69f29cf72b6c7aca0ba7caa2 Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Wed, 17 Aug 2016 12:03:13 -0700 Subject: [PATCH 20/23] legal team considerations --- getting-started/branding.md | 16 +++++++++------- getting-started/legal.md | 27 ++++++++++++++++----------- 2 files changed, 25 insertions(+), 18 deletions(-) diff --git a/getting-started/branding.md b/getting-started/branding.md index cf2c19e886a..957c3acbc24 100644 --- a/getting-started/branding.md +++ b/getting-started/branding.md @@ -17,7 +17,7 @@ Consider clarity above all. Puns are fun, but remember that some jokes might not ## Avoiding name conflicts -Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov). +Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov/trademarks-application-process/search-trademark-database). If you’re at a company, this is one of the things your [legal team can help you with](./legal/#what-does-my-companys-legal-team-need-to-know). You’ll also want to look for open source projects with a similar name, especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you will confuse your audience and make it less likely that anyone will use what you’ve created. You can check for similar project names [here](http://ivantomic.com/projects/ospnc/). @@ -31,11 +31,9 @@ Throughout the life of your project, you’ll do a lot of writing: READMEs, tuto [@janl](https://github.com/janl) discovered that the way he spoke to others helped create a positive brand for [CouchDB](https://github.com/apache/couchdb): -> When I started out at CouchDB and we finally joined the ASF \[Apache Software Foundation\] and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style. \[...\] -> -> Every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud. [^1] +*When I started out at CouchDB and we finally joined the ASF [Apache Software Foundation] and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style. [...]* -[^1]: [Sustainable Open Source](http://writing.jan.io/2015/11/20/sustainable-open-source.html) by [@janl](https://github.com/janl) +*Every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud.* [1] Beyond how you write words, your coding style may also become part of your project’s brand. For example, [Angular](https://github.com/johnpapa/angular-styleguide) and [jQuery](http://contribute.jquery.org/style-guide/js/) are two projects with rigorous coding styles and guidelines. @@ -43,6 +41,10 @@ It isn’t necessary to write a style guide for your project when you’re just We’re almost there! Next, we’ll walk you through a few components that every open source project should include when you launch. -## Further reading +### Footnotes -* [Choose a Good Name](http://producingoss.com/en/getting-started.html#choosing-a-name) from _Producing Open Source Software_ by Karl Fogel +[1] [http://writing.jan.io/2015/11/20/sustainable-open-source.html](http://writing.jan.io/2015/11/20/sustainable-open-source.html) + +### Further reading + +* [http://producingoss.com/en/getting-started.html#choosing-a-name](http://producingoss.com/en/getting-started.html#choosing-a-name) diff --git a/getting-started/legal.md b/getting-started/legal.md index dfe415626d6..dfac91b35a1 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -58,24 +58,28 @@ If you do need to use an additional contributor agreement with your project, con ## What does my company’s legal team need to know? -If you are a company open sourcing a project, there are a few legal aspects you may want to consider. +First, they should know that you’re open sourcing a project. -* **Existing Intellectual Property (IP):** Consider whether there is anything existing in the project that might fall under company IP, which you would not want to make available to the general public. If so, you could open source the rest of your project, but keep the IP private. -* **Future Patents:** If you are concerned that there may be patents associated with your project later on, use an open source license that provides patent protections (such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/)). -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects, especially if you expect employees to maintain the project. A clear corporate policy will reduce confusion among your employees and encourage them to make open source contributions during work hours. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). -* **Trademarks:** Double check that your project’s name does not conflict with any existing trademarks. If you use your own company trademarks in the project, check that it does not cause any conflicts. +For better or worse, consider letting them know even if it’s a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company’s business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company’ professional learning and development objectives for you), or avoid working on your project until you find a better company. -These are starting points for conversation. Be sure to run any open source project by your legal team before proceeding! +If you’re open sourcing a project for your company, then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company’s business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: -## I’m using others’ open source code. What does my legal team need to know? +* **Third party material:** Does your project have dependencies created by others or otherwise include or use others’ code? If these are open source, you’ll need to comply with the materials’ open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you’re meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others’ code that does’t have an open source license, you’ll probably have to ask the third party maintainers to [add an open source license](http://choosealicense.com/no-license/#for-users), and if you can’t get one, stop using their code in your project. +* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material the you want to keep private. +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you’re expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **Trademarks:** Double check that your project’s name [does not conflict with any existing trademarks](./branding/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. +* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. -The implications of using others’ open source code in your software depends on that project’s license. (If the project does not have an open source license, don’t use it!) +If you’re releasing your company’s first open source project, the above is more than enough to get through (but don’t worry, most projects shouldn’t raise any major concerns). -Some open source licenses, like the GNU GPLv3, require that any software using the code must license the source under the same terms. If you are a company using code with these restrictions, you will want to proceed carefully. +Longer term your legal team can do more to help the company get more from its involvement in open source, and stay safe: -Other open source licenses, like the MIT license, are very permissive. They may still require attribution. +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company’s best interest, whether as part of their jobs or in their free time. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). +* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company’s open source strategy, they’ll be best able to help rather than hinder your efforts. +* **Compliance:** Even if your company doesn’t release any open source projects, it uses others’ open source software. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) can prevent headaches, product delays, and lawsuits. +* **Patents:** Your company may wish to join the [Open Invention Network](http://www.openinventionnetwork.com/), a shared defensive patent pool to protect members’ use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../sustaining/leadership/#do-i-need-a-legal-entity-to-support-my-project). -If you use others’ open source code to create anything that could be considered company IP, you will want to read the terms of the license carefully to understand your patent rights. ## Further reading @@ -85,3 +89,4 @@ If you use others’ open source code to create anything that could be considere * [Introducing The Docker Developer Certificate Of Origin](https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/) by Nick Stinemates * [Broadening Node.js Contributions ](https://www.joyent.com/blog/broadening-node-js-contributions) by Bryan Cantrill +* [FOSSmarks](http://fossmarks.org/) is "a practical guide to understanding trademarks in the context of Free and Open Source projects." From 31ed010275ef98909493fe34a13796a91edc0d0f Mon Sep 17 00:00:00 2001 From: Mike Linksvayer Date: Wed, 17 Aug 2016 13:40:01 -0700 Subject: [PATCH 21/23] fix internal links --- getting-started/branding.md | 2 +- getting-started/legal.md | 6 ++---- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/getting-started/branding.md b/getting-started/branding.md index 957c3acbc24..f0a40e24cab 100644 --- a/getting-started/branding.md +++ b/getting-started/branding.md @@ -17,7 +17,7 @@ Consider clarity above all. Puns are fun, but remember that some jokes might not ## Avoiding name conflicts -Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov/trademarks-application-process/search-trademark-database). If you’re at a company, this is one of the things your [legal team can help you with](./legal/#what-does-my-companys-legal-team-need-to-know). +Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov/trademarks-application-process/search-trademark-database). If you’re at a company, this is one of the things your [legal team can help you with](../legal/#what-does-my-companys-legal-team-need-to-know). You’ll also want to look for open source projects with a similar name, especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you will confuse your audience and make it less likely that anyone will use what you’ve created. You can check for similar project names [here](http://ivantomic.com/projects/ospnc/). diff --git a/getting-started/legal.md b/getting-started/legal.md index dfac91b35a1..b999b62a2a8 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -14,7 +14,6 @@ Thankfully, you don’t have to start from scratch. This section will make sure 2. [Which open source license is appropriate for my project?](#which-open-source-license-is-appropriate-for-my-project) 3. [Does my project need an additional contributor agreement?](#does-my-project-need-an-additional-contributor-agreement) 4. [What does my company’s legal team need to know?](#what-does-my-companys-legal-team-need-to-know) -5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) ## Why does my project need an open source license? @@ -67,7 +66,7 @@ If you’re open sourcing a project for your company, then definitely let them k * **Third party material:** Does your project have dependencies created by others or otherwise include or use others’ code? If these are open source, you’ll need to comply with the materials’ open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you’re meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others’ code that does’t have an open source license, you’ll probably have to ask the third party maintainers to [add an open source license](http://choosealicense.com/no-license/#for-users), and if you can’t get one, stop using their code in your project. * **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material the you want to keep private. * **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you’re expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). -* **Trademarks:** Double check that your project’s name [does not conflict with any existing trademarks](./branding/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. +* **Trademarks:** Double check that your project’s name [does not conflict with any existing trademarks](../branding/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. * **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. If you’re releasing your company’s first open source project, the above is more than enough to get through (but don’t worry, most projects shouldn’t raise any major concerns). @@ -78,8 +77,7 @@ Longer term your legal team can do more to help the company get more from its in * **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company’s open source strategy, they’ll be best able to help rather than hinder your efforts. * **Compliance:** Even if your company doesn’t release any open source projects, it uses others’ open source software. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) can prevent headaches, product delays, and lawsuits. * **Patents:** Your company may wish to join the [Open Invention Network](http://www.openinventionnetwork.com/), a shared defensive patent pool to protect members’ use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). -* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../sustaining/leadership/#do-i-need-a-legal-entity-to-support-my-project). - +* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../../sustaining/leadership/#do-i-need-a-legal-entity-to-support-my-project). ## Further reading From f4560c893c5f13c883ebbdee84b24a2b1c31ee8a Mon Sep 17 00:00:00 2001 From: Nadia Eghbal Date: Thu, 18 Aug 2016 11:36:27 -0700 Subject: [PATCH 22/23] make legal.md friendlier sounding --- getting-started/legal.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index a03cf5bb142..7ebfc48cf44 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -27,17 +27,21 @@ Also, the licenses of your project’s dependencies, the communities you hope wi ## Which open source license is appropriate for my project? -If you’re starting from a blank slate, it’s hard to go wrong with the MIT License. It’s short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You’ll be able to release the project under a different license if and when your situation calls for doing so. +If you’re starting from a blank slate, it’s hard to go wrong with the [MIT License](http://choosealicense.com/licenses/mit/). It’s short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You’ll be able to release the project under a different license if you ever need to. -Otherwise, the appropriate open source license for your project depends on your situation and objectives. +Otherwise, picking the right open source license for your project depends on your objectives. -Your project very likely has or will have **dependencies**. For example, if you’re open sourcing a Node.js project, you’ll be using libraries from the Node Package Manager (npm). Those dependencies will each have an open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. +Your project very likely has (or will have) **dependencies**. For example, if you’re open sourcing a Node.js project, you’ll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. -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. +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. -You might have in mind 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 a license popular in the relevant community. For example, MIT is the most popular license for [npm libraries](https://libraries.io/npm). Do you want your project to be most appealing to large businesses that want to have an express patent license from all contributors? Apache 2.0 has you (and them) covered. Or do you want your project to be most appealing to contributors who do not want to allow their contributions to be used in closed source software? GPLv3 or (if they also do not wish to contribute to closed source services) AGPLv3 will go over well. +You may also want to consider the **communities** you hope will use and contribute to your project: -Your **company** may have specific licensing requirements for projects it open sources. For example, it may require a permissive license so that the company can use your project 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 objectives for your project related to standards, social responsibility, or transparency, any of which could provide a rationale for a particular licensing strategy. Talk to your company’s legal department (also see below). +* **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](http://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/npm). +* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](http://choosealicense.com/licenses/apache-2.0/) has you (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](http://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](http://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 license so that the company can use your project 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 (also see below). 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](http://choosealicense.com) to find the right license for your project, even if it [isn’t software](http://choosealicense.com/non-software/). From 7de78c18b04364ba0bcc764ccf5529970decc46e Mon Sep 17 00:00:00 2001 From: Nadia Eghbal Date: Thu, 18 Aug 2016 11:51:11 -0700 Subject: [PATCH 23/23] edit contributor agreement section making the language simpler and friendlier --- getting-started/legal.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/getting-started/legal.md b/getting-started/legal.md index 7ebfc48cf44..185027b2f03 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -49,13 +49,15 @@ When you create a new project on GitHub, you are given the option to select a li Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. -An additional agreement adds a variable amount of overhead to accepting contributions, depending on the project and implementation, ranging from minimal for simple agreements that only affirm, with a single click, that the contributor has the rights necessary to contribute under the project open source license, to open-ended, for complex and asymmetric agreements that need legal review and sign-off from contributors’ employers. +Contributor agreements can create additional administrative work for project maintainers. How much work these agreements add depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors’ employers. -Here are some situations for which you may need to deploy an additional contribution agreement for your project: +In addition, contributor agreements are sometimes perceived as not friendly to the project’s community. They can also increase the barrier to community participation by adding more paperwork than some believe is necessary. -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps based on a feeling that bare open source licenses cannot be robust in theory, even though they are in practice. If this is the only concern, an additional contributor agreement that affirms the project open source license should suffice. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is an example of such a light additional contributor agreement. For some projects, a [Developer Certificate of Origin](http://developercertificate.org/) can be an even lighter alternative. -* Your project is under an open source license such as MIT that does not include an express patent grant, and you need a patent grant from all contributors, some of who may work for companies with large patent portfolios that could be used to target you or the project’s other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example of such an agreement. +Here are some situations where you may want to consider an additional contribution agreement for your project: + +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. For some projects, a [Developer Certificate of Origin](http://developercertificate.org/) can be an even simpler alternative. +* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project’s other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.