Leading items

Desktop Summit: Large companies and open source

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.

The detour

Because he 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 this thread) 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 those 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)

The story of apps.meego.com

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 apps.meego.com, 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 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 alternatives:

• 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 unlikely outcome.

• 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 server.

• 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 published.]

Comments (3 posted)

Desktop Summit: Copyright assignments

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 opposition camp.

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 position.

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 released under.

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.

Monopolies

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"

Shuttleworth 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 to 300 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.

Or later

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 their control.

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.

Patent concerns

There is also the question of patent licenses, Meeks said. The 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 projects 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 assistance in funding my trip to the Desktop Summit. ]

Comments (40 posted)