[Fsatom-comm] New committee ; mailing lists

[Peter Murray-Rust]

At 12:31 29/10/2003 +0100, David van der Spoel wrote:
>On Wed, 29 Oct 2003, Konrad Hinsen wrote:
>
> >In summary, I see two options, both of which are fine with me:
> >
> >1) We do accept Mark, but change our formal goal to something less specific.
> >2) We look for a committee member who supports our current goals.
> >

As a newbie I may have missed previous discussions... so please forgive 
misunderstandings

IMO the "free" ethic, to which I generally subscribe, goes beyond software. 
The principles for software can be somewhat restrictive when applied to 
other components. I see three main components:

1 software including source
2 data (e.g. program input and output, reference data, etc.)
3 specifications

As an example HenryRzepa and I create and distribute "CML". CML is not 
primarily software but a series of specifications. I *do* distribute 
software as well but primarily to act as a reference implementation and as 
components to be built into larger applications. I wish the following 
freedoms for CML (and these may apply to  any MLs FSATOM creates)...

a to be known in perpetuity as an author of CML. (No one can scrape Henry 
and my names off and pretend they wrote it).
b for CML to be freely copied without hindrance and without further 
permission from me or Henry
c that CML specifications remain unaltered except through processes which I 
and Henry have devised
d that any reference implementation ("validateCML") I have written be 
freely available under opensource *but* that it may not be altered and 
retain the same name.

(and that our names are not used inappropriately, we take no responsibility 
for blowing up nuclear installations, etc.)

(d) is incompatible with GPL (which I discovered when I contributed to 
Openbabel). The GPL people discovered it and informed us that this 
condition could not be applied. I therefore use another opensource licence, 
Artistic, devised by Larry Wall for Perl which I think meets the conditions 
I want, while remaining opensource. IOW anyone can take ValidateCML.exe and 
hack it as long as they call it something different and acknowledge it as a 
derivative work. The point is to prevent *undetected* mutation, not to 
prevent mutation.

I assume that FSATOM will create (at least).

1 complete applications (*.exe)
2 libraries (e.g. F90XML, AlbertoG, JonWakelin, PMR, etc.)
3 glueware (Python, etc.)
4 specifications (FooMLs, etc.)
5 data (values of parameters, universal constants, etc.)
6 validation tools

4,5,6 and probably 2 need protecting from undetected mutation

I am personally relaxed about contributors who adhere to the openness of 
some but not all of these - particularly 2, 4, 5, 6.  When we ran XML-DEV 
to help develop XML we promoted the value of Open tools for XML development 
(and take some credit for persuading some companies to release open code). 
However we also welcomed commercial vendors who helped contribute to the 
open nature of the protocols, data, examples, etc. even if their products 
were not open.

It can be argued that if closed.com makes significant contributions to open 
protocols this is useful. However I can also accept that for some FSATOM 
members the presence of seriously closed codes is a hindrance to the 
community and the development of software. Personally I feel that software 
development has been held back in chemistry through closed codes and that 
the modern use of data is seriously restricted because of lack of openly 
available databases.

HTH

Peter