If you're contributing to or extending an existing project, it's almost always easiest to continue using that project's license. To find its license, look for a file called `LICENSE` or `COPYING`, and skim the project's `README`. If you can't find a license, [ask the maintainers](/no-permission/#for-users).
Depending on the original project's license, using the same license might be a requirement, not just the easiest thing to do. (See the "same license" condition of [some licenses](/licenses/).)
Some communities have strong preferences for particular licenses. If you want to participate in one of these, it will be easier to use their preferred license, even if you're starting a brand new project with no existing dependencies. Some examples include:
* [npm packages](https://libraries.io/search?platforms=npm) overwhelmingly use the [MIT](/licenses/mit/) or the very similar [ISC](/licenses/isc) licenses
* [Rust](https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive) crates are overwhelmingly licensed under both [MIT](/licenses/mit/) and [Apache License 2.0](/licenses/apache-2.0/)
* [Joomla](https://tm.joomla.org/joomla-license-faq.html#can-i-release-an-extension-under-a-non-gpl-license) extensions and templates must be [GNU GPLv2](/licenses/gpl-2.0/) for the PHP code.
Communities come in all shapes and sizes, and more than one community might be pertinent (e.g., keep in mind [your company](https://opensource.guide/legal/#what-does-my-companys-legal-team-need-to-know) if you work for one). The examples above are *very* well established. If the community you're building a project for doesn't have set-in-stone licensing traditions, or you don't see your project as part of any particular community, that's fine: [make your own choice of an open source license](/).
