My interest and the effort I put into Qi and in the future, Shen, is for
intellectual stimulation rather than the prospect of any financial gain or
remuneration. I think Qi offers a very interesting framework for the study of
computer language structure and development and we are indebted to you for
providing this software playground. My feeling is that we should encourage
people to join this project or at least play with the result by making the
licence terms as permissive as possible so my vote is for both Qi and Shen to be
released under the modified BSD or MIT but many of the alternative FOSS licences
in:
http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licenses
http://en.wikipedia.org/wiki/List_of_OSI_approved_software_licenses#OSI_approved_licenses
would probably also be fine by me if people have a particular preference. For
those who dislike the possibility/prospect that their effort on Qi/Shen might be
included in a commercial product and they would like to disallow this then a FSF
GPL or equivalent would seem suitable and also fine by me. My company releases
OpenFOAM under the GPL to avoid our work being ripped-off and we sell support
and consultancy services to pay for our work and this is an effective strategy
for this product. However, it is not clear if there would be an interest in
including Qi/Shen in a commercial product and even if there might be it is not
clear that this should be discouraged and that is why I would be happy for any
of my work on Qi or Shen to be released under a more permissive licence like
modified BSD or MIT if you think that this is most appropriate for the project
as a whole.
Henry
My understanding is that the GPL does not preclude commercial use but it does
preclude inclusion in a closed-source commercial product. Whereas the FPQi
licence precludes use for a commercial purpose unless the book is purchased
which then also allows inclusion in a closed-source commercial product. It
seems to me that the aims and motivations of the two approaches are rather
different.
> I guess that BSD would be widely understood and as of now seems the
> logical choice.
I agree, it makes the licencing very simple and easily understood to developers,
contributors and users.
> Qi was designed to be programmable using sugar functions and be shaped
> like putty to look like whatever you want. This means that Qi can
> spawn a whole host of experimental languages mounted on different
> platforms. In philosophy this is the diametric opposite of Python
> (fixed syntax and format). A sort of creative chaos can ensue and I'm
> not too unhappy about that.
I agree, and it is partly this freedom and flexibility that drew we in. What I
have found though is that I cannot achieve my aims simply via sugar functions
and that hacking the core to some extent has been necessary. This in turn has
required a significant reorganisation of the code to support a boot-strap build
system so that each version can be built using the previous version and generate
the pure Lisp along the way so that it can be distributed without the complete
build chain. I hope this smooth build system will be useful in the development
for Shen and perhaps some of the ideas I am testing in Qi could also be accepted
into Shen. Currently most of my work inherits your FPQi licence as required
and the bits which are independent of your code are GPL but as yet unreleased.
I would be happy to release everything I have done and will do on Qi/Shen under
the modified BSD licence if there is an interest in this work.
> I think people need to be free to pursue
> their ideas - I certainly did. And inevitably other people's ideas
> are going to differ from mine. It would be good though to have some
> sort of core for people to come back to - some sort of standard which
> is guaranteed to run. A kind of drum beat to hold together some
> frenzied jamming sessions.
I agree, but at this stage I think people need to play with the core a bit and
then see what comes out of this and put together the best ideas for the
ultimately stable core.
> Generally I think that the way to do this is to be cautious in hacking
> the sources too much, to be liberal in building in features that
> *expect* that people will want to do their own thing. Sugar functions,
> programmable comment characters are examples and this approach can be
> extended.
I am not convinced about programmable comment characters because variation at
this level makes code portability, comprehension and the programming of
font-locking and automated indentation into editors difficult.
> We want to avoid a situation where there are umpteen
> experimental copies each of which require people to reinstall Qi/Shen
> just to run experimental ideas. We want to be able to run these ideas
> by simply loading them into the standard.
I agree, but is now the time to define this fixed core of functionality? Or is
the definition still evolving? And if so would it be a good idea if
experimental copies are created as a testing ground for the pieces of the
eventual stable core?
Henry
I am glad that you have found my efforts useful and I will be taking this
further still by generating more of the Lisp from Qi source. I am more than
happy for you to use whatever I have done with Qi in whatever way suits your
purpose for Qi or Shen and would be happy to change the licence on my parts from
GPL to the modified BSD if Mark chooses that way to go for Qi and Shen.
Henry
I would be happy to release everything I have done with Qi so far and in the
future for you and other to review, use, discard, as you see fit, but under what
licence?
Henry
I agree, this will add some very useful flexibility and consistency to Qi/Shen
and I look forward to using the functionality. For me this is more important
and useful than the port to Clojure or Python but this is a personal preference
as I do not have a use for Qi/Shen running on Clojure or Python.
Henry
Exactly, so my question is under what licence should I distribute what I have
done with Qi to you, Stefan and anyone else who might want to play with it? If
you are happy with the BSD licence I am happy with that also, would you prefer
the 2 or 3-clause form? I don't mind on this point either.
Henry
But my work is derived from Qi version 1.06 so it currently inherits your FPQi
licence, are you saying that I can now release my complete Qi version with the
new boot-strap build system under the BSD licence?
Henry
Henry
I don't think the difference is very important but NetBSD uses the 2-clause form
which is the same as the 3-clause form except the 3rd clause:
* Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
is dropped.
See http://en.wikipedia.org/wiki/BSD_License in particular
* NetBSD switched from a 4-clause to a 2-clause BSD-like license on June 20, 2008; it removes the third (endorsement/promotion) clause.
* A 2-clause BSD-like license also exists which deletes the third clause, prohibiting use of the copyright holder's name for endorsement purposes. Removal of that clause makes the license functionally equivalent to the MIT License. This is the only BSD-style license permitted for certain libraries included in KDE.
* FreeBSD also uses a 2-clause license with an additional statement at the end that the views of contributors are not the official views of the FreeBSD Project.
* FreeBSD also provides the FreeBSD Documentation License, a license similar to the subsequent BSD Documentation License that contains terms specific to documentation.
* OpenBSD uses a license modeled after the ISC license, "equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention."[5]
I think we should use one of these 2-clause versions but if you prefer the
3-clause form that's fine by me also.
Henry
Good, I will do the same.
Henry
What about for commercial use, e.g. writing a data manipulation tool to convert
files as part of a commercial project? GPL would not preclude such a use
but it is not clear if your licence does.
> If you modify my code; you cannot put it under BSD. And this applies
> even with a commercial license which allows you to run Qi for money.
> If you have a license then what you do with code written *on top* of
> mine is your affair.
Sure, I have bought your book and so I have a licence but it is not clear under
what conditions I can distribute my work as all of it appears to inherit your
licence.
> If you build something which runs under vanilla
> Qi, and you have a license, you can close your code off or give it
> away as you want.
That does not help Stefan; he needs the source code I have written and his code
is under the BSD licence.
> Read the license and don't think that when I say you can do what you
> want with 'your code' I am giving you carte blanche. I am not.
It is still not clear how I can contribute to the Shen project if I cannot
distribute code needed for it under the licence it is to be distributed in.
> ***Hence if you really want to have Shen under BSD you would be
> advised to port Shen to Clojure
But it will still contain Qi source code which is currently under your FPQi
licence. Which bits of Qi can we include in Shen under BSD?
Henry
Yes I understand but that is not the same as the example I gave: writing a data
manipulation tool to convert files for part of a commercial project. Can such a
tool be used for a commercial project without buying you book or not? This tool
is not distributed or included in a commercial product, only used for a
commercial project.
> You can contribute to changing Qi sources if you want your changes to
> remain under the Qi license. Alternatively you can implement Shen in
> Clojure and that's your work and you can put your license on it.
But as you said you expect 80% of Shen is to be QiII in Qi source rather than
Clojure source, but the QiII sources are under your licence so how can they be
included in Shen if Shen is to be distributed under the BSD licence?
Henry
My understanding was that Shen was to be a Qi development which supports
Clojure, Python etc. as the underlying Lisp-like language. But as with Qi, Shen
was to be predominantly written in Shen rather than Clojure etc. Also my
understanding was that Shen was to be developed from where you left-off,
ie. from your current QiII .qi source files or is this not the case? Or are we
supposed to be writing Shen from scratch without reference to QiII?
Henry
But surely ~3/4 or more of Shen will be written in Shen/Qi just as ~3/4 of Qi is
written in Qi and not Lisp. The question is do we need to write this ~3/4 of
Shen without reference or use of any of your Qi sources? If so then Shen would
be completely independent of Qi so what is the relationship between Shen and Qi?
Henry
Just one final clarification: are we allowed to write it in Common Lisp?
Yes I know but I don't know how this is relevant to the discussion: I am
interested in Stefan's ideas for Shen but only if Shen will run on Common Lisp
as this is the platform I use for performance reasons. If you do not permit the
use of Common Lisp for Shen then there is nothing in the project for me.
> The project was to move it to Clojure.
I didn't realise that would be exclusive and that Common Lisp would not be
supported or even allowed as a platform.
> This question you would not ask unless you were more interested in changing or
> subverting the license.
I am not interested in changing or subverting your license, I am just trying to
understand your current terms for Shen as they seem to have changed since you
first proposed them.