Request for advice on license drafting

chris yoo yoo.chris at
Tue Feb 8 04:09:23 UTC 2005

Hi David.
Thanks very much for your comments - my replies are below

> This is much like the Qt Public License.   

Thank you for pointing this out. I was not aware that this was
addressed in the QT Public License. The proposed license frames it in
a somewhat more complicated way, with the assignment of copyright as
apposed to a mere grant of license. I framed it in such a way because
that is how it is done in  dual licensing schemes (mysql, trolltech,
open office, etc). I do wonder why such companies go to such lengths
to obtain copyright in contributed modifications, and are not
satisfied with a grant of license like the one in the Qt license.

> >2. The option for the Licensee to be released from some of its
> >obligations under the License, (i.e. the Licensee's obligations to
> >release source code, notify the Licensor of contributions, assign
> >joint copyright to the Licensor, etc) for a mutually agreed
> >consideration between the Licensor and Licensee. This will allow
> >additional flexibility to the Licensee's use of the software, while
> >ensuring that the principle of reciprocity is retained.
> >
> >
> Could you explain this one in some more detail?  

By default, a number of obligations are placed upon licensees under
the proposed license, including:

1. The obligation to make the source code of any modifications
available to the public upon distribution
2. The obligation to notify and make the source code of any
modifications available to the initial developer upon commercial use
(excludes research and personal use)
3.  The obligation to assign coypright in any modifications to initial
developer so that initial developer can incorporate those
modifications into the main project

These obligations are placed upon the licensee, to ensure that the
time and effort invested in the development of  the original software
is reciprocated with the time and effort invested by the licensee in
improving the software.

However, the licensee may not wish to reciprocate in such a way. Thus
the license provides a flexible alternative - coming to an agreement
with the initial developer to be released from some or all of these
obligations for a mutually agreed consideration.

> What are you trying to achieve with it?

I believe that there are significant barriers to taking a project
'open source'  when considerable time and effort (=money) has been
invested in creating a piece of quality software. How can the initial
developer(s) be assured that their investment in the software will be
returned to them upon release of the source code to the public?

What if the nature of the software is such that it is not designed to
be re-distributed, as would a library class (trolltech) or database
(mysql) but merely used by the licensee (e.g. text editor)? Without
requiring the licensee to give back modifications that are used
commercially but not distributed, it is quite likely that the initial
developer will receive little if any improvements to the software.

What if the software is so well written and distributed with ease that
there is no room for
'additional' services such as packaging, support and implementation
through which to generate income (Redhat)?

However, What if despite all of this the initial developer strongly
believes that software should be open source.

I hope this clarifies it a little :)
> I noticed that the RPL got a rather bad wrap by users of slashdot
> today.  Macstl was linked on slashdot today. (
> This
> is by Glen Low, who was discussing licenses in June last year on this
> list.

I have also come across many negative comments on the RPL. A common
mistake by skeptics seems to be that any modifications for any use
must be returned to the initial developer. However, the RPL
specifically excludes personal and research use. It simply states that
any commercial use must be reciprocated by returning modifications. I
think that this is 'fair', and does not deserve the criticism it
attracts. Commercial use is exactly that - use of software to make
money, whether such use be internal (thus decreasing the costs of the
organisation) or external is largely irrelevant. Should commercial
organisations make commercial gains through the use of software
obtained free of charge, but then refuse to reciprocate in any way or
form back to the initial developer, it is the initial developer who is
losing out.

Please note that I am not in any way trying to change the nature of
open source software, or argue that this approach is better than
others - I am merely attempting to address some of the barriers and
limits to the more widespread adoption of open source software.

Thanks for reading. 


More information about the License-discuss mailing list