[dmd-internals] DMD copyright assignment

[David Nadlinger via dmd-internals]

On 24 Jun 2014, at 0:01, Walter Bright via dmd-internals wrote:
> I'd like to know that, too. What is the difficulty with copyright 
> assignment? I can't address that if I don't know what bothers you and 
> David about it.

[Note: I'm not dealing with non-copyright-assignment CLAs here, that's a 
separate discussion.]

It boils down to a simple cost-benefit analysis.

Copyright assignment is often discussed in the context of open source 
projects which are distributed under a copyleft license and backed by a 
single corporation. In this setting, my personal opinion is that it is 
an issue on which reasonable people can disagree. However, most of the 
arguments for copyright assignment do not apply to our situation, while 
virtually all of its downsides still do, making it a pretty obvious 
choice.

Let's quickly have a look at why you might want to require copyright 
assignment as a company who initiated an open source project.

    A.1) There are claims that it is necessary to be able to efficiently 
combat license violations in court, as only the copyright holder is able 
to do so. [1]

    A.2) It allows you to monetize software by offering a 
copyleft-licensed version for free and selling commercial licenses 
without those restrictions.

    A.3) It allows you experiment with open source development, while 
keeping the option to later commercialize the product. In particular, 
this might be important for startups later being bought by a company 
that does not do open source development.

    A.4) If the need arises to change the license in order to meet the 
stated project goals (e.g. because of legal flaws discovered in the 
license), this is easy to do.

Now, let's see how they apply to our situation. 1) is moot, as we want D 
to be in a public-domain-like status, and pretty much the only violation 
of the Boost license possible is to remove the copyright statements 
anyway. 2) and 3) are similarly irrelevant, as such intentions would be 
compatible with the terms of the Boost license in any case.

So we are left with 4). If you want to have a serious discussion about 
the issue (which I think you really want to in order to get the 
community behind you) instead of just deciding that copyright assignment 
is a good idea because it gives you the warm fuzzies, you either need to 
agree that this is a very improbable thing to happen – and note that I 
am not claiming that is entirely impossible in order to reach my 
conclusion below –, or provide good evidence why this is not the case.

As for why I think that it is unlikely to happen: We all agree that our 
goal for D is to be used as widely as possible, commercially or not, and 
we use pretty much the most liberal license possible. So, there are only 
two scenarios left to consider:

    A.4) a) Some big, rouge company decides to use the frontend source 
code to build their own, incompatible system and aggressively markets it 
to the harm of D. They are allowed to do this under the Boost license. 
We thus decide that the whole liberal licensing thing was a mistake and 
want to change DMD back to a copyleft license like GPL, so that they at 
least do not benefit from our future work on D. This arguably is a 
rather unrealistic scenario, but even then, we would not need to 
re-license the code. Instead, we could just begin applying that more 
restrictive license from that point on and continue to use the old code 
under the terms of the Boost license.

    A.4) b) Somebody discovers that the Boost license actually carries 
some restrictions that nobody thought of before, meaning that it is in 
fact not the near-perfect emulation of "do anything you want, as long as 
you retain the copyright notices" we want it to be.

So, with 4) b), we have identified a single situation where it would be 
beneficial to have a single copyright owner for the project. In order to 
make an informed decision, we need to weigh this possible advantage 
against the costs and risks of requiring copyright assignment. The first 
step towards that is to try and estimate how likely it is that such a 
situation will arise. To make a weighty argument for copyright 
assignment, this scenario should also have a big negative impact on our 
goal to make D a widely used language.

As I said above, I think such a scenario is very unlikely. If you want 
to get me to agree that requiring copyright assignment for DMD is a 
useful thing to do, you'll have to convince me otherwise. Here is why I 
don't think you have much of a chance to do so:

    B.1) The Boost license has not only been written by a team of 
experts at Harvard Law School, but is also built on the experience with 
a several other widely used liberal licenses. To the best of my 
knowledge, no issues requiring such a license change have been found 
with any of them.

    B.2) You mentioned GPLv2/GPLv3 and the BSD license earlier. I don't 
think that these are not relevant for the sake of this discussion. As 
far as GPL goes, the motivation for the update was mainly to introduce a 
few new restrictions with regards to DRM and Tivoization that were not 
consistent with some other parts of the (complex!) version 2. Quoting 
Richard Stallmann, "it is important to note that upgrading is a choice. 
GPL version 2 will remain a valid license, and no disaster will happen 
if some programs remain under GPLv2 while others advance to GPLv3." And 
in the case of the BSD license, what was changed was to remove an 
additional restriction (advertising clause) from the original text. I 
think you would find it hard to argue that the Boost license, in its 
minimalism, might contain a similar restriction which we could want to 
remove later.

    B.3) The Boost license is very simple, compared to monsters like the 
GPL or even the old 4-clause BSD license. One possible problem would be 
that it is discovered that "to use, reproduce, display, distribute, 
execute, and transmit the Software, and to prepare derivative works of 
the Software, and to permit third-parties to whom the Software is 
furnished to do so" somehow does not appropriately reflect the rights we 
want to give our users. I don't think there is a valid reason to believe 
that this is any more likely than, for example, the copyright system 
itself changing in such a way that copyright assignment doesn't work out 
as intended. I'll be pleasantly surprised if you provide me with any 
evidence to the contrary.

    Much more likely, if still unlikely, is that an issue is found with 
the "unless such copies or derivative works are solely in the form of 
machine-executable object code generated by a source language processor" 
part of the license. However, even if this clause turned out to somehow 
not apply to an important use case of druntime/Phobos, this would only 
mean that the copyright statement would have to be distributed alongside 
the program. I think you will find it hard to argue that this is a 
serious problem for the future of D to the point where your earlier 
"kill switch"/"enormous bet"/"holding hostage" analogies are more than 
just empty rhetoric. After all, many widely used libraries require some 
kind of attribution. For example, I don't think there would be many 
people more unwilling to acknowledge third-party code than a company 
like Microsoft in their flagship product, yet they are happily 
attributing Andrei for his work on Loki in Windows. And remember, we are 
still talking about the worst thing that could happen in a very 
hypothetical scenario here.

I hope that at this point we (and especially Andrei) can agree that the 
only argument left in favor of copyright assignment is a diffuse fear of 
some legal quirk being uncovered in the future, hoping that aggregating 
copyright would protect us against it.

Now, as I said above, while I think that such a situation is rather 
hypothetical, I acknowledge that there is indeed a tiny chance that it 
will occur in the future. However, there is a number of very much 
non-hypothetical downsides to requiring copyright assignment, right now. 
Let me try to summarize some of them:

    C.1) It adds an extra barrier for new contributors to join. This is 
a fact, regardless of whether it is worth it or not. The fact that the 
FSF makes this step extra cumbersome by requiring a physical form to be 
sent (faxed?) in does not exactly help here either.

    C.2) In some jurisdictions (mostly european, e.g. Germany, Austria) 
it is not even possible to give away your copyright, requiring the 
agreement to be full of scary-looking legalese to provide a fall-back.

    C.3) Because of A.2) and A.3), many open source developers have a 
pre-existing notion of copyright assignment being unfair towards the 
contributors, regardless of whether it applies to our situation or not. 
The behavior of Oracle after acquiring Sun generated quite a bit of bad 
press recently.

    C.4) Contrary to what you suggest by bringing up Tango over and over 
again, requiring copyright assignment makes it _harder_ to incorporate 
external code. For example, assume that there is a nice piece of code in 
Boost (the library) that we'd like to adapt for D, e.g. some code from 
Boost.Context that would be useful for implementing fibers when porting 
druntime to a new platform. Even though the licenses are perfectly 
compatible, we can't use that piece of code, unless we manage to 
convince the original author to assign copyright to us. Your Tango 
example would only be a valid argument if we assume that all interesting 
code ever written would be assigned to Digital Mars, but I think we can 
safely agree that this is megalomania.

    C.5) Requiring copyright assignment will make it entirely impossible 
for some people to contribute, as it can be impossible to get the legal 
departments of your employer to agree. I happen to know two people in 
quant finance where they could contribute to open source projects, but 
were forbidden to sign even Contributor Licensing Agreements that don't 
require copyright assignments, like those from Google or Mozilla. There 
was a post on reddit a while back where a startup founder had signed a 
Google CLA and that generated quite a bit of legal hassles when their 
company was bought, regardless of how irrelevant that was, simply 
because it raised a red flag with the acquiring company's legal team. Or 
see this statement by a well known Linux kernel developer who claims 
that he wouldn't have been able to contribute to Gentoo if it required 
copyright assignment: 
http://article.gmane.org/gmane.linux.gentoo.devel/82061

    C.6) You wrote earlier that "the credit has a lot of value to one's 
professional career", and I couldn't agree more. Yet at the same time, 
you are asking people for the permission to take it away from them. 
Regardless of whether you actually intend to do that or not, the simple 
possibility makes this a rude thing to do without a good reason.

You might dismiss some of these points as irrelevant, and you might even 
convince me that they are. But you can't dispute the fact that copyright 
assignment is a contentious issue (see e.g. [2]-[5]) and will turn users 
and developers away before you even have a chance at trying to convince 
them too.

For one, I certainly wouldn't have started to contribute to D if it had 
required assigning my copyright to a random commercial company. Of 
course, I have been around for a while now and having met you in person 
I do believe you that you indeed act in good faith. Still, I don't think 
there is a good reason to require copyright assignment and I don't see 
myself handing over the copyright for my druntime/Phobos contributions 
or future work on DMD any time soon.

Let me reiterate: You are insisting on doing something that most open 
source projects don't require, including a number of successful, 
company-backed ones. One of them is LLVM, and while Apple's legal 
department is known to be extremely careful, they seem to have no 
problem with betting a lot of money on that. Our code is Boost-licensed, 
and in similar fashion the lawyers of Adobe and a number of other 
companies are willing to bet some serious money on the fact that it 
holds. Requiring copyright assignment is certainly not the norm, and 
recently, a number of companies with a less altruistic agenda than the 
current-day Digital Mars have ditched their CLAs that didn't even 
require copyright assignment because they still found it to be an 
unnecessary stumbling block for new contributors (see e.g. [6|, [7]). 
Yet, you are expecting us to agree to a proposition where we can only be 
certain about two things: That we are not gaining any rights in the 
process, and that it is going to turn users and contributors away in the 
future.

What you are doing right now is akin to being afraid of the possibility 
that you might have developed cancer, and asking a doctor for radiation 
treatments and chemotherapy in response to your unsubstantiated fears. 
Sure, there is a non-zero possibility that you indeed have a tumor and 
it will save your life. But clearly, anybody acting in that fashion 
would be insane because they'd completely ignore the very real chance 
that they might die from the side-effects of the treatment.

There are many other issues that threaten D's future in much more 
serious ways than some hypothetical nondescript legal issues down the 
road because we didn't require copyright assignment. One of them is 
patent-encumbered code entering DMD, an issue where copyright assignment 
doesn't help you at all.

And yes, even the likelihood of D getting forked over the discussion we 
are having now is orders of magnitude larger than what you are trying to 
prevent.

David



[1] There seems to be dispute about whether this is actually true, and 
indeed there have been suits regarding Linux and Busybox, both of which 
don't require assignment.
[2] https://people.gnome.org/~michael/blog/copyright-assignment.html
[3] http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html
[4] 
http://www.chesnok.com/daily/2010/10/08/the-problems-with-copyright-re-assignment/
[5] http://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
[6] http://www.joyent.com/blog/broadening-node-js-contributions
[7] https://twitter.com/richardfontana/status/477320000881975296