Safe as Milk

Side-effects of copyright assignment

December 23, 2009 3:11 pm Dave Neary community, freesoftware, General

Michael Meeks wrote a great piece on the consequences of copyright assignment on free software projects yesterday. He has a lot of experience in the area, and has gone from fervent advocate to something of an outspoken opponent of copyright assignment through his involvement in the OpenOffice.org project in recent years.

One of the things that Michael said in his book is that commercial agreements with partners (resellers and redistributors), made possible by copyright assignment or sharing, can work against the core principles of free software. He cites some examples, but there are many ways that companies use their dominant position within the project:

• Vendor X agrees to commercially license their software, on condition that any changes that the licensee makes to the software in the future be submitted only to the vendor. By removing the right to redistribute changes from the licensee, the vendor prevents the licensee from participating in any forks of the project. SugarCRM’s EULA contains a no-forking clause, for example. Ironically, it also contains a “standard” non-reverse-engineering clause, so you may look at the source code before buying the enterprise version to see how it works, but once you are an enterprise customer, that’s off the table.
• A vendor ties an official partner programme, support and commercial licensing together. Matt Asay has described the Alfresco parner programme, which contains these restrictions. If you want to be an official Alfresco reseller, you must agree to sell only commercially licensed Alfresco, and you must get the client to commit to a subscription before starting the support contract. You are free not to be an official Alfresco reseller, but in this case, you may not resell commercial licenses for Alfresco, or distribute any commercial add-ons.
• No compete clauses can require commercial licensees not only not to contribute to any fork of the vendor’s product, but also to any competitor of the product. While BitKeeper was not a free software product, its licensing agreement contains many of the worst excesses you can find in vendor licenses, to the point where employees of clients were asked to stop working (in their free time) on free software competition.
• Proprietary licenses can change under your feet. There are often clauses that allow a vendor to update the licensing agreement at will, and apply it retro-actively to existing clients. BitKeeper did this.
• Non-disclosure rules can prevent you from publishing performance tests, for example, as in Alfresco’s trial license. Or even disclosing the terms of your agreement, as Michael suggested, meaning that you can’t even tell people what you may and may not do in the context of the proprietary agreement.

Proprietary software agreements are simply contracts between the vendor and the user, which set out the terms by which both parties agree that the user may use the vendor’s software, and gets some value off the vendor.

Contracts are a part of life. When I rent an office, I have obligations, and so does the landlord. I’m a grown-up and I can agree to whatever I want, if I’m also getting what I need from the deal. But contracts also have victims. As a community member, if you (as a user) sign a contract that says you may not participate in the community, you’re hurting the rest of the community. And if you (as a vendor) force your clients not to participate in the community, or to do so on different terms to everyone else, they you’re hurting the community too.

Since you can only do so much to hurt a community before you don’t have one, this is why I consider copyright assignment a key barrier to entry to community building. And in a vicious circle, because there is little broad community activity around most single-vendor free software projects, those vendors feel vindicated by their copyright assignment decisions, and have little reason to invest heavily in community building – since doing so gives a very low return on investment.

It is possible to build certain types of communities, even with copyright assignment – through a modular architecture which allows anyone to build plug-ins or add-ons, for example, OpenBravo has built a large community of module developers, but has seen little contribution in the core product. And perhaps building a broad and deep group of core contributors is not important to your business model or investors as a company – and that’s fine. The only point I’m making is that you can’t have your cake and eat it. It’s a balancing act between building community and maintaining control.