NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Martin, >> 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? > > Yes, but we are not allowed to change the licence (except upgrating the > version > number in some cases). The LGPL licence on OPeNDAP can not be removed. There > is > nothing we can do about that except contact the OPeNDAP owner. In opendap.xml, > I > added the MIT licence in addition of the LGPL licence, but thinking again > about > it I'm not even sure I'm allowed to do that. Yeah you'd probably need to check for sure with the OPeNDAP folks. > > >>> 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]. > > Seems you are right... In http://www.apache.org/legal/resolved.html at section > "Which licenses may NOT be included within Apache products?", there is LGPL 2, > 2.1 and 3. > > But in http://www.gnu.org/licenses/license-list.html at section > "GPL-Compatible > Free Software Licenses", there is Apache License Version 2.0. Note that Apache > License Version 1.0 and 1.1 are listed in "GPL-Incompatible Free Software > Licenses". > > I interpret that as meaning that [L]GPL softwares can not be used by Apache > softwares, while Apache softwares can be used by [L]GPL softwares provided > that > the licence version numbers are 2 and 3 respectively. But this is only my > interpretation; I don't really know. Yep I know that ASLv2 licensed components are useable in GPL and LGPL products; but the same is not true unfortunately in reverse. > > >> Hmm, not sure about that but IANAL. We should check with Apache >> legal-discuss [4] and ask. > > That would be much better than relying on my interpretation :). Are you > registered to that list? Yeah I'm registered. I'm a member of the Apache Software Foundation (ASF) and have dealt with stuff like this in the past. ASF legal's original interpretation of the NetCDF java library was that its specific license allows us to use NetCDF java in Apache libraries. However, that was under the assumption that the software itself was licensed under an MIT-like license, specifically w/o knowing that OPeNDAP itself is LGPL and NetCDF-java includes it. It would be much better if NetCDF-java would put out an OPeNDAP free version of their software product, until the OPeNDAP folks can be contacted regarding their license. In fact, I think that's the best bet. The NetCDF minimal Java jar -- must it include OPeNDAP dependencies? I think it's possible to exclude them, no? > > >> 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. > > In my understanding, the only way to get OPeNDAP licenced under something else > than LGPL is to ask to the OPeNDAP authors... Yep, mine tool > > >> 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. > > Yes, but the licencing issue of OpenDap remains... Having separated JAR files > also allow to separate the licensing conditions. Yes, and no. There's actually a bunch of concerns regarding dependencies between software libraries and between what is truly considered a derivative work, where the license kicks in. So, separating them may not even save us there. We need to look more into this...I'm going to do so on the Apache side, and it would be great if the NetCDF community also looked into it as well. I'm happy to help where I can. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
netcdf-java archives: