Subject: open source definition
From: "Jonathan S. Shapiro" <jsshapiro@earthlink.net>
Date: Tue, 21 Apr 1998 12:33:28 -0400

Critique of the Open Source definition page at:

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

I have some suggestions for enhancement/clarification that I think
should not be controversial, and one serious difference of opinion
that won't come as a surprise to anyone.

I'm also sending to the FSB list for reactions.


NON-CONTROVERSIAL: (I hope)

All of these are suggestions for clarification or point out holes in
the license.  I believe that they are all consistent with the intent
of the terms as published.  They are certainly intended to be.

GENERAL:

The term 'author' should be replaced by 'rights holder' throughout.
This is generally the author, but not always.  If a company decides to
release something it owns into the open source domain, it is not the
author and under strict interpretation therefore cannot take part in
the Open Source branding program.


PROVISION 2: SOURCE CODE

	"The source code must be the preferred form in which a
         programmer would modify the program."

I read this to be stronger than I think was intended.  Here is an
example from an end-user perspective: apache-prime:

	I want to install an apache module.  I don't have the time or
	inclination to rebuild apache-prime.  The most convenient
	mechanism from the end-user perspective would be a dynamically
	loadable binary module that was also accessable in source
	form.

So far, so good.  However, if apache-prime is designed to facilitate
this approach, it is not clear that it meets the requirement that
[paraphrased] "source code be the preferred form of modification."

You could require that the program license insist that add-ins be done
in source form, but this prohibits a proprietary-enhanceable free
giveaway and is inconsistent with existing licenses.  

It may not be an issue in practice.  The enhanceable giveaway is a
short-term viable strategy, but *only* short term.  Open source
developers will soon replicate such a thing if it is useful; the
advantage to permitting it is that it places the base system in the
open source domain and encourages people to invest money in marketing
the base system.

I therefore suggest adding clarifying wording something like:

	Programs providing a binary plug-in or add-on interface are
	not in conflict with this provision, provided that the program 
	itself meets the terms described here.


PROVISION 2: SOURCE CODE

The rights holder should be able to prohibit redistribution of
modifications that would not meet the terms of the open source
license.

Example 1:

I incoporate a patented algorithm, redistribute it, and then hit you
for a patent license.  This violates the intent of Provision 7 (which
needs clarification, by the way).

Example 2:

I distribute a CD-ROM under Open Source containing MPEG content, but I
fail to convey to you the right to publicly redisplay that content.
This does not seem to me to be "open" in the sense of the license.


Problem:

The Berne Convention has a notion of "artistic integrity" that applies
to all copyrightable works and is (by law) vested in the author and
not transferable or waivable (also by law).

Under this convention, I can sue you for using my work in a context
that was not consistent with the work's "intent."  This has been
successfully applied to things like "where a painting was displayed"
and could presumably be stretched to inappropriate use of software.

Contrived example: In Europe, I could argue that it is aesthetically
unacceptable to run EROS in an IBM shop and sue you for doing so.

How does this interact with an Open Source license?  Should it be
addressed?


PROVISION 3: DERIVED WORKS

There is a gaping liability problem inherent in the wording "under the
same terms".  Suggested modifications:

	The author may require that redistributed variants prominently 
	note that they are modified and by whom.

	In addition, the author may require that the redistributed
	variants must NOT use certification marks that are owned by
	the author or used by the author under licensing constraints.

This provides a legal basis for authenticating authorship and for
insisting that authorship not be misrepresented or represented in a
confusing fashion.

In particular, this is require to prohibit a modified binary from
being distributed under the "Open Source" brand.

Based on a phone discussion with Eric, it seems this is consistent
with the original intent.

This is a separate kind of restriction from the patch file issue.



PROVISION 7B: TRANSFER OF REQUIRED RIGHTS

Suggested addition: (you'll want to word this carefully)

	The license MAY require that redistribution of derived or
	modified versions implicitly convey a royalty free,
	unrestricted license to use AND REDISTRIBUTE any intellectual
	property rights necessary to lawfully execute the software.

	[ Issue: no bait and switch with hidden costs ]

	The license MAY require that modifiers who are unable to
	satisfy this provision may not redistribute their
	modifications.

	[ Issue: people should know what they are getting, and nobody
	  should be allowed to put me in violation by encouraging me
	  to download and use something I won't have the rights to.

	  Note that you might have the right to place something on a
	  web/ftp site were I can get it even if you don't have the
	  right to grant me a right to use.   Example: crypto sw. ]

See also my examples under "PROBLEM 2" aboe.


CONTROVERSIAL:

PROVISION 1: FREE REDISTRIBUTION

I have no problem with saying "no royalty for aggregating the thing on
the same media."

I have no problem with saying "no royalty if you don't make a profit."

I have a big problem with saying "if you make a profit on a modified
version the author can't insist on a cut."

It may be that this is just a difference of opinion on which I will
not come to agreement with the Open Source community.  My belief is
that there is merit to requiring source availability without
restricting commercialization.


Let me argue for why allowing this is a good idea, and the claim about
incentives to defect is mistaken:

Suppose company X enhances my software Y and charges a profit. The
enhancement will tend to be minor relative to my software, because
there is only so much the market will bear as a fee for free-derived
software.

This furthers the cause of distributing Y, getting it into more
people's hands and making them aware of the utility of it.  If the
enhancement X of the software is truly valuable, the free software
community can easily replicate it.

In the meantime, the free community has actually benefitted by
leveraging the marketing dollars that the commercial entity applied.

Key issue: the contribution of marketing energy is a valid and viable
means of cooperation.


Jonathan Shapiro