Lack of developers delays OpenOffice.org (ComputerWorld) [LWN.net]

Lack of developers delays OpenOffice.org (ComputerWorld)

Posted Apr 20, 2005 3:23 UTC (Wed) by newren (subscriber, #5160)
In reply to: Lack of developers delays OpenOffice.org (ComputerWorld) by flewellyn
Parent article: Lack of developers delays OpenOffice.org (ComputerWorld)

The license under which code that has already been written is not what is relevant to the current discussion. The discussion is about requirements placed on contributions to the product. OpenOffice and AbiWord are both available under the GPL (http://www.openoffice.org/license.html, http://www.abisource.com/), but have different requirements on how they accept contributions. Of course, under the GPL, you are free to fork either project. But if you want a patch you have written incorporated into their work, the process is different. AbiWord requires less work--basically just send in your patch and describe it to see if the other developers think it is useful (http://www.abisource.com/developers/). With OpenOffice, you need to submit a copyright assignment form (making your contribution the property of Sun) in addition to getting the patch approved (http://www.openoffice.org/license.html). OpenOffice is not unique in this regard; gcc also wants copyright assignment to the FSF (http://gcc.gnu.org/contribute.html#legal) though they say that a "disclaimer" is sufficient, Evolution requires copyright assignment to Novell (http://forge.novell.com/modules/xoopsfaq/?cat_id=30%23q60...), and there are other examples as well...

The requirement of copyright assignment has various advantages and disadvantages. It makes it much easier legally to defend the software if copyrights are held by a single owner in case anyone tries to use the code without authorization (e.g. putting the code into some proprietary product; see, for example, http://forge.novell.com/modules/xoopsfaq/?cat_id=30%23q60..., http://www.gnu.org/prep/maintain/maintain.html#Copyright-...). But, it also discourages some contributors who don't like the hassle of paperwork or don't like the idea of giving up ownership of what they have worked to create (http://www.xemacs.org/Architecting-XEmacs/xemacs-tour.html, http://mail.gnome.org/archives/foundation-list/2004-Augus...).

It's a mixed bag, you'll have to come to your own conclusions about it.

(Log in to post comments)

Incorrect

Posted Apr 20, 2005 3:58 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

The FSF requires actual assignment in addition to a disclaimer from the employer. The reason is not just so that the FSF can enforce the copyright in court, it is also so that the FSF itself does not get sued later by some employer who claims that their employee had no right to contribute code and that the company owns the code (most working programmers in the US sign employment agreements that assign the copyright to all code they produce to their employer, some even claim that the employer owns every idea the employee comes up with that vaguely relates to the job).

Incorrect

Posted Apr 20, 2005 4:37 UTC (Wed) by newren (subscriber, #5160) [Link]

If I was incorrect, then the gcc site which explains how to contribute to gcc (http://gcc.gnu.org/contribute.html#legal)--and which I linked to to back up what I said--is wrong. That URL states that "If a contributor is reluctant to sign a copyright assignment for a large change, a disclaimer is acceptable as well. However, a copyright assignment is more convenient if a contributor plans to make several separate contributions."

However, digging further, it turns out that what you claim does match what is said at http://www.gnu.org/prep/maintain/maintain.html#Copyright-..., which states that "Before incorporating significant changes, make sure that the person who wrote the changes has signed copyright papers and that the Free Software Foundation has received and signed them. We may also need a disclaimer from the person's employer."

So, it looks like the general gnu maintainer guidelines conflict with the information on the gcc site.... odd.

Incorrect

Posted Apr 20, 2005 14:43 UTC (Wed) by jamesh (subscriber, #1159) [Link]

The copyright disclaimer form does provide similar legal protection to the FSF as a copyright assignment form. The main difference is that code covered by a disclaimer is essentially public domain, so the FSF can't bring a GPL violation case with respect to that code.

Incorrect -- again

Posted Apr 21, 2005 0:53 UTC (Thu) by Ross (subscriber, #4065) [Link]

You misunderstand. There are two types of copyright disclaimers being
discussed. One is disclaiming copyright interest by directly putting a work
into the public domain. The other is getting a sign-off from employers and
schools that they do not claim ownership of a contribution by one of their
employees or students. This does not mean the employee or student wishes to
place the work in the public domain. It simply means that if they assign the
copyright to the FSF that it would be a legitimate act and that the employer
or school can't come along later and say they are the "real" owner and didn't
consent to the copyright assignment.

Forking instead of patch submission

Posted Apr 20, 2005 15:24 UTC (Wed) by JLCdjinn (guest, #1905) [Link]

Thank you for that analysis; it helped me to understand the situation better. I have a follow-up question.

Let's consider one of the projects that requires copyright assignment in some form, but which is licensed under the GPL. What happens if you fork this project and then later the original project wants to merge some of your work (each action being allowed by the terms of the GPL, as far as I understand)? Does such a project refuse to cherry-pick from good forks because of a lack of copyright assignment? If they do take code from your fork, is it true that you (the creator of the fork) still hold the copyright to any modifications in the fork? If so, doesn't this circumvent the patch submitting rules?

Forking instead of patch submission

Posted Apr 20, 2005 15:57 UTC (Wed) by newren (subscriber, #5160) [Link]

Patch submission rules aren't legal requirements; they're practice that a project has decided upon. They can decide to change their practices. It's just that they need to weigh the consequences--if they take patches without a copyright assignment then they are no longer the sole copyright owners and thus legal cases to defend against copyright infringement of the code becomes more difficult.

In fact, there's a real world example of the exact situation you propose--emacs and xemacs. According to http://www.xemacs.org/About/XEmacsVsGNUemacs.html, RMS has stated, "we can't use XEmacs in the GNU system: using it would mean paying a price in terms of our ability to enforce the GPL....There is good code in XEmacs, which I'd be happy to have in a merged Emacs any day. But I cannot copy it out of XEmacs myself because of the uncertain authorship and/or lack of legal papers."