Application Indicators: A Case of Canonical Upstream
Involvement and its Problems
I always thought Canonical could do a bit more to contribute to the GNOME
project, so I was happy to see the work on application indicators proposed to GNOME. Application indicators
are based on the (originally KDE-driven, I believe) proposed cross-desktop
notifier spec. The idea (as I understand it) is to have a consistent way
interacting with status notifiers and stop the confusing mix of panel applets
and systray indicators. This is a very laudable goal as mentioned by Colin Walters:
"First, +5000 that this change is being driven by designers, and +1000
that new useful code is being written. There are definite problems being
The discussion that followed was very useful, including the comments by Canonical's usability expert
Matthew Paul Thomas. Most of the discussion was about the question how
this proposal and spec could be best integrated into GTK, the place where
most people seemed to agree this belongs (rather than changing all apps
to provide this, this should be a service provided by the platform)
However, on the same day, Canonical employee Ted Gould proposed libappindicator as
an external dependency. The following thread showed a couple of
problems, both technical and otherwise:
- It is proposed as an external dependency, not as a part of GTK
- It is unclear how it will integrate with the GNOME3 Shell
- It requires Canonical's notorious copyright
- It is licensed under the LGPLv2.1 or 3 specifically, not any
What I personally disliked is the way the Cody
Russel and Ted Gould are papering over the above issues in the thread
that followed. For examples,
about point one, Ted Gould writes in the proposal:
Q: Shouldn't this be in GTK+?
A: Apparently not.
while he himself said on the same day, on the
same mailing list: "Yes, I think GTK/glib is a good place" and
nobody was against it (and in fact most people seemed to favor including
this in GTK).
To the question about why libappindicator is not licensed as usual under
the LGPL, version 2.1 or later, Canonical employee Cody Russell even replied:
"Because seriously, everything should be this way. None of us should be
saying "LGPL 2.1 or later". Ask a lawyer, even one from the FSF, how much
sense it makes to license your software that way."
Not everybody has to love the FSF, but proposing code under mandated
copyright assignments which a lot of people have opposed and at the
same time insinuating that the FSF was not to be trusted on their next
revision of the LGPL license seems rather bold to me.
Finally, on the topic of copyright assignments, Ted said:
"Like Clutter for example ;) Seriously though, GNOME already is dependent
on projects that require contributor agreements."
It is true that there are (or at least were) GNOME applications which require
assignments for contributions (evolution used to be an example, but the
requirement was lifted), however, none of the platform modules require
this to my knowledge (clutter is an external dependency as well). It seems
most people in the GNOME community have the opinion that application
indicators should be in GTK at least eventually, so having libappindicator as
an external dependency with copyright assignments might work for now
but will not be future proof.
In summary, Most of the issues could be dealt with by reimplementing it for
GTK when the time comes for this spec to be included, but this would mean
(i) duplication of effort, (ii) possibly porting all applications twice and (iii)
probably no upstream contribution by Canonical. Furthermore, I am
at how the Canonical people approach the community for something this
delicate (their first major code drop, as far as I am aware).
To be fair, neither Ted nor Cody posted the above using their
company email addresses, but nevertheless the work is sponsored by
Canonical, so their posts to desktop-devel-list could be seen as writing with
their Canonical hat on. Canonical does not have an outstanding track
record on contributing code to GNOME, and at least to me it seems this
case is not doing much to improve things, either.