I'm developing a tool that will be distributed as a Rust crate and NPM package over the network, and a program will be running on a public blockchain. I'll be using other Apache 2.0 licensed code.

I would like to use AGPLv3 to enforce open source derivatives, but would also like to require promotional attribution for the end user (e.g. clearly visible "by CompanyName" on user interface where the tool is used, not just copyright notices in the source code).

Is there a license that matches my needs, something like AGPLv3 with an explicit user interface (rather than just a source code) attribution requirements?

I was thinking of making a compromise and using Apache 2.0 with the NOTICE, but I'm not sure if I can require such an attribution via the NOTICE mechanism?

I've read many answers across the stackexchange network (e.g. this one), but couldn't come to a definitive answer.


  • 3
    If there were such a licence, the requirement would make it non-free (and thus off-topic for this site). See eg the history of the original four-clause BSD licence and how a promotional attribution requirement that only applied to advertising materials was generally found to be non-free.
    – MadHatter
    Sep 2, 2021 at 6:16
  • @MadHatter non-free, but still open-source, thus appropriate for this site.
    – imprfekt
    Sep 3, 2021 at 13:56
  • 3
    @imprfekt 'Free' is just the qualifier FSF and Stallman use. Note that 4-clause BSD is also excluded from the OSI's list of 'open source' licenses. Thus, not 'free/libre' and also not 'open source'.
    – Brandin
    Sep 3, 2021 at 13:59
  • 2
    @imprfekt On this site "Open Source" refers to the Open Source Definition. Sep 4, 2021 at 1:26

1 Answer 1


Many open source licenses require reasonable attribution, but no Open Source / Free Software license will require prominent/promotional attribution. Let's talk about why that makes sense, and what the common Open Source options are.

Requiring prominent attribution is typically a bad idea.

Software has a life cycle. It is written, used, reused, discarded, potentially over the time frame of a century. Attribution requirements are uninteresting in case of verbatim copies of the software, but very tricky when we look at modified versions of the software. Or more precisely: when we look at derivative works. It might seem ethical to require prominent attribution when an application is modified in minor ways. But the same license conditions would apply if we only take a minor routine from the covered software and include it in a completely different program.

For example, let's say I've written an educational program that allows kids to experiment with geometry. I want all copies and modified version of that program to feature prominent attribution to me. Now someone else is creating a computer game, which needs some geometry manipulation in order to render the scene. The game developer would like to reuse some of my math functions. But would it be fair to require that the game must feature prominent attribution to me, just because the game happens to be derived from a few dozen lines of code I wrote?

I believe that requiring prominent attribution is not fair, and does not scale well. If we had to prominently attribute every Linux contributor or every LibreOffice contributor or every Firefox contributor, everyday software would become completely unusable. We must also consider that copyright typically lasts for life + 70 years, so often over a century. License conditions must be good for all that time. A license condition that might make sense in the 2020s will probably already be outdated in the 2030s, and hopelessly archaic around 2100. In particular, if an attribution is intended as an advertisement, there will probably be nothing to advertise for after a few decades.

There's also the question of how a license would define prominent attribution. If it is not specific, interpretations will differ. If it does prescribe specific ways for attribution, it will likely become outdated soon and limit use of the software in unfortunate ways. E.g. if a license from the 80s had required attribution in a printed manual, it wouldn't be possible to distribute such software over the internet. If a license today would require attribution on every screen, it already couldn't be used on non-visual software such as voice assistants.

Where license terms either require very onerous attribution or prescribe specific technologies for attribution, they violate the Free Software Definition and Open Source Definition. Free/Open Source software is about more than access to the source code, but also about the freedom to share and modify software.

  • From the Software Freedom perspective, onerous attribution requirements would violate at least Freedom 3: the freedom to distribute modified versions to others. At the very least, prominent attributions might be perceived as ads, but requiring the attribution to be preserved in a prominent place would deprive users of the freedom to modify the software for any purpose they wish.

  • From the Open Source perspective, there are additional concerns such as OSD #10: the license must be technology-neutral. OSD #3 also says that people who modify the software should be able to distribute their modifications under the same license terms, which means that they should also be afforded prominent attribution, which leads to the scalability problems outlined above.

Popular Open Source licenses support reasonable attribution.

It is completely reasonable to expect that end users of the software get to know what kind of open-source components are included in the software, and who contributed to them. To this end, popular open source licenses support some level of attribution.

  • The Apache-2.0 license has a NOTICE file mechanism. Every contributor can add attribution notes to the NOTICE file, as long as they don't appear to modify the Apache license. Any modified version of the software must provide the (relevant sections of the) NOTICE file to end users: “within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear”. For example, apps typically have a screen in their settings where such contents are shown.

  • The GPL-3.0 license family (including AGPL-3.0, LGPL-3.0) has an “additional terms” mechanism that allows you to add certain kinds of license terms. Per section 7(b) and (c), it is OK to add terms that require “preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it” or terms that prohibit “misrepresentation of the origin of that material”.

    For example, Apache-2.0 NOTICE style files could constitute reasonable legal notices. The term “Appropriate Legal Notices” is defined in the license to be displayed through a “convenient and prominently visible feature” that is part of an “interactive user interface”. But such notices might be far less prominent than expected, e.g. an entry in a menu would be sufficient. As an example, the Firefox browser includes material under GPL-3.0. The desktop version has an entry under Help > About Firefox that shows a screen that links to the about:license page that displays all required notices. I think this meets the GPL's definition of providing a prominently visible feature for showing appropriate legal notices.

What can you reasonably do?

If you want to stick with a common open source license, then making use of the (A)GPL-3.0 Additional Terms mechanism sounds sensible. But take into account that the GPL tries to maximize user freedom, and does not permit restricting downstream users with onerous attribution requirements. The GPL tightly restricts the scope of additional terms, and terms that go too far are ineffective. Drafting such Additional Terms is best done by lawyers.

It is also completely acceptable if you decide that using a Free Software / Open Source license is not a good fit for your needs. FOSS is very much about maximizing other people's freedoms, and licenses that are about other people's freedoms can be at odds with popular business models. In that case, you would likely have to get a lawyer to draft custom licensing terms that fit your needs perfectly. There are some “source available” licenses though. While they are great for transparency and for developing collaboratively in the open, they fail to provide the software freedom that is at the core of Open Source. Most source-available licenses I know are not focused on attribution, but on restricting for-profit uses (e.g. Business Source License, SSPL, Commons Clause).

A non-open source license could also be preferable from a reputation management standpoint. If you allow your software to be modified but still require promotional attribution, there could be modifications that you do not want to be associated with (e.g. political views, hate speech, illegal or obscene material). Open source licenses are generally considered to be irrevocable (unless breached). A custom (but non-FOSS) license could be written to restrict permissible uses, thus avoiding undesirable associations.

  • 1
    Thank you for the answer! Disappointed to see there isn't a compatible license for my use case as people already started claiming software as theirs. (End users don't look for the copyright notices to check the original authors)
    – imprfekt
    Sep 7, 2021 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.