Official proposal: how we define GNOME software

Community
1

This is being posted on behalf of the GNOME Foundation Board of Directors.

Historically, it hasn’t always been entirely clear what is and isn’t official GNOME software. This uncertainty isn’t necessarily a big issue for the GNOME community, and even has some advantages, but it does pose a number of legal issues, which the GNOME Foundation has been advised to resolve.

The Board of Directors is therefore proposing a new set of arrangements for how GNOME software is defined. The initial motivation behind these changes is to clarify which software is and isn’t official GNOME software. However, we also hope to use this opportunity to better support and promote the wider GNOME community. In doing so, we want to expand the number of projects and developers that the Foundation has a relationship with.

To do this, we are proposing a new category of software for projects which, while not being official GNOME software, are closely aligned with the GNOME project and its technologies. The name we have in mind for this new initiative is GNOME Circle. Software in this category will qualify for support from the GNOME project, in the same way that contributors to existing GNOME modules do today, and contributors will qualify for Foundation membership. In this way, we want to grow the GNOME community and give a greater range of participants a role in the Foundation.

The rest of this message includes an overview of how the new arrangements are expected to work. We’d love to hear your questions, comments and feedback.

There is still time to make changes before we put the plan into action.

Thanks!

Types of software

Our plan is to have two types of software that are recognised by GNOME:

1. Official GNOME software

  • Which software is included will be decided by the Release Team
  • Will include the modules which make up the desktop, platform, core apps and primary developer tools [1]
  • Included software is:
    • Required to be hosted on GNOME infrastructure
    • Can use GNOME’s trademarks to refer to themselves
    • Can identify the developer as “GNOME”
  • Applications are encouraged to use the org.gnome.* prefix in application IDs
  • Software will be included in the GNOME group on gitlab.gnome.org
  • Contributors qualify for GNOME Foundation membership

The implication is that any software that isn’t this group should not identify themselves using GNOME trademarks or state the developer as GNOME.

2. GNOME Circle

  • Which software is included will be decided by a new committee
  • Will include apps which use the GNOME platform and libraries which extend it
  • Included projects will be required to follow some general basic requirements, including quality expectations and being Free Software
  • This software:
    • Can be hosted on GNOME infrastructure in a dedicated Gitlab group, but this is not a requirement
    • Shouldn’t already have a sponsoring organization (such as a supporting company or non-profit)
    • Can use GNOME Circle branding
    • Applications can use an io.gnome.* app ID
  • Contributors will qualify for GNOME Foundation membership, and can therefore receive support through the GNOME Foundation

We would also really like to do promotional work and marketing for projects which are part of GNOME Circle.

FAQ

Will I have to change the ID of my app?

No. The guidelines for app IDs only apply to new apps.

Will I have to remove gnome from my app’s executable name?

No. Executables would not be covered by the new policy.

Will I have to move my modules to GNOME infrastructure?

Official GNOME modules are expected to use GNOME infrastructure, and they generally already do. Projects which join GNOME Circle can use GNOME infrastructure, but this is completely optional.

What this all means

With this proposal, the Foundation is providing a clear distinction about which software is official GNOME software. We are also providing a clear set of rules about what the different types of software can and can’t do with the GNOME trademarks. At the same time, we are hoping to expand the range of projects with which the Foundation has a relationship.

Inevitably, there will be projects that don’t neatly fall into the categories of software that we’ve laid out. If you work on one of these projects, the first thing to say is: don’t panic! We anticipate there to be a transition period as we align with the new arrangements, and we can make individual exceptions. If you are in doubt, please feel free to post questions here or, assuming the plan comes into effect, to contact the Foundation. We will be happy to provide individual guidance.

The second thing to say is that the definition of whether a project is or isn’t official GNOME software is not a value judgement, nor is it a statement as to who is or isn’t part of the GNOME community. Developers of software that doesn’t fit into the definition of official software will continue to be members of our community, and the Foundation remains committed to supporting you.

[1] The official definition will be the following modulesets:

16 Likes
2

Hello Alan and thanks for this proposal which is very clear!

It allows to clearly define what is official GNOME Software, what is GNOME Circle and what’s completely outside of the GNOME Foundation. It also defines a line between what can and can’t be done with GNOME branding which is much needed. I still have a few questions left though.

Did those committee decide what their decision will be based on? Is there a process for candidate applications to apply?

What kind of support do you mean? Is it infrastructure? Integration in the GNOME ecosystem (e.g. in Damned Lies)?

Given the foundation aims at not interfering with how the community shapes GNOME, I believe there is no financial support intended?

Thanks for your continuous work, and for being a part of this community which makes the world a better place!

3

Thanks for the encouragement, @thibaultamartin!

Did those committee decide what their decision will be based on? Is there a process for candidate applications to apply?

Yes, there would be a process and criteria for inclusion. Here’s a draft, so you can see what we have in mind.

Contributors will qualify for GNOME Foundation membership, and can therefore receive support through the GNOME Foundation

What kind of support do you mean? Is it infrastructure? Integration in the GNOME ecosystem ( e.g. in Damned Lies)?

Given the foundation aims at not interfering with how the community shapes GNOME, I believe there is no financial support intended?

Projects themselves will benefit from increased exposure and promotion and, if you contribute to a project that is part of GNOME Circle, you can apply to be a foundation member, and get all the benefits that entails.

1 Like
4

The link looks broken on my end. Maybe the audience was restricted?

Fancy! It motivates me to make a first release of my app then :slight_smile:

5

Pastebin not playing along - I’ve switched to an Etherpad. I hope that works!

1 Like
6

This sounds like a good proposal. Can you give some examples of apps we’d hope to initially be part of the GNOME Circle?

7

I think the goal would be to include all the GNOME-y apps that aren’t in the official modulesets (1, 2). That’d include established apps like Rhythmbox, Shotwell, Geary and Evolution, but also new apps like Fractal, Apostrophe and Shortwave.

8

Are these hard or soft requirements?

If hard, changing the app id is a substantive code and deployment change and is quite onerous. As such, the requirement should probably be dropped if applications are likely to be “promoted” or “demoted” between the two groups with any kind of regularity.

If a soft requirement, it won’t be adhered to (because changing an app id is onerous), so is pointless and should be dropped anyway - the two groups of apps will have a mixture of both app ids.

In any case, suggesting apps use a domain managed by a CC TLD registrar that engages in colonial profittering is a bad look for an organisation that claims to be inclusive and pro-social.

9

I don’t get this one. There is a company and it made a free and open source software, and it wants the software to be part of GNOME Circle. The company will continue to support the application on their behalf. But it is not possible?

10
  • Applications are encouraged to use the org.gnome.* prefix in application IDs
  • Applications can use an io.gnome.* app ID

Are these hard or soft requirements?

Soft, due to the fact that changing the app ID isn’t always trivial, although it’s not a simple soft requirement.

The io.gnome prefix is intended to be a perk - Circle apps can use it if they want, and non-Circle apps shouldn’t use it. If an app leaves the Circle and still has the io.gnome prefix, then it’s a badge to show that the app was once a member.

org.gnome prefixes are a bit different since they are already in somewhat wide usage. I think what we’re saying here is that we’d like developers to try and use them appropriately in the future, which means not using the org.gnome prefix for apps that aren’t ever likely to become part of the official core group.

In the future we might ask developers who are using org.gnome for new projects which aren’t in scope to pick something else, although I think we’re going to have to feel our way into that one.

If a soft requirement, it won’t be adhered to (because changing an app id is onerous), so is pointless and should be dropped anyway - the two groups of apps will have a mixture of both app ids.

We might have to see how things go here. I think that adherence will be easier in the Circle case, because it’s new.

For org.gnome it’s a bit messier, but we would like to try and have a more standardised approach as we move forward, for two reasons. First, it’s good for us to have some recourse in cases where the ID is obviously being abused. Second, I think we want to try and avoid the situation where we have a clique of core developers who feel free to use org.gnome for their personal projects, resulting in anyone on the outside of that group feeling excluded. We want to have an inclusive space where new developers feel that they are equals, and that means having a common set of guidelines for how apps should to be identified.

In any case, suggesting apps use a domain managed by a CC TLD registrar that engages in colonial profittering is a bad look for an organisation that claims to be inclusive and pro-social.

I can’t say I’m very familiar with those issues, but if it’s a concern we can look into it and explore alternative domains. Any suggestions or pointers would be welcome.

1 Like
11

Shouldn’t already have a sponsoring organization (such as a supporting company or non-profit)

I don’t get this one. There is a company and it made a free and open source software, and it wants the software to be part of GNOME Circle. The company will continue to support the application on their behalf. But it is not possible?

Good question, and maybe this part of the proposal needs to be specified a bit better.

The main issue is that, if there’s a big project with hundreds of contributors, its own non-profit, and money in the bank, it doesn’t make much sense for them to join the circle and get help from us to do marketing and financial support for travel.

However, maybe we need to nuance the message a bit, because you could potentially have a smaller project that has some support through an org, but is still aligned with GNOME and would benefit from being in the circle. I’m just not sure how you’d express that…

1 Like
12

Ask for the project owners to become financial supporters of the GNOME Foundation, for instance; we might need to structure different levels of donations, if we want them to be on the advisory board. Of course, it’d need to be a vetted process, so we don’t simply exchange brand recognition for cash.

1 Like
13

It’s actually hard to find more information about this issue post 2014. Of course, the underlying issue of the Chagos Islands and the mess that the UK made there is still ongoing.

In practice, though:

  • the .io domain registrar is a private company, not the UK government
  • GNOME already has an .io domain, which was donated to the Foundation

The Foundation could decide to make it lapse, but it’s kind of prime Internet real estate, and it will be snatched up anyway, and then we’re going to get a new domain, and the Chagos Islands will not see any change. On the other hand, there is a UK Chagos Support Association that the Foundation could donate to and raise awareness of.

1 Like
14

And in case the support is not something related to “cash” ? Like that organization was meant to handle development of the project itself and not involve any money stuff ?

15

That was an example of things we can do for existing, for-profit organisations. For non-profits we could have some sort of brand recognition program—you prominently mention you support GNOME in your public-facing venues, and GNOME verifies that support.

1 Like
16

What about software like Getting Things GNOME which is 100% community-driven, has over a decade of brand recognition by its users (I actually value that, and I also find the pun funny), is a GNOME app in practice (from a technological, design and social standpoint, as it was born out of the GNOME culture and has always stayed close to it), but:

  • “competes” with the “GNOME ToDo” app (which is a much younger project with a much more limited featureset/scope);
  • has not yet migrated to GNOME’s GitLab (help wanted, because I don’t have the time and skills to do that myself and I would like to see it done “properly” with no data loss incurred);
  • does not follow GNOME’s time-based release schedule, but instead uses quality & feature-based milestones (at least that’s how I’m turning that project around, otherwise it’s just not feasible in this context). More generally, I find a time-based schedule to be arbitrary and unsuitable for some agile projects (as it can be unrealistic or too constraining), and my experience leads me to believe that some app projects can benefit from a different approach, but that’s a story on its own (probably worth a blog post if anyone would be curious to hear my thoughts on that someday).

Could GTG, if migrated to GNOME’s GitLab, be considered an official “GNOME” application and retain its branding although I cannot concern myself with the release team’s fixed six-months schedule as a maintainer?

17

Well, not under this proposal. Even GNOME To Do would be part of GNOME Circle under this proposal.

18

Apps shouldn’t use “GNOME” in their user-visible names (because, you know, “GNOME” is a trademark). You mention “GNOME To Do” but that’s not the name of the app - the “GNOME” is an informal convention. The name on the launcher is “To Do”, and that’s what users see if they look it up in Software. (The description says “Task manager for GNOME”, just like the description of Builder is “An IDE for GNOME”, both of which are perfectly acceptable.)

We’ll likely need to consider the “Getting Things GNOME” name as a special case.

19

Are there any examples that you’re thinking of here…?

20

Is there infrastructure in place to deal with existing links? In particular those in About dialogs and AppData that can only be updated by pushing out a new release.