issue_comments

Great news! Thank you Dave!

On Wed, Nov 4, 2015 at 10:27 AM, Dave Brown notifications@github.com wrote:

The PyNIO license has been rewritten as a standard 3-clause BSD license. Hopefully this satisfies all concerns.

http://www.pyngl.ucar.edu/Licenses/PyNIO_source_license.shtml

We will put it on the github page when it is made public.

On Thu, Oct 29, 2015 at 2:40 PM, Stephan Hoyer notifications@github.com wrote:

I agree that the license seems complaint with OSI guidelines, but nonetheless it isn't an OSI approved license. These FAQ entries seem relevant: http://opensource.org/faq#approved-licenses-only

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152312224.

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-153820521.

The PyNIO license has been rewritten as a standard 3-clause BSD license. Hopefully this satisfies all concerns.

http://www.pyngl.ucar.edu/Licenses/PyNIO_source_license.shtml

We will put it on the github page when it is made public.

On Thu, Oct 29, 2015 at 2:40 PM, Stephan Hoyer notifications@github.com wrote:

I agree that the license seems complaint with OSI guidelines, but nonetheless it isn't an OSI approved license. These FAQ entries seem relevant: http://opensource.org/faq#approved-licenses-only

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152312224.

OK I'll pass along that information.

On Thu, Oct 29, 2015 at 2:40 PM, Stephan Hoyer notifications@github.com wrote:

I agree that the license seems complaint with OSI guidelines, but nonetheless it isn't an OSI approved license. These FAQ entries seem relevant: http://opensource.org/faq#approved-licenses-only

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152312224.

I agree that the license seems complaint with OSI guidelines, but nonetheless it isn't an OSI approved license. These FAQ entries seem relevant: http://opensource.org/faq#approved-licenses-only

I was just informed that "our lawyers looked it over and said we're OSI compliant."

Specifically "He compared the wording of both ours and the BSD one that you referenced, and said they are about 98% similar. The other 2%, which is something that's in the BSD that's not in ours, doesn't cause our license to be non-compliant."

Do you think this works? I do think we should fix the bad link to GRIBEX and point to the current ECMWF license. -dave

On Thu, Oct 29, 2015 at 2:16 PM, David Brown dbrown@ucar.edu wrote:

We are looking into our options on this. I know there were NCAR legal people involved in producing the current license. Hopefully given the current environment we will be to put it into a standard form that clearly meets the OSI requirement.

On Thu, Oct 29, 2015 at 11:14 AM, Filipe notifications@github.com wrote:

but it would be nice to be able to say that you use a standard license

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152253168.

We are looking into our options on this. I know there were NCAR legal people involved in producing the current license. Hopefully given the current environment we will be to put it into a standard form that clearly meets the OSI requirement.

On Thu, Oct 29, 2015 at 11:14 AM, Filipe notifications@github.com wrote:

but it would be nice to be able to say that you use a standard license

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152253168.

but it would be nice to be able to say that you use a standard license

:+1:

Actually I looked a little more carefully and the PyNIO license is not quite BSD -- the disclaimer of liability at the bottom is different. It looks like it's actually taken from the MIT license, with a few words copied from BSD: "INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES".

In any case, both MIT and BSD are OSI approved with similar restrictions, so I'm sure this license is also fine. I have not idea if this license is original to PyNIO or not, but it would be nice to be able to say that you use a standard license -- it makes this stuff a bit simpler.

Aside from the notice at the top "PLEASE READ THIS SOFTWARE LICENSE CAREFULLY" the license is ~~direct~~ almost exact copy of 3 clause BSD. It would be great to get this in the readme (once you're on github) to make this entirely clear.

The link for the license to GRIBX no longer works on the ECMWF website. But some googling turns up source files with the Apache 2.0 license attached, so I think we're in the clear (Apache 2.0 is BSD compatible). In any case, it should be in the PyNIO source code. For easier reference, it would be better to copy in the text of any referenced licenses in the PyNIO license itself, though.

OK thanks for the info and the doc suggestions.

On Thu, Oct 29, 2015 at 10:37 AM, Stephan Hoyer notifications@github.com wrote:

Aside from the notice at the top "PLEASE READ THIS SOFTWARE LICENSE CAREFULLY" the license is direct copy of 3 clause BSD. It would be great to get this in the readme (once you're on github) to make this entirely clear.

The link for the license to GRIBX no longer works on the ECMWF website. But some googling turns up source files with the Apache 2.0 license attached, so I think we're in the clear (Apache 2.0 is BSD compatible). In any case, it should be in the PyNIO source code. For easier reference, it would be better to copy in the text of any referenced licenses in the PyNIO license itself, though.

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152240832.

Good question. I don't know. I do know it was intended to be as open as BSD, but I will need to research further what the actual situation is.

On Thu, Oct 29, 2015 at 10:03 AM, Filipe notifications@github.com wrote:

The license here: http://www.pyngl.ucar.edu/Licenses/PyNIO_source_license.shtml

@david-ian-brown https://github.com/david-ian-brown sorry for my ignorance but is that OSI approved http://opensource.org/licenses?

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152226596.

The license here: http://www.pyngl.ucar.edu/Licenses/PyNIO_source_license.shtml

@david-ian-brown sorry for my ignorance but is that OSI approved?

The license here:

http://www.pyngl.ucar.edu/Licenses/PyNIO_source_license.shtml

On Wed, Oct 28, 2015 at 3:51 PM, Stephan Hoyer notifications@github.com wrote:

@david-ian-brown https://github.com/david-ian-brown What license are you using for PyNIO? It looks like https://www.pyngl.ucar.edu/Licenses/PyNIO_source_license.shtml a standard 3 clause BSD? This would be helpful information to highlight on the new GitHub site -- I could only finding it by searching google, not by navigating on the website.

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-152005733.

@david-ian-brown What license are you using for PyNIO? It looks like a standard 3 clause BSD? This would be helpful information to highlight on the new GitHub site -- I could only finding it by searching google, not by navigating on the website.

Thanks @david-ian-brown! That is good news!!

Hi Filipe, We will be making the pynio github site public soon, and I will update the PyPI information when that happens.

On Wed, Oct 28, 2015 at 3:51 AM, Filipe notifications@github.com wrote:

Maybe we could get ioos to also keep a pynio conda build up to date (cc @ocefpaf https://github.com/ocefpaf)

@david-ian-brown https://github.com/david-ian-brown is pynio open source now? If so I can add it to the ioos channel, but at PyPI it is still missing the source.

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/pull/636#issuecomment-151783551.

Maybe we could get ioos to also keep a pynio conda build up to date (cc @ocefpaf)

@david-ian-brown is pynio open source now? If so I can add it to the ioos channel, but at PyPI it is still missing the source.

Thanks again @david-ian-brown for your help with this. We've already been finding being able to use xray with pynio to be quite useful -- being able to read grib files is a killer feature.

@shoyer - This looks good to me.

@david-ian-brown - updating the conda channel shouldn't be a problem when/if that comes to be. Maybe we could get ioos to also keep a pynio conda build up to date (cc @ocefpaf)

Great! Just FYI, the conda channel name will almost certainly change soon to something more representative of NCAR. I will let you know when that happens. Thanks for working with us on this.

Good call. I added a small section to Serialization & IO:

I think this may benefit from some documentation, both in Serialization and IO and in open_dataset.

OK, great -- the units tests are now passing on travis, using numpy 1.9. There's no particularly good reason why we aren't testing against numpy 1.10 -- it just happens that I arbitrarily decided to test cdat-lite with the same build, and it only supports numpy 1.9 or older.

If there are no objections I'll be merging this shortly.

Hi Stephan, So in this message: RuntimeError: module compiled against API version a but this version of numpy is 9 the "a" actually means 10 in hex I suppose.

I see that I need to do more thorough testing. My latest builds have all pulled in 1.10.x by default. I did put some NumPy specific versions up on the conda site before 1.10 was released. Maybe I need to make all the builds I do numpy (and python) version specific. I'll get a new 1.9 version up today.

@david-ian-brown This is working for me on OS X, but I'm getting an error when I attempt to import your conda build of pynio on Linux:

```

import Nio RuntimeError: module compiled against API version a but this version of numpy is 9 Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/export/data/envs/test_env/lib/python2.7/site-packages/PyNIO/Nio.py", line 83, in <module> from nio import * ImportError: numpy.core.multiarray failed to import ```

Can you reproduce this? I think this is an ABI compatibility issue (ugh!) related to building against one version of numpy but installing another. To that end, it's probably worth trying specifying specific numpy requirements.

There were a few other issues that came up here that I'll note in specific comments on the code.