Re: [netcdf-java] [netcdfgroup] NetCDF jars=>Maven Central Repos?

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



  • 2010 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: