2.4 KiB
| layout | permalink | redirect_from | title |
|---|---|---|---|
| default | /community/ | /existing/ | Existing projects and communities |
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.
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.
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:
{: .bullets}
- Apache requires Apache License 2.0
- Cloud Native Computing Foundation dictates Apache License 2.0 by default
- GNU recommends GNU GPLv3 for most programs
- NPM packages overwhelmingly use the MIT or the very similar ISC licenses
- OpenBSD prefers the ISC License
- Rust crates are overwhelmingly licensed under both MIT and Apache License 2.0
- WordPress plugins and themes must be GNU GPLv2 (or later)
Communities come in all shapes and sizes, and more than one might be pertinent (e.g., your company). 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.