On Dec 11, 2009, at 10:44 AM, Peter Murray-Rust wrote:
> Thank you Andrew for this very detailed account. It's clear that the details
> are complicated so let me take a higher level view.
I fail though to see how taking "a higher level view" resolves the license
conflict which appears to exist between JUMBO and packages which use JUMBO.
I fail also in seeing how this view clarifies how BO considers SMILES to be a
vendor specific format while CML is not.
These are the main two reasons I am involved with this thread.
> To summarize, therefore, Andrew and others have identified that we have a
> licence maintenance problem.
I would have said "license conflict", for I don't see what maintenance has to
do with it.
> Many of the BO components are 10 or more years old (CML was published in 1999
> and CDK and (Open)Babel and Jmol are older). The licences, code, etc were
> written at that time and many have survived to this day not throughy design
> but because it's a difficult maintenence problem. Most BO contributors would
> probably put higher priority on fixing bugs , refactoringand developing
> interfaces than managing the interoperability of licences.
I cannot help but read that as saying that you consider the legal basis for
open source to be less important than developing software and fixing bugs.
Given your well known history in advocating open source, that cannot be a
correct interpretation, but I fail to find a better one. I seem to be full of
fail.
Open Source CANNOT exist if its participants and especially its advocates - of
which BlueObelisk is one - do not respect and follow copyright and licenses.
As you consider historical context to be relevant, let me also bring up my own
history.
My own software contributions in this field go back to 1993 and persist in the
VMD and NAMD packages. I incorporated many other packages and libraries into
VMD, and make sure to only include those which were compatible with the VMD
license. Several times this meant discussions with the authors to get the
needed permissions.
I wrote the Biopython license in 1999 and made sure to address all of the
issues I have brought up here. These general issues, though of course not the
details, were described in the book "Open Sources". It came out in 1999 and
includes the section "The Open Source Definition, Version 1.0". I see now that
there's also a section in that book titled "Open Standards, Open Documents, and
Open Source", which sounds familiar. ;)
I know the original developers of what is now the OpenBabel code base, back
when it was OELib. For that matter, I knew them when they were still working on
the Babel code base. The licensing issues were known to them, and leads to why
they picked the GPL v2 without allowing updates to future licenses. If it's of
any relevance, I can assure you that they were not advocating for open data,
and that they considered SMILES to be an open specification.
All this is irrelevant of course. The problem is that modern packages are using
software in violation of that software's license. And my personal problem is
that BlueObelisk considers SMILES (up until OpenSMILES) to be a proprietary
specification but does not explain why CML is not equally proprietary. Both of
these are modern problems, not in need of historical perspective.
> For now, **are there any BO activities that are seriously held back by the
> licences we have**. I appreciate there may be a lack of clarity but untilo
> now no-one has mailed me or the BO about licence concerns and says it is
> holding them back. For example OSCAR uses the Artistic licence - it's widely
> used and incorporated in commercial products but no-one has raised the
> problem.
Which commercial software uses OSCAR under the Artistic License? I would like
to ask them how to obtain a copy of the source code to their entire executable,
which the license requires.
The following comes from "Open source software law" by Rod Dixon, on the topic
of the "Artistic License", after it quotes from the license:
The foregoing provision essentially establishes what modifications
to the open source project, when added to the source code, become
part of the project's copyright. Notably, this provision makes no
mention of modifications constituting an original work created by
the licensee, except or public domain source code. Although this
exception is or may be quite significant, the licensees are
forewarned that their contribution will be subsumed by the project
in practically all instances.
Quite clearly, any commercial software which embeds OSCAR3 (I did check the
license and it is the original "Artistic License") and which are not "C or perl
subroutines" must in turn be licensed under the Artistic License. The Artistic
License also has no provision for distribution other than as source (the
"Package") or as an executable. Jar files are not permitted, because jar files
are neither a derivative created through textual modification nor an executable
file, which are the only two distribution terms mentioned in the license.
Just as clearly, the JUMBO license under the "Artistic License" requires that
CDK, JChemPaint, Bioclipse, and others which include JUMBO in their jar
distributions, must also be distributed under the Artistic License, or those
packages must remove JUMBO, or the JUMBO license must be changed.
Or this problem can be ignored, in which case the participants aren't fully
supporting free or open software.
That no one else has bothered to read the licenses until now is a mystery to
me. Surely that's the first thing people do when they decide to incorporate a
package into their project?
Then again, I'm not sure that people have even read and understand the licenses
for the software they themselves distribute.
Now that I've pointed it out, those activities should be "seriously held back."
I have not gone out to each project to report this license conflict, because I
figured it was best to report this problem to you directly and get it resolved
at the source, which I did last Saturday.
It seems the resolution is that the license terms will not be changed, so there
will have to be changes in the downstream packages.
Cheers,
Andrew
[email protected]
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Blueobelisk-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
