Henning Makholm writes:
> I.e, in addition to letting people fork our project (which I realize
> could be necessary e.g. when our grant expires if we can not fund further
> development man-hours), we must let them fork our project and keep that a
> secret from us.
But you've already given them permission to do that:
| - You may modify [the program] and use the modified form within
| your own organisation.
> Why on earth?
>From the Debian Free Software Guidelines:
3. Derived Works
The license must allow modifications and derived works, and must
allow them to be distributed under the same terms as the license of
the original software.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in
modified form _only if the license allows the distribution of "patch
files" with the source code for the purpose of modifying the program
at build time. The license must explicitly permit distribution of
software built from modified source code. The license may require
derived works to carry a different name or version number from the
original software. (This is a compromise. The Debian group
encourages all authors to not restrict any files, source or binary,
from being modified.)
It seems to me that your clause violates (3) by placing additional
requirements on the distribution of derivatives and (4) by being a
restriction on distribution of derivatives other than a "patch clause".
It is also excessively vague.
I really think your concerns are unfounded. It is very unlikely that
anyone is going to produce and distribute any significant improvements to
your work without you learning of them. Why not chage the requirement to a
request, and then encourage compliance by making your institution the
center of activity involving your package? Put up a web page, run a
mailing list, maybe provide a cvs repository. People want to distribute
their improvements. Make sending them to you the best way to do it.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
