The responsibilities of ownership

Friday, July 22nd, 2011

In the open source community we make a very big deal about the rights of ownership. But what about the responsibilities?

Any asset comes with attendant costs, risks and responsibilities. And anybody who doesn’t take those seriously is a poor steward of the asset.

In the physical world, we know this very well. If you own a house, there are taxes to pay every year, there will be some bills for energy and maintenance, and there’s paperwork to fill out. I was rudely reminded of this when I got an SMS at 2am this morning, care of British Gas, helpfully reminding me to settle up the gas bill for a tenant of mine. If we fail to take care of these responsibilities, we’re at risk of having the asset degraded or taken away from our care. An abandoned building will eventually be condemned and demolished rather than staying around as a health hazard. A car which has not been tested and licensed cannot legally be driven on public roads. In short, ownership comes with a certain amount of work, and that work has to be handled well.

In the intellectual and digital world, things are a little different. There isn’t an obvious lawn to trim or wall to paint. But there are still responsibilities. For example, trademarks need to be defended or they are deemed to be lost. Questions need to be answered. Healthy projects grow and adapt over time in a dynamic world; change is inevitable and needs to be accommodated.

Maintaining a piece of free software is a non-trivial effort. The rest of the stack is continuously changing – compilers change, dependencies change, conventions change. The responsibility for maintenance should not be shirked, if you want your project to stay relevant and useful. But maintainership is very often the responsibility of “core” developers, not light contributors. Casual contributors who have scratched their own itch or met a work obligation by writing a patch often give, as a reason for the contribution, their desire to have that maintenance burden carried by the project, and not by themselves.

When a maintainer adds a patch to a work, they are also accepting responsibility for its maintenance, unless they have some special circumstance, like the patch is a plugin and essentially maintained by the contributor. For general cases, adding the patch is like mixing paint – it adds to the general body of maintenance in a way that cannot easily be undone or compartmentalised.

And owning an asset can create real liabilities. For example, in some countries, if you own a house and someone slips on the stairs, you can be held liable. If you own a car and it’s being borrowed, and the brakes fail, you can be held liable. In the case of code, accepting a patch implies, like it or not, accepting some liability for that patch. Whether it turns out to be a real liability, or just a contingent one, is something only time will tell. But ownership requires defence in the case of an attack, and that can be expensive, even if it turns out the attack is baseless.

So, one of the reasons I’m happy to donate (fully and irreversibly) a patch to a maintainer, and why Canonical generally does assign patches to upstreams who ask for it, is that I think the rights and responsibilities of ownership should be matched. If I want someone else to handle the work – the responsibility – of maintenance, then I’m quite happy for them to carry the rights as well. That only seems balanced. In the common case, that maintenance turns out to be as much work as the original crafting of the patch, and frankly, it’s the “boring work” part, while the fun part was solving the problem immediately at hand.

Of course, there are uncommon cases too.

One of the legendary fights over code ownership, between Sun and Novell, revolved around a plugin for OpenOffice that did some very cool stuff. Sun ended up re-creating that work because Novell would not give it to Sun. Frankly, I think Sun was silly. The plugin was a whole work, that served a coherent purpose all by itself. Novell had designed and implemented that component, and was perfectly willing and motivated to maintain it. In that case, it makes sense to me that Sun should have been willing to make space for Novell’s great work, leaving it as Novell’s. Instead, they ended up redoing that work, and lots of people felt hard done by. But that’s an uncommon case. The more usual scenario is that a contribution enhances the core, but is not in itself valuable without the rest of the code in the project being there.

Of course, “value” is relative. A patch that only applies against an existing codebase still has value in its ability to teach others how to do that kind of work. And it has value as art – you can put it on a t-shirt, or a wall.

But contributing – really contributing, actually donating – a patch to a maintainer doesn’t have to reduce those kinds of value to the original creator. I consider it best practice that a donation be matched by a wide license back. In other words, if I give my patch to the maintainer, it’s nice if they grant me a full set of rights back. While does a bad job with many other things, the Canonical contribution agreement does this: when you make a contribution under it, you get a wide license back. So that way, the creator retains all the useful rights, including the ability to publish, relicense, sell, or make a t-shirt, without also carrying all the responsibilities that go with ownership.

So a well-done contribution agreement can make clear who carries which responsibilities, and not materially diminish the rights of those who contribute. And a well-done policy of contribution would recognise that there are uncommon cases, where a contribution is in fact a whole piece in itself, and not require donation of that whole piece in order to be part of an aggregate whole.

What about cases where there is no clear maintainer or owner?

Well, outside of the world of copyright and code, we do have some models to refer to. For example, companies issue shares to their shareholders, reflecting their relative contribution and therefor relative shared ownership in the company. Those companies end up with diverse owners, each of whom is going to have their own opinions, preferences, ideals and constraints.

We would never think to require consensus on every decision of the board, or the company, among all shareholders. That would be unworkable – in fact, much of the apparatus of corporate governance exists specifically to give voice to the desires of shareholders while at the same time keeping institutions functional. That’s not to say that shareholders don’t get abused – there are enough case studies of management taking advantage of their position to fill a long and morbidly interesting book. Rules on corporate governance, and especially the protection of minority interests in companies, as well as the state of the art of constructing shareholder agreements to achieve the same goals, are constantly evolving. But at the end of the day, decisions need to be taken which are binding on the company and thus binding on the shareholders. The rights of ownership extend to the right to show up and be represented, and to participate in the discussion, and usually a vote of some sort. Thereafter, the decision is taken and (usually) the majority will carries.

In our absolutist mentality, we tend to think that a single line of code, or a single small patch, carries the same weight as the rest of a coherence codebase. It’s easy to feel that way: when a small patch is shared, but not donated, the creator retains sole ownership of that patch. So in theory, any change in the state of the whole must require the agreement of every owner. This is more than theory – it’s law in many places.

But in practice, that approach has not withstood any hard tests.

There are multiple cases where huge bodies of work, composed of the aggregate “patches” of many different owners, have been relicensed. Mozilla, the Ubuntu wiki, and I think even Wikipedia have all gone through public processes to figure out how to move the license of an aggregate work to something that the project leadership considered more appropriate.

I’d be willing to bet that, if some fatal legal flaw were discovered in the GPLv2, Linus would lead a process of review and discussion and debate about what to do about the Linux kernel, it would be testy and contentious, but in the end he would take a decision and most would follow to a new and better license. Personally, I’d be an advocate of GPLv3, but in the end it’s well known that I’m not a big shareholder in that particular company, so to speak, so I wouldn’t expect to have any say 😉 Those who did not want to follow would resign themselves to having their contributions replaced, and most would not bother to turn up for the meeting, giving tacit assent.

So our pedantic view that every line of code is sacred just would not hold up to real-world pressure. Projects have GOT to respond to major changes in the world around them. It would be unwise to loan a patch to a project in the belief that the project will never, under any circumstances, take a decision that is different to your personal views. Life’s just not like that. Change is inevitable, and we’re all only going to be thrilled about some subset of that change.

And that’s as it should be. Clinging to something small that’s part of someone else’s life and livelihood just isn’t healthy. It’s better either to commit to a reasonable shared ownership approach, which involves being willing to show up at meetings, contribute to maintenance and accept the will of the majority on major moves that might be unpalatable anyway, or to make a true gift that comes with no strings attached.

Sometimes I see people saying they are happy to make a donation as long as it has some constraints associated with it.

There was a family in SA that lived under weird circumstances for generations because a wealthy ancestor specified that they had to do that if they wanted access to their inheritance. It’s called “ruling from the grave”, and it’s really quite antisocial. Either you give someone what you’re giving them, and accept that they will carry those rights and responsibilities wisely and well, or you don’t give it to them at all. You’re not going to be around after your will is executed, and it’s impossible to anticipate everything that might happen. It’s exceedingly uncool, in my view, to leave people stuck.

It’s difficult to predict, in 50 or 100 years time, what the definition of “openness” will be, and who will have the definition that you might most agree with. In the short term we all have favourites, but every five or ten years the world changes and that precipitates a new round of definitions, licenses, concepts. Consider GPLv2 and GPLv3, where there turned out to be a real need to address new challenges in the way free software is being used. Or the Franklin Street Declaration, on web services. Despite having options like AGPL around, there still isn’t any real consensus on how best to handle those scenarios.

One can pick institutions, but institutions change too. Go back and look at the historical positions of any long-term political party, like the UK Whigs, and you’ll be amazed at how a group can shift their positions over a succession of leaders. I have complete trust in the FSF today, but little idea what they’ll be up to in 100 years time. That’s no insult to the FSF, it’s just a lesson I’ve learned from looking at the patterns of behaviour of institutions over the long term. It’s the same for the OSI or Creative Commons or any other political or ideological or corporate group. People move on, people die, times change, priorities shift, economics ebb and flow, affiliations and alliances and competition shift the terrain to the point that today’s liberal group are tomorrows conservatives or the other way around.

So, if one is going to put strings attached to a donation, what does one do? Pick a particular license? No current license will remain perfectly relevant or useful or attractive indefinitely. Pick an institution? No institution is free of human dynamics in the long term.

If there’s a natural place to put the patch, it’s with the code it patches. And usually, that means with the institution that is the anchor tenant, for better or worse. And yes, that creates real rights which can be really abused, or at least used in ways that one would not choose for ones own projects.

And that brings us to the toughest issue. How should we feel about the fact that a company which owns a codebase can create both proprietary and open products from that code?

And the “grave” scenario really is an issue, in the case of copyright too. When people have discussed changes to codebases that have been around for any length of time, it’s a sad but real likelihood that there are contributors who have died, and left no provision for how their work is to be managed. More often than not, the estate in question isn’t sufficiently funded to cover the cost of legal questions concerned.

The first time I was asked to sign a contribution agreement on behalf of Canonical, it was for a competitor, and I declined. That night, it preyed on my conscience. We had the benefit of a substantial amount of work from this competitor, and yet I had refused to give them back *properly* our own modest contribution. I frankly felt terrible, and the next day signed the agreement, and changed it to be our policy that we will do so, regardless of what we think about the company itself. So we’ve now done them for almost all our competitors, and I feel good about it.

That’s the magical thing about creation and ownership. It creates the possibility for generosity. You can’t really give something you don’t own, but if you do, you’ve made a genuine contribution. A gift is different from a loan. It imposes no strings, it empowers the recipient and it frees the giver of the responsibilities of ownership. We tend to think that solving our own problems to produce a patch which is interesting to us and useful for us is the generosity. It isn’t. The opportunity for generosity comes thereafter. And in our ecosystem, generosity is important. It’s at the heart of the Ubuntu ethic, and it’s important even between competitors, because the competitors outside our ecosystem are impossible to beat if we are not supportive of one another.

119 Responses to “The responsibilities of ownership”

  1. Joakim Says:

    Hello Mark.
    Im going off topic here but have you heard about ?
    It is not yet decided which OS they will use but they are saying “Either Ubuntu or Fedora; the main point in Fedora’s favour is their ongoing support for ARMv6 architectures.”
    I honestly believe it would be worth it for Ubuntu to support ARMv6 just to get involved in this project.
    People seems VERY VERY enthusiastic about it.
    They wont ship until November or so, so there is still time if they want to use 11.10
    Regards Joakim

  2. gourdcaptain Says:

    I’m very confused about one point. Presumably the patch is to solve some problem pre-existing in the work that the project leaders want solved or they wouldn’t accept the patch. Now there is work in accepting a patch. But as far as I can tell, the work they have to do is

    Total Project Work = Maintenece

    while if they don’t get the patch

    Total Project Work = Maintenece + Writing the Fix

    How does this somehow work out to the patch writer owing the project for the maintenence work they do?

  3. zelrik Says:

    I totally agree with MALCOLM MCEWEN.

    I have little real experience with the opensource development process but every time I read/hear about it, I feel the opensource community and the companies involved do not know what they are doing. So Mark, tell me why I am still stuck at the first line??? Am I a complete idiot or it does not make any sense? Perhaps you can teach a newbie like me how does that work?

  4. dizzywizard Says:

    Do you copy? Is it Right?

    I’ve just read through this very interesting post and discussion / debate. My (widely shared) view is that copyright in itself is in an bad place right now and is getting quite a bad rep as a raw material of the work of legal professionals rather than creative people. i use both propriety and open source and would like to favour open source more and see applications that are better than their closed source counterparts. paid for open source software is a good thing but it needs to be maintained, not just be left to become abandonware. everyone doesn’t need to be on the same page as we hurtle through the information age leaving trails of broken toys behind us. open source enable innovation but there is a need to create new business models that encourage the use of open source and of sharing the love / wealth.

    we learn by copying.. it is how we are taught in school.. listen, repeat, write it out 100 times.
    intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. intellectual property is bunk. (ok 10 will do)

    ..of course people should be rewarded for the good things they create. (in fairness)

  5. enedene Says:

    I’d like to suggest that all the future posts on Google+. I’m not here to advertise Google+ of course, but I think it could be a good advertisement for Ubuntu, for example Linus Tovards has a huge bunch following his public posts.

  6. Ryan Sharp Says:

    The thing is Mark, you want to build a profitable business on Open Source software but you also want the community to do all your donkey work for you.

    Red Hat contribute greatly to the projects they have adopted in Fedora/RHEL and dutifully maintain them at every level.

    Google have built Android on top of an Open Source stack and have been a runaway success, albeit in a different market.

    This isn’t simply because they have more resources – it’s because they “get” the mindset of Open Source developers and embrace it instead of trying to coerce it to their own business ends. Another reason is that they have a symbiotic partnership with Open Source communities as opposed to simply leeching off them like a parasite.

    You drone on and on ad infinitum about what “we” need to do as a community but fail to point out what’s in it for us. People *will* continue to develop software when it scratches their own itch and *will* continue to share it when it aligns with their philosophical goals. However they probably *won’t* spend any extra effort trying to make sure it fits in with your business goals unless you start contributing something tangible yourself. Contributing rhetoric, marketing buzzwords and community coercion doesn’t count.

    Going back to the Google/Red Hat comparisons. Google have built a LOT of free software for the Android OS. Even if one goes no further than to mention Dalvik – that alone makes Canonical’s contributions to the Open Source community seem pathetic (which they are). Red Hat are a similar story. Despite not creating much of a spotlight out of it, their email addresses can be found all over the commits logs of various high-quality packages.

    Now what exactly has Canonical contributed to the software stack found in Ubuntu? It basically boils down to the Ayatana projects, which are mostly just trivial little utilities and upstart and bazaar, which are fast becoming obsolete due to either their relatively poor quality or slow development.

    Your community relations people keep saying things like “we need a coherent developer experience”, “we need to maintain packages properly” and “we need drive adoption”. Who’s this “we” you keep referring to?

    I can get everything Ubuntu is offering in Fedora right now, which also happens to be much better engineered and doesn’t force copyright assignment on contributors.

    So if you really want to achieve all the goals your community relations people are rambling on about, DO IT YOURSELF. Don’t just try to coerce the community to do it all for you because quite frankly, all of the serious developers can see through your shroud of bullsh*t. The only folks who are lapping it up and asking for more are kids who don’t have the skills to make it happen (

    Let’s see some real commitment eh moneybags?

  7. Ryan Sharp Says:

    By the way, taking Banshee as the default Music Player is the worst engineering decision you have ever made. .NET/Mono is an huge monolithic standard library that duplicates most of the core of the GNOME platform. Now that we have GIR, stacking frameworks on top of frameworks is ridiculous.

    GNOME as a platform is by far the best of the bunch from a technical standpoint. C+GObject is a much nicer system to work with than C++’s ridiculous ever-engineering or C#’s ridiculous…well, everything. There is absolutely nothing wrong with the GNOME plumbing that warrants using trash like Mono in it’s place.

    The only thing the GNOME platform is lacking to attract new developers is sugar-coating and things that core developers have very little need for (all-in-one IDEs etc.).

    The guys with the skills to write a decent go-to IDE for the GNOME platform have very little personal motivation to do so. A project like this needs motivation in the form of cash. That’s where you come in moneybags.

  8. MattiK Says:

    “.NET/Mono is an huge monolithic standard library that duplicates most of the core of the GNOME platform. Now that we have GIR, stacking frameworks on top of frameworks is ridiculous.”

    This reminds me the current issue to write software native to Ubuntu: What is the preferred language, API and HCI guideline for Ubuntu software?

    Usability suffers severely if all software looks and feels different, and how about maintenance if there is lot of duplication? How it is guaranteed that all of duplicated work are maintaned properly that the software binaries won’t break in the future Ubuntu releases?

    Probably LSB compatible GTK+ 2.x and Gnome HCI guideline is the best for Ubuntu today.

  9. Ubuntu Podcast from the UK LoCo: S04E12 – More Tea Vicar | Ubuntu Forms Says:

    […] Mark Shuttleworth blog&#115&#32&#97bout copyright assignment […]

  10. Shuttleworth: All your rights are belong to us « Larry the Free Software Guy Says:

    […] take my word for it. Go ahead and read Mark’s blog for yourself. Make sure you read all of it, and you might want to have a cup of coffee before you […]

  11. S04E12 – More Tea Vicar – MP3 HIGH | Ubuntu Podcast from the UK LoCo team Says:

    […] Mark Shuttleworth blogs about copyright assignment […]

  12. Johnsie Says:

    +1 for Ryan Sharps comments. I can’t help but feel that Ubuntu is milking the sh*t out of the larger open source eco-system. Ubuntu is/was the biggest desktop Linux platform and yet you guys are contributing alot less code than other smaller distros. If people really want to help open source then they would be better using a distro other than Ubuntu. I agree with Ryan in saying that Fedora is probably a better option because they contribute more. As for Unity, well it just makes multitasking alot more irritating (like gnome-shell). Any new user interface should’ve been simply a better looking gnome2 with the same features and better polish. Now that Linux will have no good user interfaces I’m sure people will start going back to Windows. The Windows 7 bottom panel is a million times better than Unity or the Gnome Shell side bar.

  13. salemboot Says:

    Reinvention of one’s self is the problem I’ve noticed in the community-vast of projects.

  14. NoahY Says:

    “That’s the magical thing about creation and ownership. It creates the possibility for generosity. You can’t really give something you don’t own, but if you do, you’ve made a genuine contribution.”

    It all makes perfect sense, what’s these people’s problem? Mark and Ubuntu have given an incredible amount to the open source community, and now they’re saying if (and only if) you want to be a part of what they do, do it from your heart, either out of gratitude or belief in what they do. If you don’t want to be a part, go kick your can somewhere else. Coming here to whine and complain is pretty childish.

    The argument that Ubuntu contributes less code than smaller distros is pretty weak; Ubuntu, Mark Shuttleworth, and Canonical have all done great things for Linux, and you know it. Who does the size of the Ubuntu desktop platform benefit most? What is this milk they have gotten in return? I feel like I’ve milked the… whatever… out of Ubuntu, personally, but I am more than happy to give up code I write to the projects I write it for, because:

    – I use them
    – I believe in them
    – I am grateful for what they have done for me
    – I want them to continue to do it for me in the future
    – I want to help others, and I believe helping such projects will help others

    If the direction of such projects change later on, I would shoot myself before I started feeling regrets for code I had contributed. I’d just move on, as you are free to do. It certainly would decrease stress levels all around if you did.

    Mark, thanks for your vision and insight, and most of all for Ubuntu.

  15. Kurdistan Says:

    Stop releasing a new release every 6 month. The release cycle is a total mess. I hope you, Mark, will understand it one day. If you really want 200 million users of Ubuntu in 4 years. One of the reason I changed distro from Ubuntu to another Linux distro was because of the release cycle madness. Not even Apple or Microsoft release new version so frequent. Keep up with quality and stability not like now, quantity.

  16. Emiliano Says:

    Hi all!!! What about this? Many people loves gnome3…but Linux’s father doesn’t agree at all 🙂


  17. My.Sirimangalo | Blog | To Share or Not to Share Says:

    […] (source) […]

  18. ubeckoMINT Says:

    To me LEADERSHIP is a key word in all this, every project should have an owner and for practical reasons it’s desirable that he holds the copyright too, so he can FREELY define the evolution of he’s design and coordination effort.

    I belive that as long as the code is open sourced and it can be FREELY forked that doesn’t represent a menace to the values of open source community. Where does the contributions go? to some project you like or to the open source community? If the cool project happens to be open sourced you are doing both!!

    Why deprive the project leader of the entire capacity to decide what’s the next best thing to do? If you can always fork the project, what harm can be done to contributors? During the good terms all sides get beneficied from it!!

    Maybe after years of being supported by a loyal base the leader begin looking for his own malicious interest. Suppose he sells the coyright of a VERY contribuited code base, will the new owner have unfair competitive advantage from the comunity? the code givers loose something?

    This only keeps the leadership of the project CLEARLY defined. If you don’t like Gnome 3 and you want to do something more revolutionary and OSX-ky like Unity, why could community be able hold you down? Isn’t Open SuSe extremly 7-ish?

    Think that if Unity dooms Ubuntu, Canonical can always sell the project. I belive thats the motivation behind Mark’s move. That’s fair, cause there still be the good old Linux Mint.

  19. The promising OpenMediaVault failed its debut as free software project Says:

    […] it’s frowned upon by many free software developers. But why not, maybe he bought the argument of Mark Shuttleworth and wants to give it a […]