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

Hi Martin,

Thanks. Comments below:

> [...]
> 
> 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/.

Great, thanks. I'll try and install it today.

> 
>>> 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.

OK, well what about the version on the UCAR website? Is that MIT-like, or
LGPL? Also, can you even do this? LGPL is copyleft [1], no?

> 
> 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.

I'm not so sure about that. See Apache's take on it, here [2] and here [3].

> 
> 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.

Hmm, not sure about that but IANAL. We should check with Apache
legal-discuss [4] and ask.

> 
> 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.

Yep, agreed. It would be great to get an ASLv2 licensed version of both
OPeNDAP as well as the NetCDF Java library, but that's just my opinion.

> 
> 
>> +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+Usa
> ge+Guide#SonatypeOSSMavenRepositoryUsageGuide-7b.StageExistingArtifacts

Yeah that's basically what I did with my mods, except I re-generated the 4.2
artifacts myself from a latest SVN build (and yes I did the *full* build,
and will change it to just the minimal jar build as discussed). Or I can
just take your artfiacts and stage them, but I'm hesitant to do that since
their dependencies aren't available on Central yet. The nice thing about
having the *-all.jar is that at least its dependencies are self-inclusive
and we don't' have the problem that its deps aren't on Central: all of its
deps are included and self-contained.


> Can we deploy opendap in the "edu.ucar" namespace, and then come back on the
> mailing list for the next step?

Yeah probably we can. Can we address the license issue, first? Then I'll be
happy to publish it and move fwd...

Cheers,
Chris

[1] http://www.gnu.org/copyleft/
[2] http://www.apache.org/legal/3party.html#category-x
[3] http://www.apache.org/legal/resolved.html
[4] mailto:legal-discuss@xxxxxxxxxx


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@xxxxxxxxxxxx
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++




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