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. dragonbite Says:

    Nicely written entry. I’ve seen “gifts with strings” enough in personal relationships to know I want nothing to do with them.

    Thanks for giving some points of reference for code-based responsibilities.

  2. Justyn Says:

    It is enlightening to read and understand your motivations behind this thorny issue. In my view you make a persuasive argument.

    However, the Canonical CLA is causing such a lot of bad feeling in various parts of the FOSS community, and bad feeling tends to linger. It adds fuel to the demonization of Ubuntu amongst a demographic that should be its best asset.

    Fundamentally the CLA concept exists solely to prevent a plausible, but not guaranteed, future problem. At the moment though it is the CLA that is causing a very real and damaging problem itself.

    I don’t know what the answers are, but I’m hoping for something radical to clean out the rot creeping into Ubuntu’s reputation.

  3. Jeff Ratliff Says:

    If I give a gift to someone I don’t know, it’s different than giving to a friend.

    My worry is that if CLAs become commonplace, good coders won’t bother to contribute to projects they don’t trust. A written promise not to do evil with the code (the way FSF does with their CAAs) would go a long way to building that trust.

  4. Stuart Says:

    No matter how lengthy your justification, it will always be perceived that CLA == theft and that is a tough perception to crack when everything that Ubuntu is built on came to Canonical without a CLA.

  5. Jef Spaleta Says:

    If all the codebases in questions that Canonical controlled were licensed under BSD or MIT, I would find the argument about being generous compelling. But as it stands I find it hollow. The GPL specifically a license which puts constraints on how the code is used by recipients. Here is this gift of code given from Canonical to users under the _conditions_ of the GPL. If you want to show real leadership in terms of generosity, if you want to sound authentic, instead of just hypocritical, re-license all the Canonical owned code as BSD or MIT and implement a policy which requires contributed code for those projects to be under BSD or MIT licensing. Be generous with your code and put it under a permissive license that allows others to make proprietary products from it.

    BSD/MIT licensing moot entirely the issue of unequal rights inherent in copyright assignment because they are so permissive in nature that there really are no usage rights which can’t be denied _all_ recipients of the code…including proprietary re-licensing.

    Case in point. translations in Launchpad. All contributed translations are required to be BSD licensed with no copyright assignment requirement. This makes it possible for the Ubuntu developers to take those contributed contributions and mix them into projects with much more restrictive licensing, relicensing them at need, including taking them into and using them in Canonical proprietary stuff like say landscape or whatever. No copyright assignment junk required for translations. Just a permissive license. Everyone gets access to them on the exact same terms with nearly no restrictions. Your community of translators in launchpad are already exactly the sort of generosity you want to see..and no assignment required.

    You are already meeting the goals with regard to equalization of rights and future proofing licensing needs in the scope of contributed translations donations as you have laid out the arguments here. You have the ability and the power to force Canonical to follow a similar BSD licensing scheme for all the Canonical owned codebases. In fact you probably have the ability to enforce such a BSD licensing policy for all original works that flow into launchpad if you really wanted to.

    But we both know you aren’t going to do it. Because we both know, you see the value withholding some rights in the form of the GPL restrictions which keep recipients from proprietarizing the codebases. Canonical’s choice of license is strictly a strategic business decision, and not one based on generosity at all.

    Moving forward I believe Canonical has two choices available that are self-consistent.

    1) Start using a permissive license and really champion the idea of unrestricted generosity when it comes to contributions

    2) Require assignment, and _pay_ contributors a fair market value for the copyright for each of those assignments as if they were works for hire.


  6. blkjdkjnad Says:

    Why doesn’t Canonical just come out and say they’ll never abuse the copyright assignment for proprietary re-licensing? That’s essentially all everyone wants to here.

  7. mark Says:


    … because that’s not the point. The point is that we want a vibrant ecosystem, and that means (in my view) having a basis for companies to invest and gain an advantage through doing so. I love that some people start projects WITHOUT the need for that advantage, but I find it sad that they usually tire of those projects and move on, leaving them unmaintained. I want a free software ecosystem that is healthier. I KNOW it’s possible to build a non-Windows ecosystem, because iOS and Android have both done so. Neither has been ashamed to invite owned code onto their platform. We should do the same AND we should find ways to make as much of that code accessible under the GPL as we can.

    Instead, we play ideological cards, arguing that “no software is better than proprietary software”. That’s pointless, destructive and juvenile, in my opinion. We should embrace software development from across the spectrum, make paths for companies to participate in free softwre, give them ways to TRY publishing their code under free licenses to get access to contributions (don’t we argue that they will be better off that way?) but respect their right to change their mind if it doesn’t work for them.

    Now, Canonical could hardly encourage others to do that if it isn’t willing to take the heat itself. And we are. Thanks for the heat, now go change the world however you see fit.

    Finally, publishing code under multiple licenses is not abuse. Much of the very best tools in Linux came into existence, and grew to be great, because of this possibility. RMS recognises as much, uncomfortable as it is, in a very thoughtful read on the subject. You would do well to read his perspective and think about it carefully.

  8. maxolasersquad Says:

    For many, myself included, the GPL is a contract between the coder, and to all recipients of the code, both the general public and the “maintainer” of the project the code is for, to ensure there is a two-way street of trust of perpetual FLOSS of that code. If the “always open” stipulation of the GPL is incompatible with the vision of Canonical, then it should works towards a BSD/MIT license for the projects it creates and maintains. That’s the whole point of GPL. I am not going to contribut GPL code that isn’t really GPL in “special” circumstances.

  9. mark Says:


    I’m well aware of perception. I’m also firmly of the belief that this perception is wrong, and ends up entrenching the position of the original distributions in the ecosystem, because it prevents upstream-oriented companies from growing up in places where the big distributions can’t innovate as quickly. It suits them very nicely! So you might want to think about the idea that perception and reality are seldom tightly coupled, and wisdom is being able to see past the perception of the crowd.

  10. Nicolas Delvaux Says:

    I do agree that a contributor agreement has many advantages and that is should be best practice in most cases.

    > 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?

    This is not, IMHO, the problem with the Canonical CA.
    This should be: “How should we feel about the fact that a company which owns a codebase can drop the open product?”

    I do understand that binding a CA to the policy of another institution is not something that should be done (because we can’t see the future). However, here the point is Freedom.

    You can promise that one (or at least the contributor of the patch) will always be able to use, distribute and modify the project (feel free to copy-paste the 4 freedoms from the current FSF).

    Why not?
    Freedom is not something that really change with time. And even if it does, there are just two cases:
    – More freedom, which is compatible with the promise (because this is just a guaranteed minimum)
    – Less freedom, in his case I think we should be proud to impose at least those liberties to this dark future.

    But the main problem with the current Canonical CA, at least for me as a contributor, is that it shows you don’t believe 100% that free software is the way to go. It means that if some things change, Canonical may just turn proprietary instead of fighting for FLOSS.

    ps: I signed the Canonical CA, but I’m still not sure I was right.

  11. mark Says:

    Hi jef@fedoraproject

    A key challenge for free software, in my view, is how to encourage companies to invest in free applications or components. We have a very weak ecosystem at the moment. Many key apps are not widely available on GNU Linux, and the apps that are purely community maintained often struggle to find the resources to handle important issues like documentation, quality assurance. There are also relatively few jobs available to work on GPL code rather than proprietary code. I’d like to change that.

    So, I’ve been thinking about how to structure things so that companies which invest in code can gain a real competitive advantage while ALSO contributing to the digital commons – the code to which everyone has access under a free license. To that end, I think dual licensing is very important, and to be encouraged. So I think it’s important that Canonical set an example of being willing to do so, and in the process, be willing to take heat from those who think this is bad practice. I can’t in good conscience wish other, probably smaller, companies should follow an approach that I myself don’t have the guts to follow.

    In that light, I trust you see that your suggestion has little merit.

    A company that creates code has the moral and legal right to keep it secret. Publishing that code, as a working, complete codebase, is an act of some generosity. It is guaranteed to rule out certain business models which coulde generate a return on their investment. And it makes your world, and my world, much richer. I think that’s generous.

    By contrast, publishing a casual patch to that code under a restricted license, and refusing to contribute it to the owner of the whole codebase, is not an act of generosity. It’s an act of control; you’ve got what you needed, and you decline to offer the original benefactor whole rights to the work in question. Your contribution, should it be accepted, ties their hands in ways that they were not tied before you came along. Not cool, not generous. I think such gifts with strings are not gifts at all. I think our community is made up of widely divergent souls – there are those who love the fact that their efforts might actually improve the lot of others, there are those who are simply interested in solving puzzles, and there are those who think it’s their right to tell other how they should think, and what rights they should and should not have. And of course there are folk who combine elements of that.

    Personally, I love the former. That’s what I came for, that’s what I’ve stayed for. And I’m increasingly uninterested in the latter – ideologues, who do little but tell others what’s good for them while they more often than not do what they like in the same regard, are just not cool.

  12. ME Says:








  13. Jef Spaleta Says:

    Yes Mark,

    I agree, you aren’t cool.

    I also love how you completely ignore the specific Launchpad translation example I gave to support my pov. I’m sure I’ll get multiple opportunities to reiterate that point as your ideas presented here get re-broadcasted in your renewed effort to show leadership on the assignment debate. We’ve gone enough rounds now for you to know I won’t let you ignore salient points that sully your arguments quite so easily.

    But leaving that translator policy aside for a minute.

    You want _more_ GPL jobs? Okay…then get Canonical to show some corporate leadership on that issue and _pay_ for the value of GPL contributed code from your contributors when you put assignment requirements on them. I fail to see how a future ecosystem of copyright assignment to multiple corps helps generate paying jobs for anyone anywhere. If anything it depresses the value of those coding hours for giving corporations the perception that they can just dip into the vast sea of community and pull out ownership on contributor work anytime they need it.

    You know the saying.. why pay for the cow when you can get the milk for free. If you are not setting a corporate standard for _paying_ for the _value_ of assignments in a work for hire fashion you are not going to generate paid jobs. Mark, Mark Mark, you totally seem to misunderstand why drives the developer pay over in the proprietary world. Those companies, understand that the copyright on the code being written has value and they are paying for that on a work for hire basis.

    Mark, so much of the corporate centric view you present is very troublesome and runs counter to a long hard fought history in labor disputes. Do you know why SAG requires studies to pay minimum wages for non-speaking background actors in film and tv? Because not paying them hurts the entire ecosystem of actors because it gives those studios the ability to think its fair and perfectly acceptable to make a buck off someone who just wants to be in a movie for 10 seconds without financial compensation. In reality that sort of thinking is damaging and devalues the ecosystem of acting labor. SAG’s unionizing efforts counter the destructive self-serving corporate interests of the movie studios.

    Or if you don’t like that example…. I give you the American Organist Guild, which establishes payment guidance for organists at non-profit churches in the US. Now even here the interests of the entity…the specific church…tends to be to try to get organist labor as cheaply as possible…even free if they can find a person in their congregation with the skillset. However allowing churches (incorporated non-profit entities with a public benefit mandate) to use the power of the bully pulpit to guilt their own members into doing the work at a subpar wage, hurts the overall ecosystem for organists as it depresses wages.

    So no Mark, I don’t buy what you are trying to sell. Gifting resources to corporate entities does not build better, sustainable ecosystems with more paying jobs. You are absolutely wrong. I really hope your ideas are not picked up by other corporate entities, because if so, the long term damage done to this ecosystem is going to vastly overshadow any positive Canonical has had after it closes up shop or gets bought by Oracle or Google.

    So back to translators….
    Does Canonical happen to pay any translators at the moment in a work for hire fashion that gives Canonical ownership over those translations? I mean, you want a bright a vibrant backed ecosystem funded by company resources. Are there translators on staff at Canonical at the moment who are paid as part of their official job description to do translations? Or are you basically relying on those BSD licensed translations strings to trickle in from the community? Obviously non-English speaking areas such as China and India are poised to be big market potential for Canonical (depending on what you read in the laypress) is Canonical making the investment in work for hire translations to expand the “GPL” job pool?


  14. Pavel Says:

    your reply to Jef just nails the point. I was ambivalent to the Canonical Copyright Assignment before, but now that you give some insight on why it exists, I think it is a good thing.
    I think you should make it more clear that you are aiming at closed source software companies, to make them at least a little bit open. Furthermore you should state that you are aware that a CA gives the assignee a compentitive advantage (well thats the whole point of the CA).
    You could also state that you are trying to build a counter-example to OpenOffice with Canonicals CA projects. With OpenOffice Sun needed the CA to be able to sell OO to IBM for their Lotus Suite. But somehow all of this horribly failed. Maybe you have some insight about why and can say how you want to prevent this to happen to the Canonical CA projects as well.

  15. Luke Says:


    Here’s a solution, license your products under the GPL but accept patches under MIT, that’s exactly what Oracle do with Virtualbox when people don’t want to sign a CA, and it allows you to do what you like with contributed code without requiring copyright assignment.

    After reading the above post, you remind me of those charity collectors that you meet in the street that just don’t want you to donate, but they force you to sign up with a Direct Debit. If I want to give, I should be able to give on my own terms.

    Another thing that annoys me about this whole CA issue, is it’s massively anti-social. Imagine if I fork Unity, and then demand copyright assignment, how could someone submit a patch to both my fork and the original Unity?


  16. Paul Sladen Says:

    @Jef Spaleta: if you’re particularly interested in translations and the work that goes on there it might be worth emailing and speaking to David Planella who is the Ubuntu Translations Coordinator. (Canonical email address and IRC details listed on ).

    Hope that’s useful, -Paul

  17. mark Says:


    I think it would be very valuable if we could convince more companies sitting on proprietary code, to open that code under the GPL.

    I’ve often heard the argument made, by leaders in the open source ecosystem, that such companies should publish their code under free licenses in order to benefit from contributions, which broaden the appeal of their product and reduce the burden of development and maintenance. That sounds like an interesting proposition: the community do NOT have to pay to get access to what was privately owned code, the commons is enhanced, and owners receive contributions.

    So the “no pay” meme works both ways – you don’t pay to get access to code which is published under the GPL, and in return, I do not think that the owner should pay to receive a contribution as a gift. Yes, there is an asymmetry: the owner ends up continuing to own the code. But there is equally an asymmetry of responsibilities, the contributor does not have to maintain what they wrote, and has limited or no liability for the code.

    You ask, essentially, what the motivations would be for someone to give rights to code they wrote to another entity. They are many:

    * Gratitude. In the case of the casual contributor, that person has had the benefit of a whole work which serves a purpose and does most of what they want. In return, many people feel it’s right to demonstrate spontaneous generosity.

    * Care for the project. Where personal relationships exist, the contributor might feel it’s right to support those whose livelihood is dependent on the project. Alternatively, they may feel that their primary interest is in the future of the codebase, and they want to keep it in one piece so it stands the best chance of having a viable future.

    * Unwillingness to maintain a patch. Giving the code to someone else is a way of having them take on the burden of maintenance. Fair deal.

    * Community. The set of contributors build deeper, more meaningful personal relationships with one another. Some may work for the company driving the project, some may not, but they have a common platform and common goals. And you know very clearly that those who WANT to work for the company, and are active participants in its work, more often than not CAN. So there is no barrier between members of that community – folk play the role they do, by choice.

    .. and those are just the start.

    What are the reasons NOT to contribute? Ideology: if you feel that donating code might result in that code being available under a non-free license. But most open source contributors will just as happily publish a patch to a BSD project as a GPL one, so it’s not the possibility of proprietary code which is truly at issue. Instead, it’s concern about supporting the entity to which they are making the contribution on an asymmetric basis, giving that entity an advantage over others.

    And yet, that’s *exactly* what we need to offer, if we want more investment and more engagement in open source by companies. The trick is to offer such advantage equally to competing companies, each of which are maintaining DIFFERENT lines of investment in competing products. That way, you have a healthy ecosystem, rather than a summer camp.

    I find the arguments against creating advantage for companies weak on several fronts:

    * they are naive. The world continues to turn while ideologues debate, companies with deep ownership in their code, whether it’s open source (Google with Android) or proprietary continue to define the state of the art for most end users. We have been doing open source for twenty years and have not managed to shift that: the height of foolishness is to keep doing what you have done in the hope you’ll get a different result next time. We need to look hard at our way of organising and see how we can become more effective. This is not an armchair revolution. The revolution has stalled. Time to think again, and decide what really matters.

    * they are ungenerous. I am damn grateful for contributions given to me. I’m also damn grateful for works by other companies that I can contribute to, and even though I compete with them, I am perfectly happy to give them the benefit of what we do.

    In your characterisation of motivations, you limit the human condition to one of simplistic “pay for work”. I think being human is much richer than that. I think we can integrate normal economic motivations, competitive markets, corporate investment and many other things with the beautiful elegance of open source.

  18. woods Says:


    A very insightful article but I’m afraid you’re preaching to the converted.
    (because what all the ideologues seem to do is to try to shout you down and twist your words the harder you try to reason with them. Still, kudos for trying)

  19. Justyn Says:

    I find it a little bizarre that an open source proponent such as yourself is simplifying motivations to contribute to open source projects in such a way.

    Your argument is essentially that corporations believing they can get people to contribute for free to their open source software depresses wages. If this is true, then it is fundamentally the same regardless of copyright assignment, and you’re making a rather anti-open-source assertion.

    I don’t believe what you’re saying to be right in either open source or your example of the enforced minimum wage for non-speaking TV/film background roles. In both situations there is a profit-making company seeking to elicit some volunteer assistance in return for a non-monetary reward. But handling volunteer effort is fundamentally different from paying a professional to do a job, and requires extra effort on behalf of the company for a more variable result.

    I would say that the SAG rules actually artificially inflate wages. If the job of standing in the background being an extra can be done equally as well by a volunteer who wants to be in a film for a few minutes then fine, both parties benefit and we have a happy and efficient transaction. In reality the task of managing these non-professional volunteers and ensuring one of them doesn’t muck up the shot (or dealing with when they do) is a cost for the studio and they are going to want to pay experienced people when necessary.

    In the same way if a software company is able to solicit contributions for their project from the community then they still have to manage the code and the disparate contributors. We know from experience that this is not trivial and they are not likely to get the consistency they would expect if paying a professional to do the work. But if the company can keep such an arrangement working well then both parties benefit and here society as a whole benefits too in the form of more available open source code. Here you have to recognise all of the company’s open source code as a benefit since it is an important part of the bargain – they would have no reason to make it open source if they didn’t hope to solicit outside contributions. The contributor is self-evidently getting something out of the arrangement or they would not submit the patch (see Mark’s list above for examples).

    Companies that want to develop any complex work of software successfully are always going to have to pay developers to work on it. Getting free contributions does not lessen this imperative, and without the possibility of these contributions there would be no reason for the company to make their work open source.

  20. zelrik Says:

    I am sorry but I am still stuck at the first line.

    “In the open source community we make a very big deal about the rights of ownership.”

    Wait, can somebody own opensource code? How is that possible? Explain to me.

  21. Justyn Says:


    Your comment clearly shows your frustration with those who are too naive or idealistic to accept reality. As you say, the world is continuing to turn and other less open approaches are beating us. We need to face facts and adapt.

    Maybe you need to be bolder in getting this point of view across. It’s full of passion and frank substance but is hidden right down here in the comments. Perhaps you are too worried about offending people?

  22. Stuart Says:

    @Mark, It is precisely the coupling between perception and reality that I have commented on, and which you have clearly misunderstood. Perception, right or wrong, is the only currency in which Canonical’s future can be measured.

    The CLA is a job for Sisyphus, and you can obviously exercise your prerogative to squander Canonical’s resources and reputation in pushing a licence that everyone else regards as exploitative and abusive of the ecosystem in which Canonical currently thrives. Or you could reassess your own wisdom amongst others both inside and outside Canonical who do not share such an absolutist conviction.

  23. Justyn Says:

    Can I just say that Luke’s suggestion, apparently used for Virtualbox, for a company to publish code under the GPL but accept patches under MIT (which allows relicensing) seems like an awesome compromise.

    While it sounds less clean to have a main code base under GPL and a load of patches under MIT, is there actually any disadvantage?

  24. srinivas v Says:


    Doubting the FSF, on its values and virtues is as far as you can go in making your point. Your are commenting about all these people because of the huge amount of FaiF software available at your disposal. Your argument that what may happen to FSF after few years, has come true but with ur aspirations. All these days from the inception of ur project u have been goody goody with all the contributors and their code which is available to you so that u can play with it and comment on it. Now, u have come out with ur real ambitions. I dont know when RMS told that he does not consider releasing software as a dual licensing model. Pls qoute the case and the condition in which RMS did it.

    Do you go through RMS tweets,do you understand his principles and virtues. He walks his talk and has never compromised. He is the “ideal” example for FaiF. All other like you have to work towards his ideals. He is the Alps and the Himalayas which other mountains would be proud to become one day. I re-iterate once again and request all the developers and contributors to assign copyright to the free software foundation, instead of corporations who are not clear regarding the way to make money from FaiF software. I dont know, so dont flame me with that question.

    I request you to please re-think ur strategy of making money from ubuntu GNU/Linux. I also request you to stop ur harmony(cacophony) project and restrain urself from talking about how “contributor agreements” is going to improve the contributors themselves and is “not at all useful to canonical” You like a piece of code appreciate it and provide generous donations, thats enough. If the contributor/developer decides to make money out of it, he will definitely find ways to make it.

    I am tired of ur corporate talk. I am tired of hearing that FaiF contributors/developers dont have professionalism and some corporation(canonical) will teach them to that. I as a user, have understood the joy, the ecstacy with which the developers/contributors make their contribution to the FaiF software/documentation/ideas pool. U as a developer/corporate head have to understand that and stop teaching developers/contributors about how they should walk/talk/present themselves.

  25. Andrew M Says:

    Hi Mark,
    That was a well written post which explains your viewpoint with regard to contributor agreements and after reading I must admit that as a developer I would now be more open to signing such an agreement. However, the agreement would have to explicitly state that the agreement ends if the maintainer decides to switch / or offer a non-free version of said license ( or something which achieves that result ). ie GPLv2 to GPLv3, as in your example would be fine.

    That way, my ‘tiny’ (or not) contribution would ever wind up in non-free software. As a free software advocate your self I hope you can understand the reasoning.


  26. Jef Spaleta Says:


    I again I’ll point you to the examples of SAG and the American Organist union. Both of these historic real world examples have elements of community, gratitude, care for the project and all that other stuff you want to hold up. But at the end of the day a fair wage is a fair wage. Copyrights have value. The right to relicense in a proprietary fashion has value. The expectation that you can build an entire ecosystem where the independent contributors are okay giving up that value to corporate entities without compensation as employees is…amazingly myopic.

    But anyways… you continue to ignore the BSD licensed translation issue. Why is that? Its a clear solution to the problems inherent in the assignment policy. You accept contributions under a permissive license, and your employees write GPL code that you can then dual license in some sort of open core business strategy. Everyone gets access to the contributed code and your customers are paying for the stuff your employees have written. There really is no downside to that. And if over time the contributed BSD code dominates, then someone else can rip out your code and replace it more BSD and have an independent codebase.


  27. Neil Says:

    I have read the blog post… and the comments… I don’t get any of it.

  28. Dan White Says:

    This is a very interesting and thought provoking article. I stumbled on it from Linux Today before I noticed who the author was, and thought the first two thirds were apolitical, and presented some nice food for thought.

    There are two points which i think missed the mark.

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

    I see this as an impossible scenerio, and one that has already been dealt with in a rather ingenious way. If memory serves, when there was discussion of the GPLv3 license on the LKML, Linux explicitly relicensed his *portion* of the kernel to a GPLv2 only license (rather than a GPLv2+ license).

    The effect of that is that any external entity which attempts to game the system of a potential licensing flaw is going to have a lot of work cut out for them. Parts of the kernel or GPLv2, parts are GPLv2+, and parts may even be BSD licensed. Which parts are which depend on who the author was. The Linux kernel, in a way, is actually protected by its diversity and number of copyright owners. That’s probably mostly historical inertia, but also partly by design.

    Granted, this became an issue during the SCO trial, in which is wasn’t as clear as it should have been who contributed certain sections of code, and adjustments were mandated (including a signed-off by line for each patch).

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

    Most contributors today define explicit ways in which their code may be managed, with the GPLv2/v2+ license, which is in common use today… or the BSD license, or even Public Domain. That is to say, it’s the license rather than the copyright that’s usually more important to the contributor.

    If i die, and I’ve contributed code via GPLv2+ in the past, I’m not going to be very concerned about how my estate is going to be funded to deal with its management. That’s actually a little silly when I try to think that through. Do you think someone is going to sue Linus’ wife after he dies if there’s a bug in the kernel?

  29. peter Says:

    @Mark: getting the product back is fundamentally the way contributors are “paid”. Contributing is not philanthropy, it is scratching an itch, solving a problem for the contributor. If the project being worked on can be made un-available via relicensing at any time, then the contributor’s reason for contributing is far weaker. When I look at an open source project, I consider it an additional risk when there are few copyright holders, and a huge red flag when contributor agreements or copyright assignment is required. In fact, I simply move on at that point.

    If GPL is good enough for the company to use, it is hard to see why it isn’t good enough to reciprocate with. Wide distribution of copyright, and difficulty of changing licensing terms give me a huge sense of security.
    There is no argument you can make that will change that, and I do not believe that this attitude is rare among contributors, who are the main audience of CLA’s. This effort will not succeed, and will simply create ill-will.

  30. Stuart Says:

    I am rather new to this blog, so I am not sure if I am missing some ulterior motives, but I have read a few hundred of the comments to various posts.
    I first came to unix 21 years ago, in the form of SunOS, Unicos, IRIX. I wonder what has really changed in that time.

    I see merit in many of the comments, but I wonder if everyone see the big picture.

    With the advent of the iPhone, the market acceptance of the tablet (iPad), the increase in mobile processing power and improved displays, the move to the cloud and the focus on services, personal networking and data, the world is changing.
    The use of GUIs and touch screens, provide a level of separation for the user from the hardware and the OS. They don’t care what the OS is. (I suspect most people see the OS and the UI as the same thing.)

    People can already create content and apps, for iPhone, iPad, Windows Phone 7, Android and Blackberry. Many of these are given away free from app stores.
    It is this area that attracts a lot of coding effort and attention.
    Many of these apps are free, in that you don’t pay for them (the code is not free). Many apps have to be paid for. Many companies pay to have customised apps developed.
    Those who wish to spend their time coding have many outlets.

    Apple are moving to provide more harmony between the user experience on the phone and the tablet (I guess their laptops will follow), as is Microsoft with Windows Phone 8.

    Whether I pick up my phone, or a tablet, or a pc (and perhaps the car, tv, etc.) I can access the same email, see the same network sites, access the internet, access cloud content, etc. The device becomes only an access tool.

    The issue is what happens with Android. Where is the harmonisation with the desktop/laptop/tablet?
    It makes sense to provide some Linux based harmonised environment across phone, tablet and laptop, although the apps (in Java I think) could be written on any platform.
    I guess Google will try to make some version of an OS and use their brand to try to promote it on the pc, although how successful they will be I am not sure. Are they appropriate gate-keepers and the ones to cede power to?

    This is where the game is, IMO. This is where the energy and effort resides.
    I think the issue is which distribution wants to rise up and make it into the consumers consciousness.
    How can this be made to happen given the historical perspective and all the licence related issues, while keeping everyone on board?
    If it does not happen soon, then I think there will be another 15+ years before the next opportunity. The great satan 😉 Microsoft is weakened at the moment.
    Without mass market adoption, the number of jobs, corporate interest and funding and will be limited and the noble aims of free software constrained.
    It is possible that most people are happy with the <5% market share of the mass market and are happy to keep it a niche product, or only used in academic institutions or for servers.
    It is not cool to be mainstream after all.

  31. Randall Says:

    Mark, that was an excellent post and thank you for all that you do. As for some of the comments: “Haters Gonna Hate”. You are on the right path and I know that we will prevail.

  32. aPerson Says:

    okay, I’ll do it, and don’t respond to this, because I’ll admit its a bit pointed. Will Ubuntu be signing a CLA with the Debian project? Arguably, by a large majority most of the maintenance is done by them.

  33. Clint Byrum Says:

    [disclaimer: I am a Canonical Employee]

    Jef, I think your analogies raise some interesting questions which I’d like to explore further.

    The first question is about SAG. I don’t think we have to speculate much to answer the question of how much responsibility a movie studio has for taking a contribution from an extra. While the extra is on set, they need to be professional and follow directions, but after the shot is taken, the studio is done with them. They need only to promote the movie. The extra’s contribution was *required* but not exceptional, and the extra can point to the movie at 32 minutes and 15 seconds and say “there I am!”. This seems like a fair trade to some, but actors know that the movie would fail without it, and the studio has no real burden, so they’ve negotiated a wage for the extras.

    Open Source software is nothing like a movie. There may be a release date, but releases are just points in time where certain guarantees are made. The contributions made to the software are both an asset and a liability, and managing the ratio between the two is what separates successful software businesses from unsuccessful ones. If I submit a patch to Banshee to support multi-touch gestures, I’ve given Banshee something big. But when Banshee accepts it from me, they also accept the responsibility to keep that functionality in future releases, to integrate it with new changes, or to carry the burden of explaining to users why its being removed.

    I don’t think I’ve ever seen an extra removed from a movie post release.

    On the subject of Organists, this is even less like software. The organ playing is purely a service in the example you’ve given. For any service provided, there is a fair and equitable wage, and if an organization is needed to push wage payers to pay it, so be it. Once the organist has closed their hymnal and left the church, the church has zero responsibility.

    Contributors of software patches are more like the organist who has been recorded. Were it to be recorded, and the organ player paid as the organization you suggest mandates, the organ player would not be entitled to copyrights, because this was a work for hire (at least, in the US). However, if the organ player showed up, played the organ out of the goodness of their heart for free, and then left the recording at the church, they would still be the copyright holder. But again, what responsibility does the church have for that recording? Are they going to have to shift the focus of their programs because of that recording? Its basically the same as a movie.. something that could be cleaned up or polished a little, but doesn’t require *permanent* integration work to keep alive.

    I raise these issues because on the surface the analogies seem to be quite good. But its a common mistake to compare software to movies or music, when those things carry *none* of the ongoing maintenance and integration work that software does.

    IMO, software is too different of a thing to analogize at that level, and we’re still figuring out how to place value on it. Mark is saying that he believes the burden of maintenance far exceeds the burden of creation. I have to say, as somebody who has maintained patches of various open source projects because they were unsuitable for upstream, its a massive relief when upstream does accept the patches. I’m not thinking “damnit, why didn’t I get paid for that?” I’m thinking “FINALLY I can move on from that merge hell.”

  34. ScottK Says:

    @Randall: I don’t think that kind of dismissive attack on differing perspectives has any place in a reasonable discussion about and important topic.

  35. Jef Spaleta Says:


    None of the maintenance arguments require copyright assignment. It’s completely hogwash. When an upstream project takes in a patch, they can do so on the same condition as it was given. There is no need for a copyright assignment on the grounds of any maintenance argument.

    Mark wants to mix the value inherent in owning the code with other things. He wants to mix it all together and guilt us into giving away our copyrights to corporations so he and other business leaders can then turn right around and make money proprietarzing the code we contributed. Not cool. Not cool at all in fact. If Canonical wants to go it alone and wants to staff the manpower necessary to build a platform that they can proprietarize without significant contribution or a healthy development community to help offset the costs, they are free to do that. But to suggest that is what the ecosystem needs to do more of is very damaging.

    And he continually gets the details wrong about the history of Qt assignment. Trolltech put some very important protections in place on their own behavior via some latching conditions if the open version of Qt ever stopped being developed that would allow the codebase to be released under BSD, pretty much nullifying the competitive advantage the controlling entity would get. He doesn’t like talking about that very important detail when he holds up Qt and Trolltech as good examples of assignment gone right. I know he’s aware of the history and the latching BSD release clauses. And yet, Canonical continues to refuse to put _any_ sort of protection in place. It’s understandable that they wouldn’t commit to the very strong protections the FSF provides in their assignment agreement. Mark expects Canonical to need to produce some proprietary products at some point, and so do I. So the strong FSF-like protections would be incompatible with Canonical’s business needs. But the Trolltech-like protections put on Qt when Qt required assignment? Completely possible for Canonical to commit to and provide some protections against the most egregious future behavior. And yet they still won’t commit to that either. That lack of interest in providing any protections with regard to egregious prioritization of contributed code and good-will is a real problem. I don’t see it changing as long as Shuttleworth remains in control of Canonical. That’s a real shame. I know there are people inside the fenceline who’d be more than happy to take a step towards a more comprehensible position, they just can’t.

    But on to the point about what it means to have a work for hire development culture in software. Indeed analogies never always fit. Just like all the hand wavy analogies Mark put forward in his blog post. So lets talk directly shall we.

    There is a reason why software companies hire developers. Part of any such contracting is invariably because of a need for ownership of the final creative work. Typically if you work for a software company anything you produce working for them is owned by them, its standard work for hire situations. You are paid a wage to produce creative works for someone else. Your wage is the compensation for the ownership of the work. If a software company (or any company really) wants to own the creative work being produced and be able to use the exclusivity of that ownership to then sell proprietary versions (without competitors being able to sell it as well) of the work in question they need to pay the developers of the work. It’s a simple as that.

    Any company that requires naked assignment (without protections against bad faith actions similar to what TrollTech or the FSF provide) is just trying to get the milk for free. And its shameful when they do it. Shameful.

    Apple gets that. Apple pays a fair wage to its developers and designers, and the end result is they own the stack. And crazier thing is, there are people are willing to pay non trivial amounts of money for the end result.

    Android, the other platform Mark is very concerned about now, doesn’t require an assignment. and has the workings of an open development community styled around Apache.

    Let’s be very clear about that, Android.. the open platform that is kicking ass right now…does not require copyright assignment. Clearly if Google can make Android the juggernaut of OEM and user uptake that it is, there’s nothing stopping Canonical from following suit. Canonical does not need your copyright to compete. It’s a straight up falsehood meant entirely to encourage people to give up their copyrights so Canonical can proprietarize contributed code at some future date.

    In fact there’s nothing stopping Canonical from literally forking the Android codebase as it stands right now and building a competing product with differentiated interface bits and Canonical backed end services to replace the Google services. Again…all of this freedom to compete.. all done without an assignment requirement…just a contributors agreement which makes your attest its your code your contributing when you submit a patch for Android. And in reality, even that could probably be superceded with a signoff process which mimics the linux kernel’s sign off procedures to cut down on that paperwork. There’s some real benefits to keeping the redtape down to the bare minimum, but that’s another point, a point I think Micheal Meeks does a good job illustrating when he talks about libreoffice developer community growth. Anyways…

    Now does Google feel a higher maintenance burden for contributed Android code because they don’t own the copyrights? No of course not, that is absurd. The maintenance burden is what it is regardless of whether they own the rights to all the code. And the Android juggernaut keeps rollin’ rollin’ rollin’ along. This little side show about assignment is ultimately just a distraction for Mark and for Canonical, it’s not going to help them compete better in the marketplace its only going to serve to drain focus inside the company. It’s a real shame.


  36. tz Says:

    The GPLv2 and v3, and even the other licenses are designed to create a commons and prevent it from being partitioned or taken.

    There is a big difference between putting something into an escrow-like place where it is to be held safe against theft, and giving it to some entity that might or might not do anything particular with it depending on what they desire at the moment.

    Whatever else it is, Canonical is a corporation that I cannot trust that the goal will always be to maintain the commons as a commons. Things might change at the FSF or others, but I don’t see much potential of them turning into Evil, Inc. Or even just not-very-nice, Inc. The FSF is the corporate body of the GPL, so the GPL protections and the four freedoms are what it is likely to promote, or even if they go some other way it would fork as the GPL keeps the rights intact.

    Take a look at Open Office v.s. Libre Office. The latter has the bigger and more vibrant contributor community. The former has corporate support but few others want to touch it – though part of that was probably the long time Oracle held on to it. Oracle is currently suing Google over some parts of Java which should be open.

    I don’t want to empower Canonical to turn into an Oracle.

  37. srinivas v Says:

    @ Jef Spaleta

    Fantastic writing. Perfect. To the point. I doubt whether Mark can reply to that.

  38. Clint Byrum Says:

    Jef, I wasn’t suggesting that Canonical cannot maintain your code without full copyright assignment. I was simply suggesting that Mark’s point is that by agreeing to take the responsibility for the code, Canonical is at least providing some form of compensation to you. Whether or not that is fair is still up for debate, but it’s a hard thing to deny that it is worth something.

    To the point about Androids open model, I think you will find that several apps distributed with Android are completely Google owned and proprietary. It strikes me as a bit misleading to then say it is somehow more open than anything Canonical has produced, seeing as all of the software which Canonical has required CLA on are open source by definition. The Android platform policy is a lot more like the Ubuntu policy, which requires similar affirmations and no such assignment.

  39. srinivas v Says:

    @ Mark

    People develping FaiF software do it for fun. I am using them in my day to day life. They definitely are responsible when pushing out code to public domain. This code is more scrutinized that the code developed within 4 walls with strict time requirements. There is always a scope for improvement. There will always be developers to take over the baton when the original developer takes up some other hobby project or related jobs.

  40. aplblm Says:

    Really nice elaborating

  41. CCC Says:

    Let me see if I understand the argument here. Mark’s point appears to be, insofar as I can see, that the burden of maintenance is such that the maintainer should hold the copyright, and should be able to do what he wants with the code… including making it proprietary.

    Now, I do not have Mark’s experience with large software projects. In fact, I have very little experience with large software projects at all. But it seems to me that what we have here is a choice that needs to be made, and it needs to be made by the person who will be maintaining the software.

    The choice is simple; the maintainer needs to decide whether he believes, as Mark does, that maintenance is enough of a chore that he needs to have the copyrights in order to do it; or if he believes that the patches are worth the trouble of maintenance even without the copyright. I say that this is the maintainer’s choice because, ultimately, if the maintainer decides that the maintenance is only worthwhile if he has the copyrights, then ideally the maintainer should reject any patch that does not come with copyrights. He should explain to the contributor why the patch is being rejected, why he feels as he does, and ask the contributor to resubmit the patch with the copyrights (a form letter would probably do the job).

    If he accepts the patch without the copyright assignment, then he is implicitly endorsing the non-assignment of copyright – that is, he is telling the contributor that ‘getting your patch is worth enough that I am willing to maintain it even without the copyrights’. If Mark is correct, and the advantage of assigning the copyright makes a better software product than the contributors keeping their copyrights, then surely a codebase that insists on copyright assignment will do better than one that does not.

    Personally, I suspect that the one that insists on copyright assignment will suffer from a greatly reduced number of contributions, and will thus grow and adapt more slowly than one that does not require copyright assignment. Since it will grow more slowly, it will be outpaced over time by projects that require no copyright assignment, and will thus have more trouble facing long-term changes into the future.

    Copyright is not what makes a codebase strong. What makes a codebase strong is a strong supporting community; a maintainer should do all that he can to increase the number of people sending contributions in, because that increases the speed of improvements – and, yes, maintenance – that is done to the code. This copyright assignment idea will chase away a non-trivial fraction of the supporting community, and that will hurt the code.

  42. Randall Says:

    @ ScottK,
    My comment was not a blanket one. There is some great discussion and commentary going one here. Sorry I should have been clearer.

  43. Christian "kiko" Reis Says:

    I’m not sure what Jef is talking about, Android-wise; there is a CLA for the AOSP, and Linaro went through the process this year:

    More on the rules and process for Linaro contributions to Android at:

  44. Josh Says:

    TIL that Mark rails against ideologues while waxing poetically about his own ideology.

    TIL also that Mark’s views often conflict with, well, Mark’s other views. He wants a profitable “open source” business that owns people’s works in a way that is contrary to open source. He wants corporate consumption and cannibalization of works specifically designed to be free.

    It strikes me as odd that Mark argues for a proprietary future from open source ecosystem, one built from a free ideology, and has the temerity to play perplexed when this contrary vision isn’t embraced by those he ultimately plans to devour.

  45. If you want to destroy my sweater. Says:

    Is it just me or does half of this read like the “before” part of an advert for the Software Freedom Law Center?

  46. Jo-Erlend Schinstad Says:

    I came into this article with a very open mind. I actually didn’t have any opinion at all. There were some points in the main post that I couldn’t really buy into, but I wasn’t convinced they were wrong. I’m still not, but after reading the long list of comments, I feel I’m leaning towards being against these contributor agreements as a concept. I personally don’t feel any ownership of my code, and I certainly do appreciate the role of the maintainer, but it’s also important to me that my code will be useful in the future, both to me and my community. When you say companies should have the chance to change their minds, does that include their right to close their software, including my contributions so that future derivatives will no longer be useful to me? Because if that’s the case, it feels like helotism to me. I’m allowed to help build your house, and while it’s being built, I’m free to use the bathroom and kitchen — even have a nap on the couch — but once it’s built, you’ll wish me well and lock the doors. It’s entirely possible that I’ve misunderstood completely. It’s not an attack, but an inquiry.

    I whole-heartedly support your goal of making free software a viable business. Jef obviously does too, even if he disagrees with the methods used to achieve it. But whether contributor agreements is a good idea or not, it seems to me that the timing is all wrong.

    One final question: you say it’s important that companies are allowed to change their minds about open source software. Does that mean you also want Canonical to be able to take back the promise that Ubuntu shall forever be at least gratis? Because I can understand how people read this as “I intend to keep my promise, but don’t be disappointed if I don’t”. And even if you do trust the intention and don’t fear any cause for disappointment, it doesn’t boost enthusiasm — and that is worrying.

  47. Jef Spaleta Says:

    Jo-Erlend Schinstad,

    Please note that the current Canonical promise with regard to the Ubuntu brand is not legally binding. Unlike the protections against the FSF gives contributors who assign copyright to the FSF and the protections Trolltech put in place against egregious bad faith action when asking for assignment from indepedent contributors. Canonical has the ability to armor that promise in legally binding contractual language as part of the assignment process, Trolltech has provided a clear example to follow on how to do that. It’s not too late for Canonical to change its mind and take a more considerate, community-centric approach to gaining access to monetize the codebases they created with the help of community. But they must recognize the community’s interest in long term code utility beyond the constraints of Canonical’s business and provide some measure of protection in a legally binding way.

    If the promise is the intent…it needs to be codified into a legally binding agreement if Canonical is going to ask contributors to enter into such an agreement to contribute at all. Fair is fair.


  48. lalop Says:


    I do need to ask: you yourself have said that you can’t trust organizations like the FSF or Creative Commons not to have changed in the next few decades. But doesn’t this exact same observation apply to Canonical? From the perspective of an outsider, Canonical’s future Good/Evil status must be as much of a black box as the FSF’s is to you. (In fact, you yourself might not have any idea of it after you have passed on management!)

    It seems to me two observations are in order:

    1) You’re right about the patches being gifts – but to whom? People often contribute code because they’d like to benefit the community or the world; I doubt patchers are expressly motivated by “I would like to make this patch as a gift to Canonical, Inc.” Insofar as people are contributing patches, it is probably on faith that doing the latter will eventually lead to the former.

    Thus, contributing [with guarantees about freedom] is probably less like “giving a gift with strings” than “entrusting a gift to a trustee”. People don’t generally want their trustees to be able to behave wily nilly and horde the gift to themselves, and the fact that they are doing so is showing great faith in you and in Ubuntu. However,

    2) The current policy is burning through Canonical’s capital of goodwill. It’s good that you’re able to tolerate negative flak (especially for radical changes that’d be useful in future), but with all the directions the flak has been coming from (this, the Unity interface, Banshee) it should make one question whether there’s just enough goodwill to allow it all. Maybe one or just a few of these issues wouldn’t matter so much (people’d buckle up and say “oh well”), but with so many in quick succession, users or developers might be inclined to leave, or develop less software, or use Ubuntu with slightly less enthusiasm.

    Just my $0.02.

  49. kore Says:

    @Jef “canonical can fork android anytime”

    Please show me a link to the android 3.2 codebase – oh you can’t, because they didn’t published it. They violate or “stretch” the GPL and get away with it. Why? Because first and foremost they earned a tremendous amount of trust among developers over the last decade and they justify their decision with responsibility of ownership.

    Imagine some other random company doing so, would it be accepted? I don’t think so.

  50. Tom Says:

    @kore: Bzz, wrong. Android is APL, which allows withholding the source. They released the GPL parts. So no violation or stretching going on.

    @mark: Copyright assignment is stupid bureaucracy. I only creates ill will and in some countries it isn’t even possible (Germany). People and especially hackers hate legalese.

    Just take all contributions as APL. I really don’t get why that isn’t the perfect simple solution?

  51. Baptiste Says:

    Basically the debate boils down to how you view a healthy relationship between companies and individual users/developpers. You believe this relationship should be asymmetric: this is the Apple model of a semi-godesque leader bestowing his goodness to a mass of grateful and helpless followers. I (and others) prefer it symmetrical, and do-ocratic: everybody on a level playing field, and people who take responsability can get an advantage by driving the project. This is not “ideology”: your dream worlds is just not mine.

    If a project is of any use, companies will be more than willing to contribute to maintenance in exchange for power in the project. Proof: Canonical almost forked parts of the Gnome project in order to drive them towards its goals; I guess maintenance costs are cheap enough.

  52. Mark Shuttleworth calls for contribution agreements Says:

    […] ownership comes responsibility for his care, wrote Shuttleworth . In the software world, this means that code changes, questions answered or brand name must be […]

  53. Shuttleworth: The Responsibilities of Ownership « Linux News « 123linux tutorials Says:

    […] Mark Shuttleworth’s push for copyright assignment agreements takes an interesting turn with this lengthy post suggesting that contributors owe a project their copyrights since they are dumping a maintenance […]

  54. Jeff Says:


    I understand you have put a lot of money in to developing your disto of Linux “Ubuntu” and it’s third party counter part programs it uses and third party program languages. I understand what an investment is. I understand risk. I understand that you have made some success on the desktop and server front for Linux and Ubuntu. Unfortunately you seem to be discounting the amount help you have been receiving from the Open Source Community who have spent their time and effort (in hopes to make a point of good steward ship) to help you in your investment. The thing is Mark, I would have expected you to have known by now that most of these people (Open Source Community) are not doing the updates, fixes, or helping your developers so that they can get something done a to work, or to help themselves, or to make a profit in which it seems you are dumbing it down too… I think you know better. I would have hope that you would have been closer by now to see that we in the Open Source Community are passionate about many things. Money being the lest.

    “The responsibility for maintenance should not be shirked” – so why do this to all the dev’s and people how make possible the third party programs that let Ubuntu shine?

    “But there are still responsibilities” Since we are talking about On the other side of it. Even the greatest book and most printed book say “The worker deserves his wages.” Are you going to pay each and everyone of those who have given to your project – directly or indirectly?

    As we both know GNU, Linux and there programs didn’t start yesterday. The many years that the people working on each project didn’t receive your financial gain or support as they built their project. The same projects and programs that allow Ubuntu to shine. I don’t hear them with a, woe is me, I must seek high ground even though I have a large community that has dedicated resources to my project (the project that would be nothing without them).

    “If we fail to take care of these responsibilities, we’re at risk of having the asset degraded or taken away from our care.” – very well put, but remember this when you make decissions that affect how Ubuntu users,dev’s,companies, and open source community interact with Ubuntu. Weither you want to calm it or not – the Open Source Community is an asset!!! And by disregarding it’s help and resource as an asset to your cause you may find that the fate of the Open Source Communitiy working with you and your project may become null and void.

    “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.” – Lets be honest about the Novell and Sun thingy. This happen for the same reason Microsoft won’t give up the offending part of linux they say they can sue over! If Microsoft were to give that offending code then we would fix it.. and Microsoft doesn’t want to lose that mind foot hold over Unix/Linux. I feel people see that samething in your move to Wayland and Unity, instead of going with Gnome 3. I also believe you have something up your sleves with the Wayland and Unity that your not being upfront about. (Hints: proprietary licensing) No offense, just being honest – feel free to share.

    I some how get the feeling your forgetting your roots and your true help.

    per your “For example, trademarks need to be defended or they are deemed to be lost.”
    It works better when you as the company defend and let defend the ones who help you and it’s community – such as: Free Software Foundation – or how about software freedom – and you can always start on this page – A guide to helping the GNU operating system – .

    With the many changes I am seeing in Ubuntu’s recent past, it concerns me. You supporting Wayland and Unity and not Gnome. Your moving Ubuntu to BSD or MIT licensing. Going after Red Hat customers and NOT going after Microsoft clients? (It would be one thing if you have a list of Microsoft customers and you got some Red Hat. Am I missing something? Are you actually getting some of Microsoft customers, just not bragging like when you get Red Hat. I would think people would be more impressed you taking Microsoft customers.)

    In any case, these are just a few red flags that show me that you are not being straight with your loyal community, loyal customers and the loyal Open Source Community.

    You came in supporting the word Ubuntu and GNU,Linux,GPL… and now it’s talk of strings attached and switching to Canonical CLA. Hmmmm? Sound like you are setting up to do business with someone you know that the Open Source Community is not okay with. Am I reading your cards? :)

    Well my hope is that you help and not hurt the hands that truly feed you.

  55. Torben Says:


    The real problem of Linux vs. the Rest (on the Desktop) is simply manpower.

    Microsoft and Apple have about 3000 developers each chunking out code that is
    visible to ENDUSERS, not to server-admins on the shell. Thats the reason
    they can chunk out serious usability updates every 18 month.

    I never saw any opensource company putting in this type of manpower, and the
    constant “calling for help” from people who work on KDE or Gnome-Software
    shows that this is the core problem.

    No trickery with licenses and sources will bring you anywhere with your linux
    desktop. The problem is, that the community is “rewriting” KDE and Gnome since
    10 years, to make it easier to code to it for commercial entities – but those
    simply don’t think there is a big enough market to offset the costs.

    With the advent of VMs you could simply boot into a $office or you $paint app
    of your liking and still use your favorite $unix. So, there is a remedy for
    this “burning” issue.

    If you really want to play with the big boys, it’s not about source ownership.
    How about long term stabilizing the GNOME code base and asking the big players
    that you help them in converting the software for the Linux desktop?

    You know the trade with NDAs and all that corporate stuff – and in return you
    would get heightened support contracts from people who might want run $app on
    the linux desktop.

    I wonder if you could explain, why this type of code ownership or even
    selling proprietary unix-flavours will bring any more $app to the linux desktop
    and make it a “player” in the market. I fully understand your posts about this
    topic, but I have the feeling you willingly taking the heat for something that
    wont bring you any closer to that perceived goal.

  56. candtalan Says:

    A really good discussion, it is a credit to all contributors and not least to Mark.
    As I understand it, Canonical is using a new, untried, business model. The open exchange of ideas and opinions (here) is certainly like no other I have seen at this sort of level in any other organisation with commercial ambitions. I really hope Canonical will be successful over time. I support both Ubuntu and FSF spiritually, actively and financially. Both are doing what at first seems like impossible things. However, it is only with Ubuntu, with Canonical’s backing, that I see even a chance of dealing with Bug #1. The FSF are my inspiration, but after two decades their commercial influence is still small. Ubuntu is gaining ground, and if Canonical just does what everyone did in the past, then, the result will likely be – just what it was, in the past….
    I want more than that for the future.
    I want Ubuntu to be more successful, I want a strong commercial ecosystem to be
    encouraged and I sincerely hope and trust that a business model can be established, almost by definition, a new one, which will work well.

  57. DoctorMo's Blog » Blog Archive » Ubuntu Contributor Harmony Says:

    […] assignment in any quarter. Least understandable was the old Canonical contributors agreement, Mark wrote another of his personal defences in his blog on Friday; of what I consider to be unreasonable and assumptive. But this isn’t […]

  58. Jef Spaleta Says:


    When did Canonical officially switch to the new contributor agreement? The new agreement does not require ownership and thus moot much of the arguments you are standing up here. And is directly contradictory to your statement:

    “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.”

    Mark, why write all of this and stand up all this rhetorical about ownership if the plan, mere days after this blog post, was to change the policy such that assignment was not longer a key piece. Why waste the breath? Why waste the time? You could have spent the time to announce the new policy and explain why Canonical made the change a way from requiring ownership. That would have been sooooooo much better and proactive. Now with the policy change, all of this just looks like empty navel gazing rhetoric. What a waste. I’m very disappointed. I can respect someone who has an honest disagreement with me, and I’m more than happy to discuss that disagreement. But when they are just half-heartly arguing their points, sitting on information (like this policy change) that moots their arguments entirely..that makes me angry because it says to me they were just making a game of it. Well I hope kicking the ant pile was fun for you. In the future I’m not going to give you the benefit of the doubt and assume that you actually mean what you say. Not any longer. This little episode just proves the point, you are just having fun stirring up trouble and you really don’t plan stand up Canonical as an example to prove the points you are making.

    Good day sir


  59. Kevin Granade Says:

    A note on the new Canonical CLA,the only practical difference I can discern between the copyright license you are required to grant and copyright assignment is that with the license you can theoretically license the same contribution to multiple sources, whereas assigning copyright to multiple sources is not possible.

    AFAICT all of the arguments made in this discussion are equally valid for an “absolutely unlimited copyright license” as they are for copyright assignment.

    It seems less that Canonical’s attitude on copyright has changed, and more that it has been rephrased slightly.

  60. Justyn Says:

    Just looked at the new contributor agreement at (although I never read the old one).
    It means contributors to Canonical projects don’t hand over ownership of their code, they just give Canonical the right to do whatever they want with it.

    This looks like a pretty good solution in this situation, and I hope this will help people move on and deal with more important issues, like getting a great open source platform into the hands of the masses. Like others who commented on this post I am worried about the effect on Ubuntu’s reputation caused by the various clashes with the open source community.

    That Mark was prompting discussion before unveiling this new agreement may be because he was concerned that some people would react negatively to the approach (or indeed positively) simply because it is what Ubuntu have decided to do. Having the discussion beforehand helps see what people think without such influence on opinion. I see nothing wrong with that.

  61. Jef Spaleta Says:


    Interesting spin. Some of us have been debating Mark and other Canonical execs and managers on this topic for years now. Some of us have had our opinion about copyright ownership publicly ridiculed repeatedly by Canonical staffers. We’ve been called zealots and ideologues and worse because we’ve had the guts to stand up and debate the issue and to say forthrightly that we believe their chosen approach to contributors is bad. And now you are going to be an apologist for Mark deliberately manipulating the discussion on the eve of a new era in Canonical’s contributor regime? Really!? Nope, sorry. Not good enough. After I’ve shown so much restraint after Jono decided to turn my interest in solving the assignment problem into an April fool’s parody, I expect far better from everyone inside the Canonical fenceline than to make half-hearted strawmen. So go ahead be an apologist for such bad rhetoric. Doesn’t change the fact that Mark really blew the opportunity to be forward looking announce the new license. Mark’s brand of half-hearted mealy mouthed leadership is not what this ecosystem needs.


  62. Justyn Says:

    Well, I must admit I am surprised that Mark has not officially announced the new license along with a breakdown of why they have decided to take this particular approach, and whether they have been persuaded to change tack. Perhaps such a post is on its way.

    I don’t really follow the matter closely enough to know what you’re talking about in your reply, but you’re clearly very frustrated! If you’ve been disrespected by Canonical-related folks then I find that sad and worrying.

    Like with the Banshee referral situation and others, it seems that Canonical are doing a subpar job in minimising goodwill-sapping controversies with the FOSS communities. To what extent this is bad PR or bad policies is debatable, but to me the effects aren’t, I think they are doing real damage. I hope Canonical will strive to improve this relationship in the future.

  63. Roger Lancefield Says:

    @ Jef Spaleta

    When you start making rude, personal comments and challenging every commenter who dares to question your assumptions, it’s probably time to confine your frustrations over this issue to a more appropriate place, i.e. your own blog. I’m sure those of us who wish to continue receiving a dose of your opinions on this matter, on Mark’s failings as a human being and on Canonical’s disingenuous intentions, etc. etc. will be sure to check out your site on a regular basis.

    I for one would like to hear the opinions of some others, in a calm, constructive atmosphere, without every comment thread being hijacked by the more overbearing members of the FOSS community.

  64. ScottK Says:

    @Justyn: While I think the new policy of copyright license is an improvement over the previous copyright assignment policy, I still think it’s unfortunate. Any complex legal agreement is a barrier to contribution that I don’t think is helpful. It could be cured if they would “or BSD/MIT Licensed contribution”, but they haven’t.

  65. lalop Says:

    The new contributor agreement (from what I understand of it) is pretty damn sweet. It could, I think, use a little more PR on its main page, rather than just in the FAQ.

    @ScottK: Perhaps I’m confused; surely you’d be able to also release it under BSD/MIT, should you please?

  66. MattiK Says:


    This is a little off-topic but when it comes to taking responsibility, like making business with open source products, Ubuntu LTS short lifecycle is real problem. I’m setting up a company now and I’m very interested to sell computers with Ubuntu and there is demand. However, Ubuntu’s lifecycle is not enough for consumer protection law in Europe. If I sell computer to end user, it should work without any major problems securely at least two years. OS upgrades to next releases are too risky in Ubuntu so I can’t take responsibility what I sell to customers.

    Currently this means that Ubuntu is suitable only for seasonal product and all Ubuntu computers must be sold first year after LTS release, and it is almost impossible to have any stock. In addition to that, hardware compatibility must be guaranteed for at least next LTS release or more on certified hardware to maintain customer satisfaction.

    Only solution for this is that LTS releases must be supported with security patches at least four years. I know that this takes resources so maybe those six month scheduled releases have too much support. For normal end user, these are useless so it is pointless to do marketing for those and these may have end-of-life when next release is out. They are anyway for developers and nerds who like to use latest technology.

    I really like if you write something your blog for that topic WHY Ubuntu release lifecycles are what they are and why those six month cycle releases are marketed for end users, although the quality is more like “preview release”, not like final release that is ready for end users and production use in business.

    There is probably some good reasons related to development model and budget but I like to know more.

  67. Jef Spaleta Says:


    Yes, this a step in the right direction, but the need for a CLA is still going to hamper development contributor growth for the codebases. Business interests and overall project health are still in conflict with Canonical’s newer broad license approach. The CLA is still going to be a significant barrier to entry to drive by contributors (simply because its red tape that is going to prevent instant gratification)

    And reading the FAQ at #6, I’m not sure how to interpret the statement about the “promise-back” Which I think is referring to Section 2.3 in the new agreement. I’m not sure I completely understand what that section 2.3 is trying to say. but it might be a protection against them stopping open development in favor of entirely proprietary licensing. Not as strong a protection as the TrollTech BSD doomsday, but it might limit Canonical from taking the code into fully closed development and may limit them to dual licensing models. It might actually be an attempt to codify the Ubuntu promise into something legally binding. If only someone inside the fenceline had made an announcement about this instead of just leaking it.


  68. mark Says:


    You’re correct, in that a wide license grants essentially the same range of options as an assignment.

    The previous Canonical CLA (before Harmony) took the approach that we asked developers to assign their patch to us, and we granted a wide license back. So we retained a whole copyright, they retained wide rights in their code. That was relatively unusual among CLA’s in that most simply required assignment with no licence back. Not that it gained us much credit :-). The reason I think that we want institutions to hold whole copyright is that most projects go through phases of sexiness, and if they are dependent entirely on continuous volunteer contributions then they fade. I contrast projects like MySQL and Qt with others that don’t have that institutional support, and it’s very obvious to me that we would do better as an ecosystem with more of that kind of investment, rathre than less.

    I think the whole copyright owner has a much stronger long term argument for stewardship of the code, and wide rights are reasonable for the contributor. There’s a general preference in the open source community for wide license over assignment though; I think this is based on very negative emotional analysis, though:

    * a lone patch isn’t of value, except for a t-shirt
    * the individual contributor probably doesn’t want to maintain and legally defend that patch
    * the individual contributor probably does not want to take any risk of liability from that patch
    * credit can (and should) be expressed separately from copyright

    So from my perspective, a casual contributor is better off giving the ownership of their patch to the project, and receiving a wide license back in case they want to do something else with the same patch. Nevertheless, such assignment has two issues. First, some countries simply don’t have a means for copyright assignment – everything is done by license. So most general purpose assignment agreements have a fallback-to-wide-license to cover that. So, in that sense, if you are open to contributions you may not have whole copyright if you accept a contribution from, say Germany. Also, there is a stronger negative perception of assignment over license. As I said above, I think that’s based on shallow analysis, but it’s widely recognised.

    That’s why Harmony has two sets of similar agreements: one is based on wide license from the contributor, one based on assignment (with fallback to wide license).

    When we reviewed the Harmony 1.0 agreements, we decided to switch to the assignment basis, on the grounds that we had many contributors express a preference for it. Again, I think casual contributors would do better to understand the value of supporting investment in projects, and be more realistic about the actual value of retaining ownership in their patches. But wide license is good enough for us, good enough to create a more potent FLOSS ecosystem, which is my purpose in pursuing this work in the first place.


  69. mark Says:


    I disagree: the real power of Apple, Microsoft and Android is in the third-party developer ecosystem, not in the core. Open source communities can keep up with the “brilliant core” engineering efforts of any of those companies, but they struggle to match the breadth of quality assurance, documentation, design and marketing of them. And where FLOSS really struggles is to create an ecosystem of companies that invest in applications, because open source business models are extremely difficult if your focus is the software (and not a related piece of hardware, or service).

    There are many things we need to improve. Simply having easier business models in the ecosystem would not be a panacea. But it would help. And right now, there is very little understanding of that issue in the open source community, which is why I’m raising the profile of the issue here.

  70. mark Says:


    It’s very true that something like Ubuntu cannot come about solely through investment: it’s the combination of community and company which makes Ubuntu so different, and potentially so very important. I know that more than most. However, I think it’s possible to attract contributions on BOTH sides of that fence without pretending that one or the other is dominant.

    People work for love or money. Both are important in FLOSS, and in Ubuntu.

    Those working for love, probably want to feel that their volunteer efforts are going to have the biggest possible impact. In part, having partners working on the project who are full time paid helps that; those folk get to do the diligence, the process, the QA, the meetings, the planning. Volunteers get to do what they want, and STILL get more done, more satisfaction, than they would if they were contributing to a volunteer-only effort which was constantly begging for help and resources. I think the scale of Ubuntu’s community is in part a reflection of how satisfying it is to work in an environment which is partly staffed by full time professionals. Pure-volunteer efforts are often stuck, often blocked, often begging for help. That’s not to downplay their importance, but instead to say that working on Ubuntu as a volunteer can be more interesting and more fun because of that other half: the company.

    Similarly, those working for money often find it more stimulating if they can do so more openly (albeit never completely openly). Working for a company that is engaged in open source is more satisfying than working for an investment bank.

    So this is a story of complementary motivations, NOT a story of exclusive moral high ground for either side. And it’s important for everyone who wants to work with Ubuntu to understand that. I think most do.


  71. Justyn Says:

    Thanks for explaining.
    I think being a bit flexible based on the desires of the community, vs your own belief in how it should be done, does you credit.

  72. mark Says:


    We (Canonical) have signed many contribution agreements with companies and non-profits that are stewards of upstream components, from the FSF to MySQL and Qt. If Debian had a whole copyright on something like dpkg, and asked for assignment of work by Canonical people, we would gladly sign that too. And we would encourage volunteer participants in Ubuntu to do the same, because from my perspective that’s what contributing to *somebody elses project* is all about.


  73. Shuttleworth: Contributors Owe Us Their Copyrights Says:

    […] his latest blog post, Mark Shuttleworth argues that contributions cause a significant maintenance load to companies and that contributors […]

  74. mark Says:


    I know that the idea of someone’s code winding up inside a proprietary version of a product is upsetting. My point in this series of posts is to show why the free software community should soften its position, and work to attract companies into the ecosystem as actual drivers of projects, rather than as tangential beneficiaries and contributors (as we have today).

    Most open source contributors will just as happily contribute to an MIT, Apache or BSD project as they will a GPL one. All of those licenses allow proprietary editions. And many of the projects which *companies* setup or invest in, prefer such licenses for that reason. Android, Postgres, and of course the new OpenOffice push, are all examples. The question is whether we think it would be useful to get more corporate support of the GPL. I think it’s good, and possible to do this, by encouraging companies to use the GPL and in exchange offering them true contributions.

    Again, this will not be a panacea. But it will make a difference.

    I think we should examine our reaction to the idea that a patch “might find its way into” a proprietary version. If that code was BSD, would we be so upset? Why do you think RMS encourages, with careful thought and subject to a wider understanding of what’s going on, dual licensing? I think it’s because this is a good way to grow the body of code under the GPL. Your contribution, in such an arrangement, will ALWAYS be available under the GPL. That cannot be undone. We should be happy to gain the GPL’ing of the main part of the codebase, and willing to accept that the company in that case may, or may not, be able to sustain it’s GPL position indefinitely. What is released is always released. We should not try to manipulate future choices, just as we would not accept having our own future choices restricted.



  75. mark Says:


    We’re both speculating as to the likely behaviour of a complex system under unpredictable circumstances. I would read your history as supportive of my point: when there is uncertainty, Linus is able to exert leadership. remember, he can relicense his code again differently, and if it were appropriate for him to lead that way, I suspect he would. He’s very pragmatic. In the analysis, he preferred GPLv2 to GPLv3. Personally, I think v3 is the stronger license, but I understand why he felt that way.

    Now, I also understand that smart people change their minds when the facts and circumstances change. If GPLv2 were under serious legal threat, so that it did not even deliver what it’s widely assumed to deliver, it would be smart to move to something new. Linus would do that, and others would follow, and the gap of code unaccounted for would simply be handwaved over. I think it’s better to address the potential need for that up front.


  76. MattiK Says:

    @Mark: “I disagree: the real power of Apple, Microsoft and Android is in the third-party developer ecosystem, not in the core. Open source communities can keep up with the “brilliant core” engineering efforts of any of those companies, but they struggle to match the breadth of quality assurance, documentation, design and marketing of them. And where FLOSS really struggles is to create an ecosystem of companies that invest in applications, because open source business models are extremely difficult if your focus is the software (and not a related piece of hardware, or service).”

    Well, I think best thing in the open source is that when there is working open source solution, it prevents proprietary software to set prices high and monopolize market segments by tying customers to propietary technology. Open source importance is crusial if there is lot of dependence some piece of software, so it really matters lower level software and when avoiding proprietary fileformats and protocols. End-user applications, it doesn’t matter that much is it open or closed source. Example most of the software I use are open source but I prefer closed source in games. In fact, easiest way to prevent cheating many cases is using closed source.

    This leads conclusion that Ubuntu should be more attractive to closed source software developers too. And how this is achieved, most important thing is long term stabilized platform. Good news is, we actually have it. As long as LSB compatibility is maintained, platform is good. Java platform is other important platform, especially in business use. This is so important, that Ubuntu development process must include routinely testing all available POSIX and LSB testsuites and JCK and compiler tests too, and targetting to get every release more complete tests. Of course to attract developers, it is important to aim newest LSB and Java. Ubuntu 11.10 should be LSB 4.1 and Java 7 compliant that rest of the bugs can get rid off before next LTS. Progress of passing tests should NEVER go backwards in newer Ubuntu LTS releases. It is less important how good performance there is or what new fancy features new version have. Of course it is correct to use newer release of compiler before LTS even if doesn’t pass all the tests, because newer release may break something even if tests are passed. Better to break software on six month cycle release that there is time to fix them before LTS.

    What comes to documentation, developers may need guidance what components are stabilized long term, it should be tell clearly how long and there should be guidelines for preferred APIs when developing software to Ubuntu. Because Ubuntu start moving to Unity, it requires Human Interface Guideline -documentation to get preferred look & feel to Unity desktop.

    What comes to marketting, best way is to get product enough good for preinstallation, in factory or independent system integrators so they can sell the Ubuntu and get profit too. I can see snowball effect coming future when indepedent software vendors are developing/porting lot of software to Ubuntu and Ubuntu is installed ten-fold larger scale. It requires however at least four year support for LTS on desktop and hardware compatibility must be maintained to next LTS when upgrading on certified hardware, and making it attractive to closed source developers too. I also keep prioritizing of six month cycle releases first in download page marketting failure because it doesn’t mention any warning that they are so bleeding edge.

    Open source software clearly kicks off proprietary software almost everywhere now but end user should be high priority and keep platform attractive, and it is not wrong if end user uses closed source software. When the important things are done in platform development process and support, focus may be then shifted more to get applications too more open sourced.

  77. mark Says:


    Perhaps I have not made my points very clearly, because the way I think about it doesn’t match what you’re describing :-)

    First, I’m not talking about works designed to be free. I’m talking about works brought into existence through the force of will of an institution. The Linux kernel isn’t a good example, by something like Qt is. Or Unity. Or MySQL. Now, there are huge numbers of copyright codebases that are entirely proprietary. I would like the owners to give serious consideration to open sourcing those codebases. I specifically don’t mean “abandon and turn over to ‘the community'”. I mean “publish under the GPL while continuing to invest”.

    The problem we currently face is that, in the absence of a clear contribution agreement, this is a one-way trip. Worse, there are few stories of great success on the other side of that one way trip. So companies are understandably reluctant to try it. You cannot unmix paint.

    I’m saying that, in those circumstances, we should be willing to make a trade: we’ll offer our contributions as genuine gifts, without strings attached. They publish the whole lot under the GPL. And here’s the key bit we have to accept: if it doesn’t work for them, in the long term, they have the right to change their mind. They can then close the gate, and continue working in private. They cannot retrieve what has left the factory: what was published under the GPL, including our contributions, remains so. But they have the option to go private, and we have the option to continnue in public.

    That seems to me to be a reasonable proposition. I think we need reasonable, pragmatic engagement if we want to build a winning ecosystem. Naive views are often attractive, but poisonous. It’s naive to think that a society will be healthier if it is “purer” in some sense; that way lies madness, though it seems, when carefully phrased, to be attractive. Equally, it’s attractive to think that we should tie the hands of every participant in the ecosystem. Instead, we should encourage people to contribute to the body of work under the GPL, we should recognise the value of stewardship and maintenance and concentrate the responsibilities for that in the place it can best be handled. We should also recognise the benefits of competition, so for every MySQL we should try to ensure there are alternatives that are equally well positioned to compete.

    We have lots of data to work with in this analysis. This is no longer a theoretical exercise. Look at Qt vs Gtk. Qt is deeper, stronger, more complete, more widely used and usable. Why? In part at least because it had a persistent backer who had rights to make proprietary arrangements around the code. I absolutely think we should challenge our own assumptions when the facts don’t fit the theory, and there are now enough examples for me to be convinced that the so-called “inbound outbound equality” story is a nonsense. The net effect of an open source ecosystem which has weak upstream code ownership is to strengthen the position of the distributions. I think that weakens the long term prospects for the movement, because is results in relatively few investment centers: do you really want most of the money flowing into open source to flow through Red Hat, Novell and Canonical, in that order? I don’t think so. You want it to go to Cassandra, and Mongo, and Redis, and OpenStack, and Eucalyptus, and all the places that really drive innovation. Think about it.


  78. mark Says:


    Your analysis there is based on common thinking, that a project which can accept contributions more easily will get more of them, and thus will be more agile.

    And in the short term, this is true. I’ve seen lots of projects start up quickly and “sprint”, and in that burst of energy they cover a HUGE amount of ground. The early parts of history for many open source projects are like that.

    And then reality catches up.

    The early contributors are often folk who have time on their hands. They are either students, or they are folk who are trying to solve hard problems in a company and they have little in the way of management burdens and responsibility. They move on or up, and suddenly people have less time.

    All that sprinting often results in debt, too. Technical debt. All the patches that were accepted easily were accepted without tests, or without documentation, because that would be “friction” or a “barrier to contribution”. Suddenly, the project which has the lower barrier to contribution looks weaker.

    This is where Gtk is today. It has suffered from a lack of ownership, which translated into a lack of leadership, focus and maintenance. I respect the Gtk community and admire their intellect and energy. But they are setup to compete badly in the long term, and I think it would be better to recognise that and address it than to pretend otherwise. I am not saying this to hurt anybody’s feelings, but because I think that reality is important to recognise and plan for. It would be better for me if Gtk were a really effective competitor, because the competition between Gtk and Qt would stimulate innovation. So, I’m making this argument not because I think Gtk is cooked, but because I want a more effective, more competitive, more dynamic ecosystem. And that will require more investment from more companies; this is one way to facilitate such investment.


  79. mark Says:

    Dear Jef@FedoraProject

    My views are unchanged: I think it is healthier for contributors to partner with strong companies to ensure the long term strength of the codebase they are investing in. I think that relationship is best reflected by consolidating ownership of upstream codebases in a set of competing institutions, with volunteer and other scratch-my-itch contributions being assigned, and wide licenses back to the author of the patch. I think the exception to this is the case where a contribution is a whole component, or plugin, which has an identity of its own.

    Those views are my own, and they remain unchanged.

    Canonical has done two things:

    First, it opted to move from its own, custom, mediocre CLA, to one of the Harmony agreements. Those have been through a process of debate and discussion and review. Despite your efforts to characterise that process as closed, it was open to anyone who wanted to participate from the beginning, including those who fear, resent or disagree with the fundamental existense of CLA’s. As a result, the Harmony agreements are more rounded, better phrased and more likely to withstand legal scrutiny than anything an individual attorney is likely to come up with.

    Second, it opted to move from a CLA which is of the “assign and receive a license back” approach, to the “grant a wide license” approach. This is because of the strongly expressed preference of many developers to this latter approach.

    The reason I don’t think a wide license is the best approach is because it sweeps under the carpet the core of the relationship, in a company-lead project, between the contributor and the company. It’s really important, in my view, to recognise what BOTH parties bring to the table. Open source is wonderful because it can bring together those who work for love, and those who work for money. I think it weakens our position to pretend that one or other of those groups has a moral high ground or natural lead.

    I think many companies have a position on copyright and code which is carefully constructed to play to contributors vanity and fear, while really serving the company interests. I prefer not to hold such a position: I think relationships are stronger when they are founded on a clear understanding of what everyone brings to the table, and mutual respect. There is little respect, or insight into, or understanding of, what companies bring to the table amongst those who think that the open source ecosystem is entirely based on altruism and freedom: in fact, it’s energised in equal measure by self-interested directed investment and social dynamics, and we could strengthen BOTH of those by acknowledging them.


  80. 451 CAOS Theory » 451 CAOS Links 2011.07.26 Says:

    […] Mark Shuttleworth discussed the responsibilities of [copyright] […]

  81. Jef Spaleta Says:


    First let me just say the change in the agreement Canonical is using moot much of the details of Mark’s original blog post. And I have been making my arguments in the context of that original post. So with the content mooted by unannounced policy changes at Canonical a lot of this is pointless navel gazing now.

    But I want to address just a couple of subtle things in your comment to me.

    I’m not arguing Android is _more_ open or not. I’m arguing that its more _fair_ to the interests of external developers. The bits that Google wants contributors to help with are licensed symmetrically. The versions of Android (the platform) that I can contribute to I am also able to take and fork and build a proprietary product of… just like Google!!!!! Is what they are inviting me to contribute to the whole stack in their product? Nope. But they aren’t inviting me to contribute the rest of the stack they are keeping control over. That’s fair. The bits that are closed Google is doing in house with paid development work in a work for hire fashion. Its a hybrid model..and its a _fair_ hybrid model. As an external unpaid contributor I’m not being asked to give up anything, nor to give Google an advantage over any other interest including my own long term business interests. I don’t know how to make it any clearer than that. When you invite people to contribute, to help you build and maintain the code (patches which fix crashers are maintenance being done by externals that you aren’t paying for), treat yourself like an external and give everyone equal conditions to make use of the shared value. That is fair. You give up some control, to gain access to the external labor pool to help build your product.

    What Mark is champion is not _fair_, nor is it completely open. Clearly Mark is very interested in some sort of hybrid model moving forward that mimics the success of Android and can support closed application development. He’s making that clearer and clearer the more I poke him in the eye. Mark wants to see proprietary _applications_ on top of some sort of platform definition. the games in USC are a first step along that path. He is very specifically and very deliberately not champion a pure open system. What Mark wants to see appears to just a new variant on the open core idea. No one here is arguing a completely open system, not even me. Will Canonical create proprietary applications in the future that live in USC for purchase? It’s not out of the question. If the Ubuntu community is okay seeing other developers place proprietary products into USC, surely its acceptable for Canonical to do the same.

    And even with out assignment in the new contributor agreement, my point continues to stand. When the licensing is reciprocal and symmetric, when all participants have access to the code under the same conditions, you end up with a healthier external development community that can support multiple competing business interests as well as individual contributors. When one company stands themselves up with specialized rights and breaks that symmetry, its going to impact the breadth of that developer community. The new broad license Canonical is using will continue to be a deterrent to many skilled contributors. The assignment clause was egregious (as it created an eclusivity that made it possible to layer with peer agreements of a similar construction), and its gone, but the new agreement itself is still problematic and will be a road block to building a healthy development community (a problem for Canonical’s community team to mitigate). The new agreement meets my personal requirements so I feel comfortable submitting critical crasher fixes and what not found in Fedora packages of Canonical codebases on behalf of fedora users, but I’d still won’t be contributing anything like a feature enhancement under this new agreement because its not symmetric.


  82. Jef Spaleta Says:


    “Now, Canonical could hardly encourage others to do that if it isn’t willing to take the heat itself. And we are. Thanks for the heat, now go change the world however you see fit.”

    You can’t say things like that and then tell us that you were just speaking for yourself and not for Canonical. You were absolutely speaking for Canonical there (unless SA English has some weird grammar rule which allows ‘we’ to mean ‘myself’.) Stop the backpeddling, stop making it worse. You were using your position as a Canonical exec as a bully pulpit for your personal views. Stop it. That’s just absolutely dumb and abusive of your position in the organization. if I was on the board of directors of Canonical I’d haul you in to my office, by your ear, and give you a very significant CoC shattering shaking down for your behavior for squandering the Canonical brand like this.
    It’s really a shame there’s noone inside the Canonical fenceline that can hold you accountable for not taking better care of the Canonical brand and identity. If you really were trying to speak for yourself, and not leverage your position as a Canonical exec, you would have you vastly different language to avoid representing Canonical. Both you and Jono do a absolutely horrible job at delineating a space between corporate policy and personal belief since you use the same communication channels to talk about corporate policy as well as personal ideas. And since I know that you are not a stupid person, I’m not placated by the “I was just speaking for myself” dodge. You screwed up here in your handling of a messaging opportunity. And Canonical has screwed up by making the contributor change so silently after you have been so very vocal over the last couple of years about the need for Canonical’s assignment clause.


  83. Jefster Says:


    So much hate. Get over it man.


  84. Jeff Says:


    First of all I appreciate your reply to my … let say thoughts :)

    So I get were your going on this. I understand the want for investments from other companies to help with that ecosystem. It does present some good opportunities for the GPL.

  85. mark Says:


    The product cannot ever be “made unavailable”. Think about it:

    * you have access to the code you patched, under an open license
    * you (under the old Canonical CLA) also have a wide license to your patch

    Therefor, you, or anyone else, can at any time publish an open version of the code including your patch.

    It’s a myth, and FUD, when folk claim that contribution agreements might result in existing “free” code being withdrawn. That’s legally impossible; once a version of code is published under the GPL, say, it cannot be withdrawn. At least, that’s the current legal thinking, and Canonical has in cases fought to defend that principle, as have others.

    So what we are talking about is preserving the right of the owner to change their mind about FUTURE work they do, without having to rip out what was contributed while the product was open. We’re talking about encouraging companies to GPL their proprietary work, to see if the balance of contributions is worthwhile. If it turns out that it is not, and they decide to continue their work in private again, we still have what was published under the GPL *forever*, and of course can derive from it in the commons. On balance, I think that’s hugely valuable.


  86. mark Says:

    Dear Jef@FedoraProject

    Canonical has adopted a professionally drafted CLA, from Harmony. It uses clearer language and a different legal mechanism, just as the GPLv3 uses clearer language and a different legal mechanism (“conveyance” versus “distribution”, iirc) from the GPLv2. My argument is unchanged: volunteer contributors, who are a wonderful and extraordinary force for good in the FLOSS ecosystem, will have a more satisfying long term experience if their chosen projects WIN. It is much more satisfying to work on a project which is (a) available to your friends under the GPL, and (b) the clear winner on any terms. I think, in order to achieve those goals, we need to assess what we can do to encourage meaningful investment in all the components that make up the modern, free, GNU-style platform.

    I absolutely believe that a reasonable relationship between such parties would involve the donation of a casual patch. Since I came to this view I have been glad to sign any and all vaguely standard assignment agreements, and under my leadership Canonical did the same; and continues to do so, today. It is human nature to cling and obsess. Let go of it, Jef, and you’ll be a much happier person. That patch scratched my itch, accomplished my goal. Under Canonical’s CLA, at least, I could donate it and still retain enough rights to see it would be available on terms I liked. And good practice for the recipient, in my view, would be to ensure that every patch accepted is always published under an open license, at least once. I argued for that to be a feature of Harmony, I think unsuccessfully, but I argued for it. Nevertheless, most institutions will do that as a matter of course.

    Wide licensing is close enough to assignment that most lawyers, and pragmatists, say “meh, let’s move on”. And that’s Canonical’s position now.

    My own view is that what’s really necessary for a healthy relationship is clear-eyed mutual respect. I would be delighted to contribute a patch to Microsoft if it helped make free platforms work better on their stuff. I don’t like ’em, don’t trust ’em, and have no expectations that some other group at the company wasn’t busy preparing for Linux’s downfall. But mature engagement with complex counterparts requires that sort of separation of emotion and goal-driven decision.

    Ubuntu is a collaborative work between thousands of people, some of whom work for Canonical, most of whom do not. What I’m saying here is controversial, and I think it’s important that I speak clearly, completely and openly about these views, so that folk who want to participate in Ubuntu and Unity can decide if they share them or not. What I’m describing is a working relationship – the true meaning of collaboration – built on mutual respect and appreciation. To have mutual respect, you need to understand what each party’s principles and requirements are. That way, people can make clear decisions about where they will participate and where they will not. Also, you cannot have mutual respect if the view of contribution is one-sided. My opponents in this debate sanctify volunteer contribution as the ONLY good; in fact, it’s a distinctive property of openness, but it’s not on its own enough to win. In Ubuntu, I think we strive for balance: we make hard compromises in the company to be able to work with contributors, and we love it, and it’s reasonable to expect reciprocity.

    Participating in such a project can be MORE fun. There’s money to get stuff done, for a start. You get more travel to conferences, better quality releases, releases on time, publicity and widespread awareness of your efforts. We have many participants in Ubuntu and Unity who enjoy it. Who are you to tell them to feel otherwise?


  87. Garry Says:

    @Jef Spaleta
    “When the licensing is reciprocal and symmetric, when all participants have access to the code under the same conditions, you end up with a healthier external development community that can support multiple competing business interests as well as individual contributors.”

    I’m not sure the evidence supports your statement here. If that were true then why has more than twenty years of open-source development created so few successful companies and taken so little market share from proprietary products?

  88. Garry Says:

    Even Android, used in above comments as an example of a successful ‘open’ platform, doesn’t have good supporting evidence. Have a look at the this, from

    “According to research by Kantar WorldPanel Comtech, Android now accounts for 38% of the UK smartphone market, compared to 23% for Apple’s devices.

    “Stateside, Android is faring even better, holding a 54.7% share, while iOS has 27.2%.

    “Last month, Google revealed that 350,000 Android phones are being activated every day.

    “Yet sales of Android apps remain relatively poor.

    “IHS Screen Digest estimates that £1.1billion of revenue flowed through Apple’s App store last year.

    “Android Market managed just £62m. The figure was lower than both Blackberry App World (£100m) and Nokia’s Ovi store (£64m).

    “Research predicts massive improvements for Android by this time next year, but it is still expected to lag far behind iOS.”

    Mark is right. Open development can do better and should be looking at alternatives to do just that.


    >>In the open source community we make a very big deal about the rights of ownership? <>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.

    So why the confusion Mark? Are you giving it away in a truly altruistic fashion or are you just trying to tear down the MS grip on the OS World? Or (and I express great disappointment if this be true) perhaps just another variation of the old objective: looking for brownie points and a mention in the New Years Honours list?


    Greenman-23 (A modern day Sufi)


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

    Sorry but are you not beginning this post with a contradiction: an oxymoron. Is not the WHOLE POINT IN OPEN SOURCE the abdication of ownership?

    Perhaps as a ‘self appointed dictator’ you see ‘open source’ rather like a teacher sees children playing… as long as you behave and do with the ball what I have prescribed then I will leave you alone…

    Sadly Mark, and this is a hard lesson for men like you to learn but open source, being free with your work, your creation, your ideas means letting them go… you no longer own them and if I or anyone chose to use your ideas in a way you disapprove .. tough! more fool you for making them open source!

    Perhaps if Nobel had of patented dynamite we would not have the peace prize (though it be a total joke in todays climate) but I suspect we would still have War… so don’t fool your self into believing a) you can control and b) you can actually determine what is a good/bad application for another… that’s arrogance… particularly from the perspective of men like me.. We do not understand this obsession with the accumulation of wealth and power that the majority on this planet (you included) have……..

    we similarly hold the view that patents and copyright are what hold the progress of Humanity (Ubuntu) back … a view I would aver is more shared in the open source World than not..

    now responsibility… this is also an interesting concept, perhaps you are as responsible for mowing the lawn and painting the walls (really?) as I in my Universe am responsible for letting the grass grow and neglecting the pointing…. we each have a reason and both would claim it to be being responsible….

    whilst I won’t claim to know your reasoning mine is because I love the creation and I know that the long grass and the cracks in the walls will yeild colour and scent as well as become the homes and nurseries to the insects and mammals that are to me the reason to be alive…. but then my paradise is a very different place to yours……..

    So don’t be too quick to judge my methods less you truly know my objective!

    The more I read the more confusion I see!

    When a maintainer adds a patch to a work, they are also accepting responsibility for its maintenance

    no they are not!

    And then you give this example.. the trust fund concept of those that refuse to die!
    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.

    So why the confusion Mark? Are you giving it away in a truly altruistic fashion or are you just trying to tear down the MS grip on the OS World? Or (and I express great disappointment if this be true) perhaps just another variation of the old objective: looking for brownie points and a mention in the New Years Honours list?


    Greenman-23 (A modern day Sufi)

  91. StuartM Says:

    “IHS Screen Digest estimates that £1.1billion of revenue flowed through Apple’s App store last year.
    Android Market managed just £62m. The figure was lower than both Blackberry App World (£100m) and Nokia’s Ovi store (£64m).
    Research predicts massive improvements for Android by this time next year, but it is still expected to lag far behind iOS.”

    I wonder whether revenue is the best measure. In an open environment where many things are free, then financial return is not going to be maximised.

    I believe that Android users consume more data than Apple (although not by a vast margin).
    Although it is clear Apple do a (insert word of your choice) job of generating revenue from their data use.

    The initial race was to have more apps, but once you have 20 versions of Backgammon, why do you need more, also how do users judge which one to use?
    What is needed is a broad selection of good quality apps and content.
    This therefore requires some form of certification, or testing, or a gatekeeper. This means that what you see is now controlled by some process and not the community at large.

    As to what enables successful business ecosystems, it is open and agreed standards rather than open source software.

  92. dipesh Says:

    Thank you, Mark, for sharing your pov. I personally appreciate such a fresh view on our goal to spread FLOSS, open up proprietary code bases and bringing both worlds closer together.

    One problem I see and which wasn’t named yet is those of decision-making processes. How to bring a company that opens up it’s large code-base to a table so the community is able to do more then bugfixing? Think of refactoring problematic code which is hard to understand and maintain but works. The community would very likely replace that with something that can be understood without headache while “the large company” may used to the atomic pattern (build a nice API around and hope it doesn’t explode inside cause noone can fix it)? How to arrange a ground where innovation inside a code-monster is possible? I fear if we cannot solve that then any such code-base that was opened up once will be closed again rather soon cause those who code for fun do so to produce a good book of code while those who are used to sell padded envelopes for books will not care about the content?

  93. » Mark Shuttleworth: The responsibilities of ownership Says:

    […] […]

  94. Johnsie Says:

    How about committing more upstream instead of just milking the rest of the open source community?

  95. Jef Spaleta Says:

    “We have many participants in Ubuntu and Unity who enjoy it. Who are you to tell them to feel otherwise?”

    Mark, I’m not telling anyone to not enjoy what they are doing.

    But I definitely question your implication that you have _many_ people inside the Ubuntu community who think assigning ownership to Canonical was a good idea. I even question whether the assertion that most people prefer the broad CLA to an inbound==outbound. You undoubtedly have some but I would wager that there are more people in your community that would prefer not to assign copyrights. Is there a way to see who has signed the CLA via launchpad acount information so I can get a fair an accurate accounting?

    Again I would point the the Launchpad translation group and their use of the BSD license in the work they are doing as an example of preferred assignment avoidance and even preferred CLA avoidance. Where the FSF requires a CLA-like document for translations, the Ubuntu community has actually gone the extra step and is using an inbound=outbound license to lower the bar to contribution and to build their community without resorting to a CLA construct to make relicensing possible.

    Everyone still reading along needs to read:
    It’s very important to understand that the Ubuntu community has already shown by example that the stronger contributor communities are the ones which drop CLA paperwork entirely and rely entirely on picking a license that allows for relicensing if that is inside the scope of the work.

    The Ubuntu translation community is the strongest external _contributing_ community Ubuntu has, and what I am telling you is, the lack of a CLA is a big part of that.

    All of those people, every single one of them, are doing their work without assignment or even a CLA like structure. Are you going to tell them they shouldn’t prefer to do that work without a CLA or without an assignment to Canonical?

    And its really important to point out that previously, Canonical attempted to require joint copyright ownership for translations being submitted:
    And way back then, it was clear that Canonical ownership was unnecessary, and even problematic. The solution was moving to BSD, not entangling people in some CLA paperwork. If relicensing is something you expect, contributors can and will contribute under a license that makes that possible for everyone on equal access terms. The history of translation inside the Ubuntu community shows that its a workable way to drop the barrier to entry and to increase participation.


  96. Josh Says:

    @Mark – thank you for a thoughtful and calm reply to my agitated (and worried) posting. I think a big thing for those of us who contribute code for the love of it is 1) Not sounding like Balmer/Microsoft (which blog postings, Harmony breakdowns, and interviews leave you sometimes sounding like), and 2) Not appearing as though you want to consume my contributions while hanging me out to dry. I don’t believe you’re doing the latter, now. Thanks for your clarifications.

    @Johnsie – I certainly don’t speak for the entire FLOSS community, but I don’t care if Mark makes a dollar off of my code. I really, really don’t. What I (and I suspect most contributors) do _NOT_ want to see, having specifically chosen open source, is to see my contributions proprietized, or to see me hung out to dry for some obscure patent troll. If Mark can make money from my code, he’s not only legally entitled to according to RMS, but furthermore good for him from my personal viewpoint.

  97. candtalan Says:

    On the subject of ‘new’ business model, I have just seen an interesting TED video where high level views of development and survival of cities show apparently a fundamental difference from corporations, organisations, biological entities.
    A new business model may have an interesting position between, within, the different behaviours. For example, it is hard to destroy a city, while an organism is guaranteed to age, and die.

  98. Dave Neary Says:

    Hi Mark!

    Nice article and summary of your perspective.

    I agree with you that the authors of small patches should not be able to hold projects to ransom. I think it would be really useful to have better guidance as to what constitutes a sufficient patch to make a derivative work – the grey area around the meaning of “derivative work” is a big part of the problem, I think.

    I do not believe that most authors consider that a single patch gives them any say in the project – I may be wrong, of course, but I agree with you that to believe otherwise would be an unreasonable position.

    The problem is asking for a paper signature. A drive-by patch from someone scratching their itch should not have a lot of overhead involved, or it’s not worth it for either party. If I have to rewrite a 20 line patch and it’ll take me a couple of hours, I’m not going to do it. And if I have to print, read, sign & fax or mail a licensing agreement for the same patch, then I probably won’t do that either.

    In addition, sustained contribution, including sharing the maintenance burden of the project after contributing to it changes the nature of the relationship. In the case of Novell & Sun you allude to this. In that case, there was a major functional addition. I would argue that frequent and numerous small contributions would, over time, have the same impact. It’s impossible to identify the tipping point when a person goes from “contributor of small patches” to “significant contribution to the project”, but at some point a hacker will begin to feel ownership of his stuff and identify with the project. This is to be encouraged.

    As a whole, I think that we agree on the level of ownership that a contributor should expect to have in a project he contributes to. The devil is in the details. Clear guidelines on derivative works would help, and the SFLC could help provide some guidance in that area, I think.


  99. Bob Good Says:

    Hello Mark,
    I hope you read this, Mark, and my comments are not related to the topic, so sorry about that.

    Mark, I’d like to ask you to consider extending support for Lucid until 2015 instead of 2013. A lot of people are having trouble cottoning up to the new Unity desktop environment, myself included. A lot of formally loyal Ubuntu users are jumping ship and are actively seeking out an alternative. I hate to see to see this happening but it is happening. If you extended Lucid’s support life then surely many will stick with Ubuntu giving Canonical a chance to develop a more popular solution. As we’ll both agree, Lucid is a great, if not the greatest, Ubuntu release.

    BTW, I’ve been a loyal Ubuntu user ever since I got DSL back in 2005 (Warty) :).

    Thanks for your time.

    Bob Good

  100. Benjamin Kerensa Says:

    Nice entry Mark…. I think you made some good points although a lot of good points were also made in comments and perhaps you might address some in the future.

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

  102. 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?

  103. 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?

  104. 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)

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

  106. 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?

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

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

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

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

  110. 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 […]

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

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

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

  113. salemboot Says:

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

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

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

  116. Emiliano Says:

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


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

    […] (source) […]

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

  119. 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 […]