How to Pick a License for an Open Source News Tool (October 2026)

Picking a license for an open source news tool comes down to three questions: do you want other outlets to reuse the code freely, do you want any published improvement to stay open, and do you plan to run it as a hosted service. Get those answers straight and the license names sort themselves out. MIT and Apache-2.0 for wide reuse, GPL-3.0 when you want the code to stay open, AGPL-3.0 when a hosted copy could otherwise be closed off.

The wrong choice is hard to walk back. A newsroom project that ships with missing notices or a copyleft clause in the wrong place creates obligations for every downstream partner, and relicensing later usually means asking every contributor for permission again.

What You Need

Before comparing licenses, gather the project facts. A decision made without them usually comes back in a pull request six months later.

• Intended users. Other newsrooms, freelance journalists, students, or a paying SaaS customer base.
• Repository structure. One repo or many, an application or a shared library, monorepo or separate packages.
• Dependencies. Every library, framework, template and font, with its SPDX identifier.
• Contributor involvement. Who writes code, whether they are employees, freelancers or volunteers.
• Planned commercial features. Premium tiers, hosted hosting, support contracts, branded add-ons.
• Distribution method. Published source, container images, installable packages or hosted only.
• Attribution requirements. Whether you need your newsroom credited in every reuse.
• Newsroom and funder constraints. Institutional IP policy, grant terms, nonprofit compliance rules.

If your institution owns the IP, ask before you publish anything. Universities and public broadcasters often require review before a public release, and that process takes longer than the license decision itself.

Step-by-Step: How to Pick a License for an Open Source News Tool

1. Define how the news tool will be used

Write down every use case you can defend, not just the first one. Most news tools end up doing more than they were scoped for: internal deployment first, then a public repository, then an outside newsroom running a hosted copy.

Four patterns cover nearly every case. Public-interest reuse means another outlet, a classroom or a civic group can run and extend the tool. Newsroom deployment means it stays inside your organisation and maybe a few partners. A hosted service means you run it as a website and other people never see the source. Redistribution means you ship copies of the code itself.

You can verify this step because each use case maps to a distribution model: a hosted service triggers different obligations than handing over a tarball, even under the same license.

2. Decide which rights must be preserved

The license is not one decision but a bundle of them. Separate each right before you pick, because you may want one right held back while releasing the others.

• Copy and modify. Nearly every open source license allows this.
• Redistribute. Permission to pass the code on, with or without a fee.
• Attribution. Whether the notice and copyright line must travel with the code.
• Derivative works. Whether modified versions must also carry a license, and which one.
• Patent rights. Whether the project grants an explicit patent licence or stays silent.
• Trademark and branding. Always separate from the code licence; no open source license stops someone reusing your newsroom name.
• Commercial use. Whether a company may charge for a hosted or supported version.

If the answer you care about most is “improvements must be published back,” you are looking at copyleft. If it is “anyone may use it for anything, including a paid service,” you are looking at a permissive license.

3. Check compatibility with dependencies and existing code

Run a license scan across the dependency tree and read the actual license text for anything permissive-looking but custom. Look at libraries, API clients, front-end templates, icon sets, fonts and datasets, and treat code you copied in from an old script as a separate dependency with its own terms.

The rule that bites most newsroom projects: copyleft flows one way. MIT, BSD and Apache-2.0 code can be dropped into a GPL-3.0 project. GPL code cannot be pulled into an MIT project without the whole result becoming GPL. If a library is licensed under something that forbids commercial use, you cannot use it in a project you plan to host for a fee, no matter how open your own license is.

Verify by writing a one-page inventory: dependency, version, SPDX identifier, and whether you use it at runtime or bundle it. Tools that scan a repository manifest can generate the first draft of this list.

4. Compare MIT, Apache-2.0, BSD, GPL and related licenses

Four families matter for news tools: permissive, weak copyleft, strong copyleft and network copyleft. The difference between them is not how much you are allowed to build, but what a user must do if they pass your work on.

License	Family	Commercial use	Published modifications	Patent grant	Typical newsroom fit
MIT	Permissive	Yes	No requirement	No	Small utilities, scripts, single-purpose tools
BSD-3-Clause	Permissive	Yes	No requirement	No	Similar to MIT, adds a no-endorsement clause
Apache-2.0	Permissive	Yes	No requirement	Yes	Larger tools, corporate contributors, patent exposure
MPL-2.0	Weak copyleft	Yes	Yes, for modified files	Yes	Libraries that plugins must be able to extend
LGPL-3.0	Weak copyleft	Yes	Yes, for the library	Yes	Reusable modules others link into their own tools
GPL-3.0	Strong copyleft	Yes	Yes, for derived whole works	Yes	Tools you want to keep fully open
AGPL-3.0	Network copyleft	Yes	Yes, including hosted use	Yes	Hosted platforms that competitors could close off

MIT is the shortest text and the lowest friction, and for a script under a hundred lines it is usually right. Its weakness is silence on patents, which matters if your tool uses a corporate contributor’s code. Apache-2.0 adds an explicit patent grant and a patent termination clause, plus a requirement to mark changed files, which is why many foundation-backed projects and large collaborations pick it instead.

GPL-3.0 requires that anyone distributing a derived work publishes the corresponding source under GPL-3.0. It does not stop commercial use, which is the most common myth around it; a company may sell software built on GPL code as long as it hands over the source of the derivative work. AGPL-3.0 extends that same trigger to software used over a network, which is the part that matters for a hosted newsroom product.

5. Consider open-data and public-interest requirements

Software licences do not cover your data. A public records scraper, a document corpus or a feed of parliamentary votes carries its own terms, and those terms decide whether another newsroom can query, cache or republish it.

Treat the two layers separately: an OSI-approved licence for the code, and an explicit statement for datasets covering reuse, attribution and redistribution. For civic, educational and small-newsroom reuse, a permissive code licence plus a clear data statement usually spreads the tool furthest. Reach for strong reciprocity only when a hosted fork genuinely threatens the project, and remember that a more restrictive licence narrows who can adopt it, including the newsrooms you wanted to help.

Check your funder too. Journalism grants frequently require that funded work be published under an OSI-approved licence, and some require the licence choice to be documented at the award stage rather than at launch.

6. Review contributor and ownership issues

The person who wrote the code holds copyright unless they assign it. If your contributors are employees, your employer may own the work. If they are freelancers, your contract needs to say who owns it. If they are outside journalists who sent a pull request, you have no assignment at all.

You have three workable options. A contributor license agreement assigns or grants rights under defined terms. A Developer Certificate of Origin asks contributors to affirm that they have the right to submit the code, which is lighter and very common. A clear CONTRIBUTING.md plus a DCO keeps paperwork to a click.

Also sort third-party assets early. Photos, icons, fonts and datasets often carry their own terms that will not match your code licence, and news projects pull in a lot of them.

7. Add the license to the project and record the decision

Documentation is where most newsroom projects fall short. Six things make the choice legible:

1. The full license text in a file named LICENSE at the repository root, unmodified and complete.
2. A short statement in the README naming the license and linking to the text, plus a note that the code is separate from the newsroom’s name and trademarks.
3. A per-package licence field using the SPDX identifier, so automated scans read the same thing a human does. Note whether you are offering the licence “only” or “or any later version”.
4. Third-party notices for vendored or copied code, with the original copyright and licence text intact.
5. A CONTRIBUTING.md that states the licence expectations before the first pull request arrives.
6. A short rationale, four or five lines, describing why you chose this licence. Future maintainers inherit the project; they do not inherit the debate.

You can verify the whole thing by cloning the repository fresh and checking that the LICENSE file is there, the SPDX field matches, and no dependency carries a conflicting term.

Common Mistakes

Picking by popularity. MIT is the most common license on package registries, which says nothing about your project. Fix: start from your answers in steps 1 and 2, then look up which license matches. If two licenses satisfy the same answers, take the more popular one, because it means fewer questions from adopters.

Confusing open source with public domain. A public domain dedication lets anyone do anything and gives nobody a duty to credit you. Open source keeps those rights reserved and grants them conditionally. Fix: decide whether you want the right to be credited, because only an open source license gives you that.

Ignoring dependencies. A copyleft dependency inside a permissive project, or a no-commercial-use asset in a tool you plan to host, both surface after someone else builds on your work. Fix: keep the dependency inventory from step 3 and check it again at every release.

Dropping required notices. Keeping the copyright line and licence text intact is the whole obligation in a permissive licence, and removing it is the most common breach. Fix: add a check for the notice in your release checklist and keep vendored attributions in a file that ships with the code.

Changing licences without permission. A relicensing switch, even to a looser one, needs every copyright holder’s agreement. Projects have had to unwind public forks over exactly this. Fix: require a CLA or DCO from day one, keep contributor records, and treat relicensing as a governance decision rather than a maintenance task.

Two final tips. Prefer the least restrictive licence that still meets your goals, because restrictions cut both ways and most news tools do better with more adopters. And re-read your licence when the project changes shape: a hosted product, a paid tier or a corporate contributor is a good reason to revisit the decision you recorded.

Frequently Asked Questions

Conclusion

Start with one list: every use you expect for the tool over the next few years, public reuse, newsroom deployment, hosted service or redistribution. Then check your dependencies for conflicting terms, pick the least restrictive licence that still meets your goals, and write the decision down in the repository so the next maintainer can see why. For most newsroom tools that answer lands on MIT or Apache-2.0; for anything you intend to run as a hosted platform that must stay open, it lands on AGPL-3.0.