oss-license-strategy

MIT suits small projects where adoption matters most, while Apache-2.0 adds an express patent grant and fits projects with corporate contributors, patent exposure, or foundation plans. The Skill first audits your shipped dependencies, since a copyleft dependency can eliminate both options before preference matters.

Start with a DCO, which costs one commit flag and provides provenance. Move up to a CLA only when you need rights the license does not grant, such as relicensing, dual licensing, or selling commercial licenses of contributed code.

AGPL obliges a network operator to publish source but does not stop a competitor willing to comply. It also triggers written bans at some enterprises, such as Google's published policy, so check whether your target accounts sit behind such rules.

Relicensing requires consent from every copyright holder whose code is still present, unless a contributor agreement pre-granted that right. Published releases stay under the old license forever and can always be forked, as the Elastic, Redis, and HashiCorp cases show.

No. Neither BUSL nor SSPL is OSI-approved, and the OSI board publicly rejected SSPL in 2021. They must be called source-available, since calling them open source fails procurement filters and invites public correction.

Ship an unmodified LICENSE file at the root, per-directory boundaries for mixed repositories, SPDX-License-Identifier headers, registry metadata license fields, a NOTICE file where required, and a contribution policy enforced by an automated check on every pull request.