Introduction
Prior to the transition away from “codenames” GNOME used the freedesktop Menu Specification to denote what kind of activity an application was categorised under.
Rhythmbox was a Music Player, Anjuta was an IDE, Nemiver was a Debugger, Epiphany was a Web Browser etc.
These categories and expanded categories were easily translatable and contributors were free to name their applications and frameworks however they saw fit within reason, e.g they must not violate an existing trademark.
Today GNOME is in a strange position where it both does and doesn’t use “codenames”, some users know Epiphany as Epiphany, some know it as Web and some know it as both. Is renaming Epiphany to Web more straight forward from a UX perspective than using the expanded categories to categorise Epiphany as a Web Browser? I’m not sure.
It gets particularly confusing when taking into consideration the naming conventions of other freedesktop environments as many different applications might share the same generic name, e.g Music, Photos etc
But another aspect that I feel hasn’t really been discussed all that much is the role of trademarks in free software development and how the generic application name policy impedes projects from defining trademark policies for the distribution of their applications.
Why would you even want a trademark policy?
You may encounter unfortunate situations where some downstream packagers, package your application in a broken state by e.g refusing to include a dependency which the application requires to function.
The downstream are well within their rights to do this from a copyright perspective, they are free to ignore upstream and ship something to users which is broken but with a trademark distribution policy they would not be free to tell users that the code they are shipping is associated with your project.
Do situations like that happen?
Yes they do, all the time. Bugs get reported upstream, sometimes over many years because a particular packager refuses to include the correct dependencies in a package. Sometimes it’s stubbornness on the packagers side and sometimes its conflicting downstream policies which end up frustrating users and wasting the time of upstream which could be better spent improving the application in question.
Who does this affect?
Upstreams , users but also other downstream’s who do their best to follow guidance and collaborate with an upstream to ensure that the downstream package they are producing actually works.
Upstream is often just one person wearing multiple hats, there’s enough work to do, whether that’s bugs to fix, features to add, documentation to write. There’s no need to add more on top because a packager decides they don’t like that you used framework x, y, z to develop your application.
How do other projects deal with it?
Some OpenSource projects have trademarks which are hosted by a single company, others have trademarks which they place under the stewardship of an independent organisation.
Examples of OpenSource trademarks would be Firefox, Kubernettes etc
The Kubernetes trademark was provided to the Linux Foundation by Google to manage independently, Mozilla are responsible for the Firefox trademark.
How does the GNOME foundation deal with it?
Looking at the foundations trademark policy page, It appears that the foundation does not have many trademarks in its possession.
There doesn’t appear to be any procedures or policies around placing your projects trademark under the stewardship of the foundation where it can be independently defended by a neutral organisation .
How could the foundation deal with it?
I’m wondering whether it’s a good idea with the GNOME Circle initiative to maybe rethink the existing trademark strategy and provide opt-in solutions for trademarks.
Similar to what the Linux Foundation currently provides its projects today.
Just to clarify, I am not saying that the foundation should define a one size fits all distribution policy for Circle Apps, The distribution policy would depend on the app in question and what it actually needs in order to function correctly when distributed downstream, e.g tracker-miner to discover content installed on the system, libretro-cores to be able to play content etc.
Mozilla’s distribution policy is a good source for ideas on what could be achieved.
A downstream may not want to distribute an application in accordance with the distribution policy of an upstream project and if that’s the case it’s A ok 
, the distributor would be free to distribute the codebase under a different name.
That would help prevent any confusion as to what users should expect from an upstream application when shipped downstream.
It would also help reduce tensions between upstream developers and downstream packagers who aren’t actively creating problems.
Summary
I think that it would be great to be able to place a trademark for a Circle app that you develop under the stewardship of the foundation if that’s something that you would like to do.
Right now it’s not clear where a trademark should go if you join Circle, if you want the trademark to be hosted by an independent non-profit and GNOME doesn’t accept it then will that prevent you from joining Circle entirely if you need to turn to e.g the Linux foundation to host said trademark?
Does that count as a non-profit fiscal sponsorship?
This is unfortunate as you may just want a distribution policy in order to ensure that the GNOME dependencies your application requires are bundled with your application when it’s distributed to users by third parties using your trademark.
If you look at the distribution policy for Mozilla then you will see that they can also be used to enforce privacy policies which upstream defines.
This is something which cannot be achieved with the generic name policy that is currently being pursued.
A downstream could inject downstream patches into an upstream project which snoop on the user-base and neither the maintainers nor the GNOME foundation would have any avenues open towards fighting back.
As far as the user is concerned it would be the upstream project and GNOME doing the snooping.
A downstream could also inject downstream code into an upstream project which redirects donations from the upstream to the entity responsible for the downstream package and there would be nothing that upstream or the foundation could do to fight back.
So thats the gist of it really, I think “codenames” have gotten a bad rep over the last 10 odd years and needlessly so, it’s much easier to transition a “codename” to a real trademark with all of the tangible benefits associated than it is to transition a generic name.
Trademarks can offer a layer of protection for contributors, the foundation, and for the user which generic names just can’t afford.
They help with search engine optimisation, discoverability and they are also quite crucial for upstreams to provide assurances and trust for their user base so they can be confident that the code they are running locally has been distributed correctly to a high standard.
I am eager to hear some feedback on this from contributors, the foundation etc.
Thanks for taking the time to read this.