You're talking about two separate issues: controlling the name of a project, and requiring user-visible attribution.
To summarize the below points:
- of course you can register a trademark for your project name, though this might be expensive
- control of a name does not equal control over a project
- some Open Source licenses have name-related terms, but I can't recommend them
- nearly all Open Source licenses require user-visible attribution notices, and some make fairly detailed requirements
- it probably doesn't make sense to distinguish between substantial copies vs individual components
In practice, I'd suggest thinking about whether you are more interested in permissive or copyleft licensing, and then pick one of the commonly used licenses like Apache-2.0 or (L)GPL-3.0, all of which have detailed attribution requirements. If appropriate, you could add further exceptions to those licenses.
Controlling the name of a project
Trademarks are largely orthogonal to Open Source licensing issues, and indeed registering a trademark is a common way for large projects to maintain control over the “official” version. Generally, Open Source licenses only allow usage of trademarks as necessary for attribution purposes.
If you're considering registering a trademark for your project, it would be useful to read up on the trademark policy history of Mozilla Firefox and Mozilla Thunderbird. Mozilla uses exactly such trademarks to prevent unofficial builds to be distributed as Firefox/Thunderbird. However, the exact terms of this policy was incompatible with the policies of the Debian Linux distribution, so that Debian instead provided rebranded versions called “Iceweasel” and “Icedove”. This could eventually be resolved, though. Notable current Firefox forks include the Tor Browser and LibreWolf.
Some Open Source licenses try to implement a trademark-like mechanism without having to register a costly trademark, but I don't think it's particularly advisable. As an example of this, the Artistic License 1.0 (used by Perl) allows forks of the projects to use the same name if they remain compatible to the upstream project, otherwise they must change the name, in particular the name of the installed executables. This allows users to install different Perl forks side by side. The SIL Open Font License 1.0 has a similar “Reserved Font Name” mechanism. But I recommend neither of these licenses for general purpose software.
Instead of wading into trademark or other naming issues, many licenses just require that changes to the upstream version are clearly marked.
Even when related projects have distinct names, this can sometimes cause confusion for users.
When Oracle acquired Sun's OpenOffice.org and stalled development, nearly the entire community forked the project as LibreOffice. Thus, LibreOffice is the continuation of the OpenOffice project, despite having a name change. The rights to the name of the stagnant OpenOffice project were subsequently donated to Apache. Nevertheless, many people keep installing the dead OpenOffice software.
- The GCC compiler almost had a similar history, with development stagnating under FSF leadership, and the community EGCS fork thriving. The community split was eventually resolved when the FSF blessed EGCS as the official GCC project and agreed to a community-led governance approach.
uBlock is definitely not associated with the excellent uBlock Origin adblocker.
Looking at these examples, I think the best way to stay in control of the project and the name (even without trademarks) is to keep an open ear for user needs and to welcome reasonable contributions. But even if development effort migrates to a different fork, many end users will stick with the original name that they recognize.
When publishing apps in an app store, don't expect licenses or trademarks to prevent copycats. Even for proprietary apps, it is common for clones to spring up. Criminals don't care about your rights. The question is then less “are the imitators allowed to do that?” but rather “can you force the store to take down the imitations?”.
Requiring attribution
Nearly all Open Source licenses require some degree of attribution, perhaps with the exception of 0BSD. The licenses should also generally be interpreted so that this attribution must be visible to end users, though not necessarily prominently. For example, the BSD-3-clause license requires such notices to appear “in the documentation and/or other materials provided with the distribution”. For mobile apps, it is common to have a screen in the app settings that collects attribution notices for all Open Source components.
Looking at the most commonly used licenses, the Apache-2.0 and GPL-3.0 licenses have detailed requirements about how notices be presented to end users. The goal here is not necessarily to provide glory and fame to the original developer, but to inform end users about their rights to use, inspect, share, and modify some or all of the underlying components.
The Apache-2.0 provides a NOTICE file mechanism. The contents of this file must be provided as a “readable copy” “in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; 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.”
The GPL-3.0 (and AGPL-3.0 and LGPL-3.0) allows verbatim copies to be shared as long as existing notices are kept intact. For modified versions, there must be “prominent notice” that the work was modified. If the software displays “appropriate legal notices” via some user interface, the modified version must continue to do so. Such notices are further defined in the license – in particular, obnoxious advertisements would not be appropriate:
An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
As an example of such interactive notices, consider the output I see when I launch the GDB debugger:
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
[...]
(I have elided the part of the message that links to the manual and explains how to report bugs.)
The GPL-3.0 also allows additional attribution- and name-related requirements to be added to the license, if they are explicitly allowed under Section 7(a) through (f).
You mention that you want to distinguish attribution requirements between substantial copies and individual components. I think this is unlikely to work. First of all, any such boundary is difficult to define in a reasonable manner, so it is best to avoid such distinctions. Second, existing licenses do not really make this distinction and instead provide reasonable but fairly low-key attribution requirements for any kind of derivative work. So you'd have to create a custom license, which can be problematic.
If you really wanted to make such a distinction, you could add a rider to an existing license that provides an exception to its attribution terms. The GPL-3.0 license family explicitly anticipates such exceptions in Section 7. Just like the LGPL-3.0 is an exception from the GPL's requirement to provide the Corresponding Source Code for the entire application, you could create an exception from the license's requirement to provide attribution. In principle, a similar approach could also be applied to other license terms.
