Le 03/11/10 02:23, Mattmann, Chris A (388J) a écrit :
I just pushed the files on our public server for convenience. If you have
Mercurial installed on your system, you can get the files as below:
hg clone http://hg.geotoolkit.org/netcdf-deploy
OK, I will look for them there, thanks. Is Mercurial the same as Git? I have
Git installed on my Mac, but not sure that I have Mercurial. Can I just do
git clone?
It is a Distributed Versioning System (DVS) like "git", but still a different
software. This is the DVS used for OpenSolaris, OpenJDK, OpenOffice, Mozilla,
NetBeans, Python and other. Mercurial commands are intentionally very similar to
SVN commands in order to make transition easier for SVN peoples.
If you are using MacPort, then you can get it with:
sudo port install mercurial
Otherwise you can download from http://mercurial.selenic.com/.
Yes, I fell that a clean approach would be to create new JIRA issue for
"org.opendap". Do you want me to take this action?
Actually, looking at OPeNDAP's license [1], I'm a bit confused. The license
states that OPeNDAP is LGPL, however, NetCDF is more like a BSD/MIT style
license [2]. How is it possible to include OPeNDAP-Java in NetCDF-java and
not have NetCDF immediately be LGPL? I'm actually kind of worried now b/c I
was going under the assumption in Apache Tika that NetCDF was amenable to
use in an Apache environment. See my discussions on Apache legal about this
[3].
Given the information provided by John Caron in previous emails, the library
bundled with NetCDF is actually a derivative work of the OPeNDAP library, not
the OPeNDAP library itself. Consequenty I updated the pom.xml files in the
Mercurial repository in order to change the groupID from "org.opendap" to
"edu.ucar". In addition, I added a <licences> section with two licences: the
LGPL one under OPeNDAP copyright and the MIT-like one under UCAR copyright.
In my understanding, the LGPL licence does not force NetCDF to become LGPL. It
would be the case if the license was GPL. But the "L" in "LGPL" remove the viral
aspect.
However I think that LGPL 2.1 is incompatible with the Apache licence, and that
this incompatibility has been solved in LGPL 3. The source code of OPeNDAP state:
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
A key point is "or (at your option) any later version". Consequently we are
allowed to upgrade the license to LGPL 3, which would solve (in my
understanding) the Apache-licence compatibility problems.
For now I declared LGPL 2.1 in the pom.xml. It would be nice to hear from UCAR
(John?) which action they wish to take.
+1, that sounds good to me, but we need to address the opendap issue. I'm
wondering if a more modular build set up as maven projects (e.g.,
netcdf-core, netcdf-opendap, netcdf-idv, netcdf-util, etc.) that builds
separate artifacts for netcdf, like maybe:
netcdf-core-X.Y.jar
netcdf-opendap-X.Y.jar
netcdf-idv-X.Y.jar
netcdf-thredds-X.Y.jar
Would work better? Then folks could pick and choose which parts of NetCDF
(and which licenses better yet) to include in their sources.
I think that a more modular build would be desirable, but that would be for
NetCDF 4.3 deployment. For NetCDF 4.2, I think it is safer to perform the steps
described here:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7b.StageExistingArtifacts
for being sure to deploy exactly the existing JAR files (not rebuild them).
Can we deploy opendap in the "edu.ucar" namespace, and then come back on the
mailing list for the next step?
Regards,
Martin
