Using fsnotify in core, license and CLA

[Nathan Youngman]

fsnotify is a library for file system notifications created by Chris Howey using code from golang.org/x/exp. It isn't the only Go library in this space. For the history, please see: https://fsnotify.org/history/

Over the years, various people have expressed interest in using fsnotify in the core Go codebase:

* godoc for reloading directory listings: https://golang.org/issues/3386

* cmd/go to speed up scanning for changed files: https://golang.org/s/go13fsnotify

* guru: Alan Donovan is interested in file system notifications to make guru more responsive

* os/fsnotify in the standard library: https://golang.org/issues/4068

My first question is whether or not there is still interest in using fsnotify specifically, or file system notifications in general, for each of these areas.

For the fsnotify library to be used in any of these places, it needs to be under the Google license and CLA. 

However:

"The CLA is an agreement between the contributor and the project maintainer. Since Google is neither of those, we wouldn't actually be party to the agreement, so I'm not sure that using the Google CLA makes sense." - Will Norris

The license and CLA situation has felt awkward to me for some time. Should fsnotify become a Google project like grpc-go? Should the license and CLA change?

This is something I hope can be resolved in the coming weeks, though of course I understand that rolling out Go 1.8 is at the top of everyone's mind right now.

Related issue on fsnotify: https://github.com/fsnotify/fsnotify/issues/193

Nathan.

[Nathan Youngman]

Is there any feedback on this concern?

[Brad Fitzpatrick]

If it's going to be used by official Go tools, it needs to be CLA clean and license compatible.

We could move it to be github.com/golang/fsnotify or something probably if you can verify all the authors in the history have done the CLA, and then hook up the CLA bot. But we'd probably just use Gerrit at that point.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathan Youngman]

That is the big question. 

If there is no longer any interest in using fsnotify (at least this particular codebase) in core, then it should probably have a license and CLA that reflects it not being a Google project. That may be the best option right now, as we can always do a clean implementation later based on the learnings from fsnotify.

On the other hand, I'm certainly willing to do the legwork to ensure the CLA has been signed by everyone, so long as we have a CLA bot that ensures it continues to be the case.

As far as the location and use of Gerrit, that's fine by me, though I would want to confirm with the other contributors. I'm also not sure if the location should matter:

https://github.com/golang/go/issues/17244 (proposal: decide policy for sub-repositories)

We have multiple repositories right now, including FSEvents on macOS, so moving to something like golang/fsnotify would involve merging these into an fsnotify monorepo. That's probably a good move in the long run.

Cheers,

Nathan.

[Brad Fitzpatrick]

The license is not Google-specific. You can choose any license that is compatible with Go.

The CLA is Google-specific, but it's fine to just mention that the reason you require the Google CLA is because Go does, and you intend or want to be able to get the code into Go in the future. That's what go4.org says (https://github.com/camlistore/go4/#details).

[Nathan Youngman]

That sounds reasonable to me Brad, and is essentially what fsnotify is doing now, though your wording for Camlistore is better.

I would still really like the Google CLA bot in place to ensure that myself or other committers don't forget the CLA. It's too easy to let it slip. Would that be okay Will?

Thanks,

Nathan.

[Brad Fitzpatrick]

He could ping me or other Gophooglers to debug?

On Wed, Feb 8, 2017 at 12:44 PM, Will Norris <wi...@willnorris.com> wrote:

My concern is what happens when the automated checking fails (which it does more often then I'd like, and we're working to reduce that).  We have internal tools to help debug that, which you won't have access to.

[Will Norris]

My concern is what happens when the automated checking fails (which it does more often then I'd like, and we're working to reduce that).  We have internal tools to help debug that, which you won't have access to.

[Will Norris]

Sure, I just didn't want to volunteer you :)