Re: Copyright notice for demo source headers

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Mon Mar 08 2004 - 15:15:37 CST

On Monday, March 8, 2004, at 03:44 PM, Douglas W. Jones wrote:
> have doubts that it should be allowed to happen, because software
> that's developed as an exploration of what could be done is
> almost always worth discarding after you find what you ought
> to have done.

There's obviously a point to the "throw out the first one" approach. I
find--in my "real world" development experience--the first one gets
thrown out more often in slogans than in practice. But part of that is
bad inertia, not practical benefits to smooth evolution. But then, see
also:

        http://info.astrian.net/jargon/terms/s/second-system_effect.html

In any case though, even where a real rewrite happens, I've never
experienced a situation where the rewrite was free of copyright
entanglement. Even if you throw out 95% of the code, the 5% that gets
carried over is more than enough to make the new system a "derived
work" for those purposes. Of course, when I've worked for corporations
doing this, it hardly matters, since both the first and second versions
are entirely "(c) Acme Corp".

One thing we -could- do to let OVC play with licenses later would be to
ask developers to assign copyright to the OVC. Then the board actually
could change terms later. But OVC hardly has the years of reputation
in preserving Free Software that that FSF does--so asking that is a lot
less of a slam-dunk.

> There's a difference between housecleaning and the nuke-and-rebuild
> approach to clean-room development. I advocate housecleaning.

There are separate issues for "best development practices" and
"copyright entanglements." I quite agree it's crazy to
nuke-and-rebuild as an approach to a second system. But if you really
need control of copyright, that's what you need to do.

Here's a worst-case hypothetical: One developer of the demo either
cannot be reached later, or is so headstrong (who'd think that in a
programmer :-)) that s/he refused to relicense under the new terms OVC
wanted (even if it was something reasonable like GPL->EVMPL or
vice-versa). Call her Smith. CVS will tell us which check-ins are by
Smith; though really we probably need to go through list archives and
private email to really know who wrote what. We could rewrite
everything Smith contributed--but even there, those developers who were
in contact with Smith during development have been "contaminated" for
copyright purposes since their implementation will be influenced by
their knowledge of the prior implementation. Instead, to stay fully
legal, we need to abstractly document the requirements of a component,
then have someone brand new implement it to spec, then merge the new
implementation back in. If we don't Smith--assuming she's REALLY
headstrong--has a lawsuit against OVC. I don't think this is -likely-,
but it's better still to have it not be even a hypothetical issue.

In the end, we are better off just declaring a license that we plan to
stick with. If it's EVMPL, I think we should use my (candidate) v1.1.
Otherwise, we should just go with straight GPL, and not worry about the
revision history clause as a license issue (it can still be part of OVC
-standards- down the road; e.g. maybe required for an "OVC Approved"
stamp).

---
Dred Scott 1857; Santa Clara 1876; Plessy 1892;
Korematsu 1944; Eldred 2003
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Wed Mar 31 23:17:03 2004

This archive was generated by hypermail 2.1.8 : Wed Mar 31 2004 - 23:17:12 CST