Meeks: Some thoughts on copyright assignment

[Posted December 22, 2009 by corbet]

Michael Meeks's posting on copyright assignment is not a quick read, but it's worth the effort; this is a more thorough look at the issue than your editor has seen elsewhere. "I am not aware of a single project that mandates copyright assignment to a corporation that has a diverse, and thriving developer community. If there was even one, the business model of 'communitising' a code-base, then firing all your developers, sitting back, and collecting an effort-free rent might become attractive. In contrast I am aware of many diverse and thriving communities that have eclectic ownership, and also some less thriving ones that are dominated by single entities."

The result isn't quite what he thinks it is

Posted Dec 22, 2009 2:28 UTC (Tue) by BrucePerens (guest, #2510) [Link] (9 responses)

The big counter-example is MySQL. MySQL built a billion-dollar company to which Open Source was essential, but community development was avoided. They hired the good people.

Of the two companies we can prove made a profit with Open Source, one didn't use community development. Could this mean that community development isn't even a good idea if you're out to make money?

Of course, most Open Source projects are not out to make money, and for them community development is essential. We don't particularly need companies to do Open Source. But maybe it turns out that they don't need us either.

Obviously, if it's got Open Source licensing, it's Open Source. Community development is an option that is always available to the community, who are never without the ability to fork the product if that is what is necessary to get it.

Some folks theorize "fauxpen source", saying that Open Source without community is really fake. 1) it's a stupid name and 2) it's expanding the definition of Open Source by several more parameters than today: #11 there must be independent copyright holders and #12 there must be a low barrier to entry for developers. Those are always nice but not strictly necessary.

Bruce

The result isn't quite what he thinks it is

Posted Dec 22, 2009 4:55 UTC (Tue) by iabervon (subscriber, #722) [Link] (5 responses)

I'm sure there are plenty of examples of companies that made successful software products without community involvement (including, for example, Microsoft). It would be reasonable to guess that this is not incompatible with that software being open source. Releasing the source under an open source license is not so big an impediment to sales in many areas that free labor is needed to make the total viable.

On the other hand, I think community involvement is important to making open source actually matter. Sure, licensing can make sure that you are able to make changes, and that you are permitted to make changes, but what's the big deal if you (and people like you but more interested in this particular software) never actually do make changes? Without community involvement, there is still the fact that the software doesn't cost any money, that it can be procured without a business transaction, that there's less potential liability for users, and that there's essentially automatic source escrow in case the owner falls apart. But I think the ideological basis for open source software is that, as technically competent and interested users use it, they generate improvements for their own benefit and share them, advancing the state of the art; and this pretty much implied community involvement.

The result isn't quite what he thinks it is

Posted Dec 22, 2009 7:44 UTC (Tue) by jmm82 (guest, #59425) [Link] (4 responses)

I find most programmers love to write new code, but hate matanaince and
documentation. Some would argue the documentation is not needed in
open source but that only holds up if every user is a programmer. Normal
users do not want to search 5 years of forums or ten thousand lines of c to
learn a piece of software.

Most good open source projects pick up external funding to productize the
project or a disto assigns one person to five projects and the project is
maintained just enough to get dragged through the mud. Or the person
who wrote the project enters the real world and gets a job programming
and after a year or two of programming 40 for work and 40 for
free, calls it quits.

We may not need companies but everyone needs money to live. Let's face
it if you are not getting paid, it gets tiring once the "Honeymoon" is over.

The result isn't quite what he thinks it is

Posted Dec 22, 2009 16:38 UTC (Tue) by iabervon (subscriber, #722) [Link] (3 responses)

Most programmers hate to write documentation, but if not all users are programmers, it stands to reason that there are users who like writing documentation. In fact, my experience is that interested users who aren't programmers tend to generate a lot of explanations for confused new users, and these users are eager to write documentation to avoid having the same questions to answer all the time. Of course, getting good documentation out of this process requires having a process in place for getting documentation from contributors into the project state, getting it organized in some usable way, and then into the hands of new users. It also depends on the documentation source being in a form that people who like to write about programs like to write. Furthermore, someone with an interest in process management and document organization has to work out a procedure for keeping the documentation organized as the project grows and more documents arrive. Random factoid: in the git project history, of the 19785 commits leading up to v1.6.5, 4086 of them (20.6%) touch the "Documentation" subdirectory, and 3096 of them (15.6%) touch the "t" (tests) subdirectory. As far as I know, there's nobody who has writing documentation for inclusion in the git project as a specific job duty.

Programmers don't like to do maintenance, but they also don't like to work on badly maintained code. Stuff gets cleaned up when it's more trouble to work on interesting stuff despite it than to clean it up. This is probably better than most of the commercially driven world, where clean up is only generally supported when the messiness is actually problematic, not just annoying.

The result isn't quite what he thinks it is

Posted Dec 23, 2009 0:05 UTC (Wed) by jmm82 (guest, #59425) [Link] (2 responses)

Last time I checked about 75% of code contributions to Linux kernel were by people being paid. So regardless of if they are paid to "write documents" they are paid to see that the project does well.

Also, the Documentation dir in the Linux kernel is much better then it used to be, but it is not sufficient to understand the kernel.

From my personal experience learning the kernel I have found a lot of the tutorials Greg KH has written helpful(along with a few other people like Rusty Russell), yet documentation is still the exception rather than the rule and that is sort of realistic for the pace that the kernel moves. Also, most documentation is out of date, but that is fine it is usually enough to dive into the code.

The Linux kernel is obviously an example of how every project should turn out, but it is mostly funded programmers. The kernel is so complex and the politics are so great that it is relatively impossible for an unpaid community member to contribute significant code to the kernel. I am not saying it doesn't happen, but it seems to be getting harder and harder to "catch up" enough to write good kernel code without doing it full-time. That does not mean unpaid community members do not contribute in others ways, but the paid programmers are the foundation that keeps the kernel in shape.

While I believe external funds are necessary to create a good open source project. I also believe that companies can fund projects without hijacking all contributions. Your example the Linux kernel being proof.

I really enjoyed the article by the way. I forgot to mention that in my last post.

The result isn't quite what he thinks it is

Posted Dec 23, 2009 3:18 UTC (Wed) by iabervon (subscriber, #722) [Link] (1 responses)

That's all true of the linux kernel project, but I was talking about git. The kernel has quite a few more commits than that, and a much smaller portion touch the Documentation directory (which makes sense, because the documentation that people mostly need is in the separate "man-pages" project, not the kernel's Documentation directory. (Also, the kernel never had a version 1.6.5.)

As far as I know, the people paid to work on git are: Junio, whose employer lets him work a day a week on it; Shawn, who works on git-related projects in his "random useful stuff" time as a Google employee; and presumably the scattering of people who work for git hosting companies and also make some changes to the project. There are probably a number of others who have convinced their employers to use git and therefore can fix bugs and contribute patches if their site runs into the problem.

I think that, to the extent that there's corporate sponsorship of git development, it's either essentially an employee benefit or is corporations acting as technically competent end users and scratching their itches, which is somewhat of a different situation from the relationship between Linux and corporations.

The result isn't quite what he thinks it is

Posted Dec 23, 2009 4:26 UTC (Wed) by jmm82 (guest, #59425) [Link]

My apologies I heard git and I immediately thought Linux kernel.

Git is a great example of the type of project which thrives in open
source.
1. It is a utility made *for* programmers.
2. It does not often have a direct connection to the Companies final
product(obviously it improves general quality, but it not really sold to
customers by the companies using it)
3. Everyone needs it, but no one really wants to pay for it.
4. It helps get a community when Linus started the project.
5. It is used by the Linux kernel so any company that uses the Linux
kernel uses it at least to review commit logs and most likely to sync
code.

My current favorite Open Source project is the Chromium browser. It is a
pleasure to use and rather painless considering its age. Obviously,
funded by Google and released under a dual license a GPL?(it is unclear
exacly the open source license) and propriety commercial Google
License(renamed Chrome) which I do not know off the top
of my head. Therefore, the open source community can work on Chromium
project and Google can make money of their Chrome browser. Obviously,
they also plan to have it be the "Only application" on their new
OS.(Though they will also be running some services over a DBUS
interface.)

The result isn't quite what he thinks it is

Posted Dec 22, 2009 9:20 UTC (Tue) by AlexHudson (guest, #41828) [Link]

Michael's article isn't about making money, and your counter-example isn't - if it doesn't have a thriving developer community, which you admit, then it's not a counter-example in the context of his article.

Having a wildly successful project/product is not the same as having a thriving developer community, but I know which I would value more highly.

The result isn't quite what he thinks it is

Posted Dec 22, 2009 11:04 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

>Of the two companies we can prove made a profit with Open Source, one didn't use community
> development. Could this mean that community development isn't even a good idea if you're out
> to make money?
Too strong a development community might actually be a threat to some open source business
models.

Threats and efficiencies

Posted Dec 22, 2009 11:09 UTC (Tue) by sladen (guest, #27402) [Link]

"Threat" has negative connotations; what's actually happening is the optimisation and evolution of a development process—in the long run it is better for the general good.

The 'Delay' Argument

Posted Dec 22, 2009 13:08 UTC (Tue) by kripkenstein (guest, #43281) [Link]

First, I have to say that that was an excellent article.

Second, I just have one issue with a specific argument: That by requiring copyright assignment, you add a 'delay' between submitting your code and having it accepted (since you need to sign forms, get them approved on both sides, etc.), and that that delay removes the fun and motivation from contributing.

There is no denying that there is a delay. However, both from his actual anecdotes, and my own experience, I am not sure about how correct the argument is. For one thing, no serious project just commits patches from contributors just like that, they go through a review process (a technical review, not one about copyrights or legalities). And actually that review tends to be *long* in big, 'serious', corporate-funded projects. Those are often the same projects that have copyright assignment of some form. So there is a correlation here that may be misleading. In particular because the technical review process is often more than long enough by itself to kill the fun he mentions of submitting a patch and seeing it quickly committed.

That said, I am not a fan of mandatory copyright assignment. For my own projects I prefer to let people either assign copyright, *or* submit it under a permissive (BSD, Apache, etc.) license, their choice.