As part of being the chief Linux and open source technologist at Intel,
Dirk Hohndel flies all around the world to talk to conferences on various
topics. This time around, he came to Berlin to talk to the Desktop Summit about the role of
large companies in open source. Some recent events caused him to take a
bit of a detour on the way to his topic, but, as it turned out, that detour
fit in fairly well with the rest of his message.
By way of an introduction, Hohndel said he has been hacking since he was 11 years old, doing Linux for
almost 20 years, and open source a bit longer than that—though it
wasn't called open source back then. These days, he still writes code,
though not as much as he might like, but he still considers himself a hacker.
was coming to the summit, Hohndel said that he decided to install the latest versions of
both GNOME and KDE. But then he made a mistake. He publicly complained (in
about his experience with GNOME 3. He was, he said, trying to give some
feedback, and the reaction was not quite what he expected.
But Hohndel is very happy about how far the free desktops have come. Both
GNOME 3 and KDE 4 look "sleek and professional", he said. He
is also glad to see that the free desktops have stopped following along
with what Windows is doing, though that may have shifted to following Mac
OS X a little too closely these days. The Mac interface is
"awesome" as long as
"you do exactly what Steve wants you to do", otherwise, it
turns into: "you can't do that". He sees something of that
attitude bleeding over into the Linux world, which is worrisome.
He noted that the most recent Mac OS X update changed the way scrolling
worked, which made it very confusing and hard to work with for some
people. But, he said, Apple also added an option to turn off the new
scrolling behavior. That's what seems to be missing in the GNOME 3
situation. It is not helpful at all if the first reaction to a criticism
is "you're an idiot", and that's some of what he's seeing.
Radical change is difficult, he said, and he is very glad GNOME and KDE are
taking it on, "but don't leave people stranded".
Large companies and open source
Shifting gears, Hohndel launched into his main topic and listed three "F"s that can be used to describe the relationship between
large companies and open source—and "one is not the
one you are thinking of". The three are funding, feedback, and
freedom. Funding is more than just hiring developers to work on free
software, he said, there is lots more that companies do. Sponsoring
conferences (like the Desktop Summit), helping developers travel to various
conferences, getting hardware into the hands of the right developers, and
so on, are all things that companies do.
But, "don't just think of us as moneybags", he said. Companies
have other uses as well and one of the biggest is in providing feedback.
Companies spend huge amounts of time and money trying to figure out what their
customers want. While open source developers mostly talk among themselves,
companies are out talking to customers.
Unfortunately, the results of those customer talks are "conveyed in
unbearable marketing-speak", he said, but there is value in it.
Gaining that value requires listening carefully and filtering what you
hear. Intel always has the Intel view, and other companies are the same, so
one needs to take that into account. It is important to keep an open mind
even when the feedback is critical of a particular feature or project.
One area where open source could do a much better job is in documenting the
response to a bug report or feature request. It is often the case that
reports and requests either get a "vicious response" or none
at all. Two releases later, it might be fixed, or not, with very little
indication of which is going to happen—or why. It would be much
better for all concerned if requests that are rejected have a clear reason
stated as to "why the request cannot or should not be implemented".
Freedom (or control)
The third element is freedom, which Hohndel said he really wanted to call
"control", but that it didn't start with an F. Large companies have
agendas and an ingrained need to control things. As long as open source
developers understand a company's intentions, a good working relationship can
come about. Companies "are not per se malicious, we just
appear that way", he said. By definition, companies are
"looking out for our interests first, yours second".
Big company managers "manage to numbers", Hohndel said, not
freedom or the greater good and that affects their decision-making. Things
can change quickly and three months down the road a particular project
"may not be interesting anymore", and free software developers
and projects need to recognize that. If the project is depending on a
company to finish a particular library that is being used by the project,
the developers should be
prepared that the priorities or interest level of the company may change.
Most open source developers today are employed to do so, he said, like it
or not—most of the developers themselves do like it. For the kernel,
he cited statistics from LWN showing that 80% of kernel developers are paid
to do that work. He couldn't find similar statistics for GNOME or KDE, but
they are likely to be comparable.
"Companies are very important, but change the way things work with
projects", he said. Most projects start small and are created by
individuals for their peer group. That means that they are not designed for
working with companies, particularly in the areas of licenses and
governance. If the main developers are all suddenly snapped up by a
particular company, it can change things. It is something that projects
should consider because "freedom is often overlooked" when a
project starts to look at working with companies.
In summary, Hohndel said, no big open source project is independent from
large companies today because they have all been "engaged and infiltrated" by
those companies and their employees. That means that projects need to
understand how to work with companies to get the most out of them. Part of
that understanding will come from listening. Companies can really help
accelerate development on a project, which is one of the reasons it is
worth figuring out how to make it work.
GNOME and KDE are "both beautiful looking desktops", he said,
and "we are miles and miles ahead of where we were a few years
ago". There is still some way to go before they are ready to go for
everyone, but his hope is that the week-long summit will help solve some of
problems and get us that much closer.
[ I would like to thank KDE e.V. and the GNOME Foundation for assistance
with travel funding to the Desktop Summit. ]
Comments (4 posted)
Despite some severe setbacks, the MeeGo project continues to develop its
platform. The software is getting better, and we are starting to see a few
places where it can be had on real hardware. Unfortunately, MeeGo has just
run into another snag involving the hosting of a proposed third-party
application repository. The project can survive this rough patch too -
without even all that much bother - but only if the participants can
gain a better understanding of what is going on. What may look like a
serious community disconnect is really a simpler story which has been
muddied by poor communication.
Some developers within the MeeGo project have been working for a while on
intended to be a repository for open-source MeeGo applications written by
individual developers. Plans include a vetting process to ensure the
quality and benign nature of applications to be hosted there. Things were
getting closer to being ready for deployment when the process ground to a
halt. David Greaves described the problem this way:
The Linux Foundation have told us in private conversations that
they will not permit apps.meego.com to be served from the MeeGo.com
infrastructure hosted by them. They do not have the resource at
this time to provide a statement giving their reasons. We can not
assess what other services may be impacted in the future.
The Linux Foundation is in a position to make this decision because it is
the nominal owner of the MeeGo project, the MeeGo trademark, and the
meego.com domain name. One of the parent projects - Moblin - was handed
over to the Foundation in 2009 as a way to establish it as a free and
independent project; when Maemo was merged with Moblin to create MeeGo, the
combination remained under the Foundation's management. The intent was to
ensure that MeeGo was not driven by the needs of any one specific company,
but, instead, to help it be a fully independent project.
In a separate "problem
statement," David says that, in private communications, he has been
told that patent worries are behind this decision. In the absence of an
official statement from the Linux Foundation, David's statement has shaped
the public discussion. LWN was able to get some more information by
talking to a Linux Foundation VP Amanda McPherson and from an
IRC conversation held on August 9. As one might expect, the full
story is more complicated - but also more simple.
Patents - or something else?
The legal concerns are a good place to start, though. The Linux Foundation
does a lot of work that is not related to MeeGo at all. It hosts
Linux-related conferences around the world (and funds developer travel to
those events), runs a growing training operation, helps companies join the
contributor community, promotes various standards activities, provides a
vendor-neutral paycheck for Linus Torvalds, and more. One could reasonably
argue that putting all of those activities at risk for a MeeGo-related
application repository would be an irresponsible thing for the Foundation's
management to do. It is also possible to argue that this risk is not zero;
there are organizations which might see value in disrupting the
Foundation's operations. The risk of simple patent trolls is also,
clearly, something that must be kept in mind.
So it is not possible to immediately conclude that the Linux Foundation's
refusal to support apps.meego.com is unreasonable or improper, even if
legal worries were the only consideration. There may indeed be real
concerns that apps.meego.com could lead to collateral damage far beyond the
MeeGo project itself. It would be a shame to see Linus on the street with
a "will pull git trees for food" sign, so this is an outcome that is well
worth avoiding. But, the Linux Foundation says, legal concerns are only a
part of what is going on here.
The real issue, according to Amanda, is simply a matter of resources.
Setting up this repository would require comprehensive legal review,
certainly, but it also requires system administrator time, trademark and
branding attention, and little things like user support. Even if the
repository has big warnings to the effect that applications are unsupported
and guaranteed to set devices on fire, there will still be a stream of
users with battery life problems contacting the Foundation for support.
The Linux Foundation is a small operation lacking much in the way of spare
staff time; it simply felt that the resources required to establish and
operate this repository were not available.
Beyond that, it seems, plans for MeeGo never called for a central "app
store." Instead, MeeGo is meant to be the upstream for vendors to use in
the creation of their products; it was assumed that those vendors (or their
users) would set up multiple application repositories as they saw fit. A
central application repository blessed and operated by the MeeGo project
could be seen as competing with (and discouraging) those efforts.
Questions and the way forward
All told, it seems like a reasonable explanation for what has happened
here. That said, there are some questions that arise from this incident.
First among those is: why was the Foundation so secretive about its
decision? Somebody clearly took the time to think the problem through,
but, somehow, they could not find the time to explain - in a public setting -
the conclusion that they came to. This time of year, allowances need to be
made for vacations and frantic preparations for LinuxCon, but it still
should have been possible to avoid being completely silent on the issue.
Silence is, at best, unfair to the developers who have been working to make
apps.meego.com a reality. At worst, it feeds doubts about the Foundation's
motivations and allows other mysteries to endure. For example, why is
distribution of MeeGo applications via the project's open build server
(something which has been going on for a year) less worrisome? We are told
that the Foundation will have an official statement out in the near future;
hopefully that will clarify things.
A more important question, though, might be: is the Linux Foundation the
right home for the MeeGo project? If the Foundation's concerns and
limitations get in the way of what the MeeGo project wants to do, it might
be time to ask if MeeGo needs to find a home more suitable to the
activities it is trying to pursue. Thus far, it must be said, the number
of people asking that question in public is quite small.
Then, of course, there is the most relevant question of all: what should the
MeeGo project do now? The above-linked problem statement offers three
- Keep the apps.meego.com plan as-is under the assumption that somehow
the Linux Foundation's resistance will go away. This seems like an
- Move the application repository to a new domain outside the control of
the Linux Foundation - probably apps.formeego.com. Everything else
would remain where it is now with the possible exception of the build
- Move everything away from the Linux Foundation and place it under the
control of a separate non-profit organization. The Foundation would
retain the MeeGo trademark and compliance process; everything else
would happen elsewhere.
One does not have to read too deeply between the lines of the problem
statement to get the sense that David favors the final option listed
above. But David (whose job is "MeeGo devices build systems architect" at
Nokia) is not in a position to make that decision. Some other
participants in the MeeGo community have called for the project to become
more independent, but, if there is truly a groundswell in favor of that
idea among serious MeeGo developers and the companies with stakes in MeeGo,
it has not yet become apparent in the public forums. There does not appear
to be any widespread desire for a new home - or a fork - in this community.
So what is almost certainly going to happen is that apps.formeego.com will
be set up, probably on servers installed in Europe, and third-party
applications will find a home there. The use of that domain
name has already
been approved, so there need be no fear of repeat of the Smeegol incident in this case.
It also seems that linking to apps.formeego.com from meego.com sites will
not be a problem; linking to external repositories was always in the plans.
This should be a solution that works for everybody involved, even if some
participants would rather have seen the repository live within the
meego.com domain. The biggest failure in this story is not, as it might
have initially seemed, one of project governance; it's really just a
problem of communications. That particular failure will, with luck, be
remedied soon. The project will get its repository, and everybody can go
back to the real problem: getting interesting MeeGo-based devices into the
market where the rest of us can actually get our hands on them.
[Update: the Linux Foundation's Brian Warner posted
an update on the apps.meego.com decision shortly after this article was
Comments (3 posted)
Copyright assignment (or licensing) agreements for projects is a rather
contentious issue that reflects differing views of how free software will
be best-positioned to grow over the coming years. Several perspectives
were on display at the "Panel on Copyright Assignment" held on August 6 at the Desktop
Summit in Berlin. The panel consisted of two opponents of such
agreements, Michael Meeks and Bradley Kuhn, as well as perhaps their most
outspoken proponent, Mark Shuttleworth, with GNOME Foundation executive
director Karen Sandler handling the moderation duties. In the end, each
position was well-represented, but, as might be guessed, neither side
convinced the other; each will likely continue to pursue its path over
the coming years.
Sandler asked the assembled room—packed with 400 or more
attendees—how many knew about the issues surrounding copyright
assignment and around half raised their hands. More or less the same half
responded that they already had strong feelings about the subject, though in which direction wasn't
necessarily clear from the query itself. Based on the general feeling in
the free software world—perhaps reflected in the 2-1 ratio on the panel—it is probably
reasonable to assume that most of the strong feelings were in the
The differences between copyright assignment agreements (CAAs) and
copyright licensing agreements (CLAs)—the difference between assigning
copyright to an organization vs. giving the organization a broad license to
do what it wishes with the contribution—was not really under
discussion as Sandler pointed out in the introduction. For the most part,
the differences between the two are not germane to the dispute. She then
asked each of the panelists to introduce themselves and to outline their
Setting the stage
LibreOffice and longtime GNOME hacker Michael Meeks went first with
his objections that he said came under three separate headings:
scalability, conflict, and ownership. Those make a nice acronym that also
summarizes his feelings, he said. Meeks was at one time an advocate of
copyright agreements, and then changed his mind because he has "seen it
go badly wrong".
The scalability problem is that giving the rights to your code to a company
leads to them having a monopoly. The company typically has a strong
copyleft outbound license (e.g. GPL) to drive any proprietary licensing to
the company. This can lead to conflicts, he said, like "hackers
vs. suits" or the community vs. the company. If contributors don't
feel like they own part of the code, they "feel very differently
about the project", he said. They don't necessarily feel any
allegiance to the company, but the loss of ownership can make them feel
like they aren't really part of the project either. That can cause less
vibrant and excited communities.
Canonical and Ubuntu founder Mark Shuttleworth said that he thinks of
himself as a gardener and
"looks at how ecosystems grow and thrive". As a businessman,
he wants to be part of a thriving ecosystem and believes that others in the
room share that view. Today, we don't have a thriving ecosystem for the
Linux desktop, he said. Even in the face of Microsoft domination, iOS and
Android have built thriving ecosystems and he would like to see the Linux
desktop do the same.
"Freedom is not on the table in these discussions",
Shuttleworth said. While code that is contributed under one of these
agreements could go proprietary, the code itself is not at risk as it will
always be available under the free license that it was distributed under.
The Linux ecosystem needs lots of smaller companies and startups to be
involved, but that isn't happening, he said, as they are developing for
Android, iOS, or the web—and are not at the Desktop Summit.
There are several ways to get companies to participate in a free software
project, Shuttleworth said. One way is to a "nexus project"
like the Linux Kernel, where companies have to participate in its
development, though they "hate it" and wish that they weren't
required to do so, he said. Another way is
to have a "core shared platform" with a permissive license
that allows companies to add "secret sauce extensions", and
pointed to the PostgreSQL community as an example. Aggregation is another
path—used by Linux distributions—to take the work of multiple
communities, package them up, and make quality or IP promises about the
bundle to attract customers. Lastly, he mentioned the single vendor model
which clearly states that there is an organization behind the project, like
Mozilla. There are fears about that model, he said, but the way those
fears are dealt with in mature markets is via competition.
Bradley Kuhn of the Software Freedom Conservancy disagreed with
Shuttleworth: "software freedom is always on the table", he
said, and it is always under threat. Kuhn was formerly the executive
director of the Free Software Foundation (FSF) and currently serves on its
board. He noted that the FSF put a lot of effort into putting together a
legal framework where projects can work with companies on equal footing.
The license that is used by a community is in some ways the constitution of
that community, but a copyright agreement can change that constitution in
unilateral ways. Copyleft is designed to make sure that derivatives of the
code are always available under the terms which the original code was
Kuhn noted that some might be a bit surprised at his opposition, given that
the FSF requires copyright assignment for its projects. He has been
advocating making that optional rather than mandatory, but has so far been
unable to convince the board to make that change. But there is "a
tremendous amount of value" in assigning copyrights to an
organization that is "completely aligned with free software"
such as the FSF. The FSF has made promises that the code and its
derivatives will always be available under a free license, but unless a
company makes those same kind of promises, there is no such guarantee. So
far his requests to some companies to make promises of that sort have
been met with a change in the subject, he said.
Meeks asked Shuttleworth if he agreed that signing a copyright agreement
with a company gives that company a monopoly, and Shuttleworth said that he
didn't. If the code is available under the GPL, there is no monopoly, he
said, though the company with a majority of the copyright is in a
"beneficial position". Kuhn argued that Shuttleworth was
changing the subject, because the monopoly is on the ability to
license the code under proprietary terms. That is a "trite and
obvious" observation, Shuttleworth said, in agreeing that it does
give that kind of monopoly power to the copyright holder.
Meeks said that the reason that there are two major Linux desktop projects
stems from the proprietary licensing problem, referring to the non-free Qt
licensing that existed at the time of the GNOME project's founding. He
believes that having both of those is a "sad waste". Part of
the problem for Linux is lots of "pointless duplication", he
said. In response to a question from Shuttleworth, Meeks said that having both the Firefox and Chrome browsers was pointless
duplication in his view. "I see nothing wrong with Firefox", he said.
Signing requirements and "friction"
pointed out that copyright agreements "can cause problems and we should be
careful to address them". One of those problems is the "friction"
caused by having to sign an agreement at all, noting that one of the great
strengths of the GPL is that you don't have to sign it. But, in cases
where an agreement is needed, we can reduce the friction, which is what
Project Harmony was set up to do, he said. By reducing the number of
differing agreements, companies like Canonical would not have to look at up
different ones every year, he said.
Kuhn said that his goal would be for Canonical and others to never have to
sign such an agreement at all. If the license under which the code is
contributed is the same as that under which the project is released
(i.e. "inbound == outbound"), there would be no need for an agreement. The
GPL is designed to handle that situation properly, Kuhn said. He also
noted that he was concerned about the Harmony agreements because they could
lead to the same kind of confusion that the Creative Commons (CC) licenses did.
By having multiple different kinds of agreements under the same top-level
name (e.g. Harmony or CC), there can be confusion as to what
is meant, he said. It took time to separate the freedom-oriented CC
licenses from the non-free choices, and he worries that a similar situation
may arise for Harmony.
Sandler asked the panelists about using the "or later" clause (e.g. GPLv2
or later, aka "plus" licenses) when licensing code and what the implications were. Kuhn noted
that the Linux kernel famously does not use "or later". He said
that doing so is putting trust in another organization, and that if you don't
trust that organization "deeply", don't sign a copyright
agreement with them or add an "or later" clause to a license that is under
But Shuttleworth is concerned that using "inbound == outbound" licensing is
"believing that the world won't change". While licensing
won't change overnight, it will eventually to address changes in the legal
landscape. Just as there needed to be a GPLv3 to address shortcomings in
v2, there will be a GPLv4 and a GPLv5 some day, he said. Richard Stallman
will not be around forever, so you are placing your trust in the
institution of the FSF, he said. It would be better to place that trust in
the project itself and allow it to decide if any license changes are needed
down the road.
Essentially disagreeing with both, Meeks thinks that "or later" is
"vital". He says that he trusts the FSF and thinks that others
should too, but beyond that, "the FSF is less of a risk than killing your
project through bureaucracy". One reason that companies want to be
able to get proprietary licenses to free software is so that "they
can get patent protection that isn't available to us", he said.
There is also the question of patent licenses, Meeks said.
Harmony agreements assign patent rights along with the other rights and if
the code is released under a permissive license (e.g. BSD), the patent
rights accumulated by the company don't necessarily flow back to those who receive the code. It would
be nice to have the community be in the same boat with respect to patents
as the other companies
that license the code, but that may not be true if the Harmony agreements
are used, he said. "Harmony makes it more complicated, not simpler", he said.
Patents were "debated vigorously" as part of the process of
coming up with the Harmony agreements, Shuttleworth said. He was a
"tangential observer" of the process, he said, but did see
that the patent issue was discussed at length. The problem is that you
have to be careful what you ask for inbound with respect to patents if you
want to be able to use various kinds of outbound licenses, he said.
Patents are "a very serious problem", but the Harmony
agreements just give the ability to ship the code with a license to any
patents held by the contributor that read on the contribution.
The GPLv3 was designed to ensure that everyone is getting the same patent
rights, Kuhn said. Part of the reason for the update was because the GPLv2
was not as good in that regard, he said.
Dead developers and companies
The problem of the "dead developer" is one place where some
kind of copyright agreement can help, Sandler said. If there is a need to
relicense a project where one or more copyright holders is dead or
otherwise unreachable, what can be done if there is no agreement, she
asked. Meeks said that the "dead company argument is also
interesting". There are more developers than companies, so maybe
they die more often, but we have already seen problems coming from dead
companies, he said. "Plus" licenses can help there, he said.
Meeks also said that he was happy to hear that Canonical was using plus
licenses, but Shuttleworth was quick to point out that was not the
case. Canonical's preferred license is GPLv3, though it will contribute to
with plus licenses, he said.
We have seen problems with dead companies that have resulted in other
companies coming in to "pick at the carcass", Kuhn said.
Sometimes part of that carcass is free software projects where the new
company then changes all of the policies going forward, he said. The dead
developer situation is very different as there are very personal decisions
that developers may want to make regarding their code after they are gone.
That could include appointing someone to make those decisions—as Kuhn
has done—after they pass. Shuttleworth was skeptical about relying on
people to get their affairs in order before they go.
The panel wrapped up with a short discussion of competition, with
Shuttleworth saying that the free software world fears competition and
tries to prevent anyone from getting a competitive advantage. Meeks
believes that there is
already enough competition from the proprietary software companies, so
adding it into the free software community is not needed. Kuhn's position is
that the "ecosystem that has worked so far is a copyleft
ecosystem" without any kind of copyright agreement.
While interesting, the panel was given too short of a slot, so that it felt
very compressed. In addition, there was no opportunity for the audience to
ask questions, which is something that Kuhn noted as one of the most
important parts of any kind of panel discussion. The balance on the panel
also seemed a bit skewed, though, as noted above, that may roughly reflect
the community's opinion on the matter. A neutral third member of the
panel, replacing either Meeks or Kuhn, might have been better, though
Sandler did a nice job of steering things as a neutral moderator. In some
ways like the topic itself, the panel was quite interesting, but vaguely
unsatisfying. There are certainly no easy answers, and we will likely
struggle with it for many years to come.
[ I would like to thank the GNOME Foundation and KDE e.V. for their
funding my trip to the Desktop Summit. ]
Comments (40 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Desktop crypto consolidation; New vulnerabilities in ecryptfs-utils, flash-plugin, phpmyadmin, squirrelmail, ...
- Kernel: TCP connection hijacking and parasites; An EFI introduction; Network transmit queue limits.
- Distributions: Security testing tools for Fedora; Fedora, Gentoo, openSUSE, ...
- Development: Mozilla Tilt; Cython, KMyMoney, QEMU, Samba, ...
- Announcements: Lots of upcoming events