Compulsory checkin clauses.

[kmself at ix.netcom.com]

On Sat, Aug 05, 2000 at 04:26:01PM +0930, Ross N. Williams wrote:
> At 1:56 AM -0400 23/7/2000, John Cowan wrote:

<...>

> Hi all. I am just polishing my Free World Licence for release (you
> might remember it from when I was working on it last year) and am
> agonizing somewhat over compulsory checkin clauses.

Don't agonize.  Omit.

Better yet -- don't write a new license, use one of several existin
models:  GNU GPL/LGPL, Mozilla, MIT / BSD (w/o advertising clause).
Tried and true, fit many different goals and objectives w/in the free
software space.

...which begs the question:  what are your goals and objectives.

> Last year's version (never formally released) had this clause:
> 
>    5.11 COMPULSORY CHECKIN: Within sixty days of modifying the
>    Module, you must communicate through the internet (e.g. by
>    email or through a web form) to Original Licensor (or its
>    authorized representative) the modified Module (in text
>    form) so that the modifications can be integrated into the
>    Official free version. The communication must contain your
>    name, your email address, your web address (if any),
>    reference to this Licence and clause, a copy of the modified
>    Module, and a brief description of the change(s) made. You
>    must submit each modification even if you do not publish it.
> 
> Based on some recent feedback, I have deleted it in the current
> draft. However, now I'm not so sure whether it's best to delete it
> and am thinking of putting it back in. Here are some examples of
> why it might be a good thing:
> 
> * A programmer discovers a bug and fixes it, but doesn't tell anyone!
> 
> * Two companies A and B in some market are competing. They both install
> some free software. Company A then modifies the free software to improve
> productivity, but it doesn't publish the change, so company B can't make
> use of the change to increase ITS productivity. Seems to me that if one
> of the aims of free software is to reduce wasteful isometric struggles
> (via the duplication of development effort in competing proprietary software)
> then to eliminate compulsory checkins is to forsake an opportunity to avoid
> some of these struggles. I guess from the FSF perspective, this is a case
> where the issue of freedom takes precedecence over economic efficiency,
> but it seems to me to not align with the spirit of free software.

In either of the above cases, the general philosophy of the GPL is that,
while you can strongly encourage people to act in an intelligent and
Pareto-efficient manner, you can't compel the behavior, and in
compelling it, you may do far more harm than good by killing the
incentive to play the game (use software licensed under such terms) at
all.

> * A company adds 10,000 lines to some free software to make it much
> better, but simply *couldn't be bothered* checking it in. After having
> spent $100K on improving the software, they say "Why should we waste
> a programmer day checking this stuff in just to help OTHER companies?".
> Many companies are this ruthless.
> 
> So here's an idea. Why not have a clause that requires checkin if:
> 
>   1. A bug is fixed. (7 day checkin).
> or
>   2. A total of more than 300 lines of code is changes/added (90 day checkin).
> 
> This will allow people to tool around with the code unhindered, but
> will ensure that they have to checkin if they find a bug or do some
> non-trivial development work.

Re-read your Greek fables:  the Sun, the North Wind, and the Traveller.
You are the North Wind -- blowing harder and harder trying to rid the
traveller of his cloak.  The Sun merely beams down warmer and brighter
-- the traveller, warm from his exertions, is more than happy to rid
himself of the extra weight.  The Sun's strategy in this case is to make
it easy for people to continue in their old ways if they really want to,
but to realize the compelling benefit of turning in their own bugfixes
and extensions of free software to the central maintainer because this
is easier than having to maintain fork compatibility down the road.

Create compelling benefit for returning bugfixes and enhancements.
Don't kudgel people over the head trying to get them to do it.

> I am under no illusions about the practical enforceability of these
> kinds of provisions, but I think it's a good idea at least to define
> what's required so at least people know.
> 
> Comments? Flames? 

Your last comment pretty much wraps it up:  you are under no illusions
of the practical enforceability of these provisions.  Look at the
problem from the PoV of an independent developer, or a company, which is
looking to use software with a bugfix clause.

The licensee is pretty much in the same position you're in -- the terms
are ambiguous, of dubious enforceability, but could have powerful
consequences.  My own experience in dealing with negotiations for use or
sale of software and/or services based free software is that the other
party is much less concerned over the direct costs as they are over the
potential liabilities opened up.

Suppose that at this large company a disgruntled employee hacks in
BigCoTradeSecret.h to BugFixCode, and lets it sit for 60, 90, whatever,
days.  D.E. quits BigCo and joins OtherCo, which has also been using,
and contributing, to BugFixCode.  OtherCo decides it has rights of
enforcement to BugFixCode's license, being a copyright holder of
portions of the code, and enjoins BigCo in a lawsuit to have
BigCoTradeSecret released publicly, under pains of intentional copyright
violation, etc., etc.  I can see why BigCo might choose not to use
BugFixCode, even if chances for losing such a suit were small.  Downside
risks are huge.  Promoting widespread acceptance of software distributed
under such terms, particularly when alternatives (both to software and
license) exist, is unlikely.

The other legal angle is that the primary mechanism of several of the
key free software licenses ([L]GPL, MozPL, BSD/MIT) is a fallback to
copyright.  The licenses largely address rights reserved to authors
under copyright.  Transgressing the license then moves the issue to one
of copyright law, not license enforcement.  A bugfix clause is placing a
requirement on the licensee *after* she has copied, modified, or
distributed the code (from its distribution point) compliant with the
license.  US copyright law has a strong tradition of fair use, which has
been interpreted to include investigation and study of software in the
case of reverse engineering.  It's quite possible that a bugfix clause
would be seen as restricting this fair use right of the recipient, as
well as confounding factors such as first sale doctrine (with which I'm
less familiar).  You're dealing with Australian law, which may differ,
but US copyright law is a large part of the relevant landscape.

The same fair use arguments might also be used as a launching point for
deciding that bugfix clauses violate the four freedoms Stallman speaks
of for free software, specifically:

    The freedom to study how the program works, and adapt it to your
	needs. 
	http://www.fsf.org/philosophy/free-sw.html

There may also be a conflict with the Open Source Definition, though I
believe this is an open question, and I'm not familiar with earlier
arguments.  Sun's SCSL and Apple's APL both include similar terms.  SCSL
has not been OSI-Certified, not sure about the APL, though it's not
listed on OSI's licenses page:  http://www.opensource.org/licenses/

The relevant parts of the Open Source definition IMO might be:

	1.  Free Redistribution "The license may not require a royalty or
	    other fee for such sale".

    3.  Derived Works "The license must allow modifications and derived
	    works..."

    http://www.opensource.org/osd.html

...if you consider a bugfix obligation a royalty or other fee, then
bugfix requirements are not OSI compliant.  As I said, I don't have the
discussion history here, I'd be interested in other reads.

Oblig:  IANAL.

-- 
Karsten M. Self <kmself at ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Opensales, Inc.                    http://www.opensales.org
  What part of "Gestalt" don't you understand?   Debian GNU/Linux rocks!
   http://gestalt-system.sourceforge.net/    K5: http://www.kuro5hin.org
GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20000806/49a7d3e1/attachment.sig>