Copyright assignment

[mjg59]

The fundamental problem with projects requiring copyright assignment is that there's an economic cost involved in me letting a competitor sell a closed version of my code without letting me sell a closed version of their code. If this cost is perceived as larger than the cost of maintaining my code outside the upstream tree, it's cheaper for me to fork than it is to sign over my rights. So if I have my own engineering resources, what rational benefit is there to me assigning my copyright?

Comments

Depends on your focus

[http://gould.cx/ted/]

Your engineering resources are working on something entirely different and you don't want to waste your time on maintaining the fork. So it's then cheaper for you to contribute the small fix in your platform and move on.

[stewart [launchpad.net]]

A contributing factor/problem is that for contributors working for most non-small companies this means talking to a lawyer. This greatly increases the amount of effort you have to go through to contribute a relatively small amount of code, thus making forking it yourself even more attractive.

I've also had company lawyers balk at signing the exact same contributor agreement that the company asks people to sign but with s/our company/other company/.

Copyright Assignment in Germany?

[(Anonymous)]

I always wonder how Copyright Assignment legally works in countries like Germany, that don't have the concept of copyright like the US does. In Germany, according to the "Urheberrecht", the ownership of the work is bound to the author and cannot be re-assigned. After all, he is the author...

So no matter what piece of paper he signs, legally nothing can take away the author's ownership of the IP, so while he can assign usage right to third parties, he will always retain his own rights to the things he wrote, including the right to relicense.

Or so is my understanding, at least.

[(Anonymous)]

And your fork has the advantage that it can take code from the upstream tree (as per licence) but the upstream tree can't take your code without dropping their copyright assignment requirement (or maintaining a seperate "copyright pure" fork for their closed releases).

If there are significant engineering resources outside upstream then that leaves upstream at a disadvantage and at risk of not being considered upstream any more.

Copyright assignment only makes sense for either side when those requiring it are (and will be) doing the vast majority of the work.

There may be other considerations (such as ease of relicencing to a different open license rather than releaseing a closed version) that make copyright assignment attractive in some cases but some licenses accomodate for that fairly well in themselves.

Nice case. Even stronger…

[mirsolutions.de]

… is the initial effort people have to go to. As an integrator, for example when working on BSD ports, or doing “mass” work on Debian packages, or one-off work on a package that doesn’t generally interest me, it’s always the same for me (and others): if I have to register an account at a bugtracker, or subscribe to a mailing list, or similar, in order to submit a fix, it’s too much effort, and the fix will be kept local, unless upstream takes it on their own time. (If I had a way to notify upstream, I’d use it. Or, I use it and upstream doesn’t respond.) A copyright assignment is just so much more trouble. I admit I have it standing with the FSF, but I’m very unlikely to do it with another organisation, no matter how good they present their case.

The point may be moot ...

[david.dasz.at]

... if the assignment is to a community instead of a company. No? e.g. if the assignment is conditional on a free-only relicensing policy, it would defuse your argument.

Assumptions...

[https://profiles.google.com/askutt]

Your premise isn't ipso facto true: they may only sell the closed source version to markets you don't have access to, or in markets in which you cannot compete. Few companies have the engineering resources to compete with Apple or Microsoft, if their intent is to put your software in OS X or Windows. Even when that's not the case, you may not actually be giving them an competitive advantage. For example, I don't develop print servers, so giving away copyright on patch to a print server really doesn't impact my business any. For lots of people, this is the case: the entire reason I downloaded your project in the first place is it does something I (my employer) cannot be bothered with.

Though yes, if you're in "competition" with upstream and have the resources to make a fork palatable, the value of assignment is minimal. You're left with externalities, like the political fallout of a fork.

website

[(Anonymous)]

distributed version control should make it very cheap to maintain a fork.

it would be great if there were a good hosting site (like sourceforge) specifically designed for keeping forks. maybe with support for auto pulling upstream, adding the patches, and making packages.

then anyone could make their own 'go-oo' type project.

at some point the company who wanted the copyright assignment would be so tempted by all the lovely patches in the fork, that they would have to drop the requirement.

[reddragdiva]

I see what you mean (and wonder what in particular triggered it), but is it different assigning copyright for GNU contributions to the FSF than, say, OOo contributions to Sun was?