If you're contributing to or extending an existing project, it's almost always easiest to continue using that project's license. Look for a file called `LICENSE` or `COPYING`, or a notice in the project's `README` to find out what that license is. If you can't find a license, [ask](/no-permission/#for-users).
Depending on how you're building on an existing project and what its license is, using the existing project's license for your own might not just be the easiest thing to do, but a condition on which your permission to build on the existing project rests: 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 the preferred license even if you're starting a brand new project with no existing dependencies. Examples:
* [NPM packages](https://libraries.io/search?platforms=NPM) overwhelmingly use the [MIT](/licenses/mit/) or the very similar [ISC](/licenses/isc) licenses
* [OpenBSD](https://www.openbsd.org/policy.html) prefers the [ISC License](/licenses/isc/)
* [Rust](https://rust-lang-nursery.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/)
Communities come in all shapes and sizes, and more than one might be pertinent (e.g., [your company](https://opensource.guide/legal/#what-does-my-companys-legal-team-need-to-know)). The examples above are *very* well established. If the community you see your project as a part of doesn't have set-in-stone licensing traditions, or you don't see your project as part of any particular community, that's just fine: [make your own choice of an open source license](/).
