support requirement

VAB alexb at ufl.edu
Mon Aug 30 19:07:14 UTC 1999


bruce at perens.com wrote:
> 
> Thus, their license requires that if you distribute a derived work of their
> program _and_ you provide support on reasonably comparable programs,
> that you provide support for their program too. The provision has no effect
> on organizations like Debian that don't provide support.
> 
> This is currently the stumbling block for X's license being Open Source.
> Any ideas, folks?

I don't see any way for this to occur under the OSD.  The requirement of
providing support for product X if you derive product Y from product X
violates paragraph 1 of the OSD - Free Redistribution.  I would also
argue that it violates paragraph 5 as well, by requiring that one group
of developers incur monetary costs providing support (which possibly
prohibit their development efforts) while other developers are free from
that restriction. 

While it may be possible to interpret the OSD as allowing this type
of licensing, in my opinion something like this violates the most
important aspects of free software.  It violates the right of a
third party to fork the project by placing demands on third parties
who do.  In the very least it discourages forking by this requirement.
The ability to fork is critical to the development of cutting edge, 
lean, stable software.  The ability to fork has played a large part
in the development of opensource software's reputation for stability.

I think Vendor X's methods are misguided.  If Vendor X is interested
in the benefits of opensource and feels the their current course of
action is critical, they could continue and release the source code
with a non opensource license that contains the suggested terms.
If Vender X is interested in contributing to the community and in
reaping the benefits that are incurred through that action, Vender X
should release their code under the GPL.  Release under the GPL
ensures that the code is available to everyone, available as opensource,
and that the code remain available for refinement and improvement.

A fact rarely mentioned on the list is that release under a 
license other than the GPL brings with it the danger that 
the software product will be reimplemented under the GPL.
This is likely if Vendor X releases under a license which
is unattractive due to say, required support terms.

If a GPL'd application defeats Vendor X's OpenSource (or
Non OpenSource/Source Available) application in the battle for
market share, Vendor X looses many of the benefits the focus of
community developers could have provided to it, and Vendor X
really looses out if people pick up the standard app (the GPL
app) and provide support for it.

In summation, release under the GPL (even though it does not
have the support guarantee Vendor X is looking for) nearly 
ensures (as long as Vendor X is receptive to patches and
suggestions) that Vendor X's app becomes the standard app 
for it's nitch with in the community, encouraging it to be
picked up and supported.  Release under a license other than
the GPL encourages reimplementation, especially if that
license is for some reason unattractive (if for example it
would be cheaper for Vendor Z to reimplement or base on an
alternative GPL'd project than provide support).

	- VAB
---
V. Alex Brennen    [vab at pog.ufl.edu]
[http://www.metanet.org/people/vab/]
Systems Administrator/Sys. Prgr
Pediatric Oncology Group
[http://www.pog.ufl.edu/]
Statistical Office
University Of Florida
352.392.5198 x303
352.392.8162 Fax



More information about the License-discuss mailing list