gjoseph / BarbaryWatchService

An implementation of Java 7’s WatchService for OS X
41 stars 10 forks source link

Software License #6

Closed robertroeser closed 2 years ago

robertroeser commented 9 years ago

Hi,

What is the software license that you are using for this project?

Thanks, Robert

gjoseph commented 9 years ago

Sorry it took so long to get back to you Robert.

The v1.0 version is a hodgepodge of licenses, with code borrowed from OpenJDK which is licensed under the GPL.

For v2, in which I'm hoping to bring Java7 interoperability, I'm not still not sure - I might have to resort to copy code from OpenJDK as well (private APIs), which means it'll have to stay GPL. If not, then I'd like to pick a more permissive license.

Did you have any particular concern about this ?

robertroeser commented 9 years ago

Hi,

No problem. I'm hoping to include parts this in RxJavaFileUtils. The library is Java 8 but so I don't need the JDK pieces necessarily, but the parts you wrote to work with OS X are really interesting - the java file watcher doesn't very well on a mac without it. The license for RXJava is Apache so I was kind of hoping for something like that.

I basically forked the code, and replaced references to copied JDK code with imports except for the internal packages https://github.com/ReactiveX/RxJavaFileUtils/tree/master/src/main/java/com

Thanks, Robert

jvanzyl commented 8 years ago

I have been using an older version of this utility for quite a while in a Maven Shell I have made, but one of the reasons I can't release is the license of this project. If we can move to Java 7/8 can most of the Oracle specific files be removed? Additionally we can offer the code to the JDK team, maybe they would integrate it into the JDK.

Another idea is that a separate interface is made for this project and people can adapt it into JDK APIs if they wish. Almost everything I work on is ASL 2.0 or EPL 1.0. But it would be hard sell for Maven to be ASL 2.0 and a Maven Shell be GPL. File watching is really only efficient with this utility. It really makes a huge difference. I'm happy to help sort out the licensing.

lhotari commented 8 years ago

@jvanzyl https://bugs.openjdk.java.net/browse/JDK-7133447 is the JDK bug. Email thread on nio-dev mailing list http://markmail.org/thread/p6zd4svwqo32nu57

jvanzyl commented 8 years ago

Doesn't look like a very high priority so I'll propose the changes I've been using locally for the last couple weeks. I'd love to release the Maven Shell but not without this capability.

gjoseph commented 8 years ago

@robertroeser , @jvanzyl ,

the parts you wrote to work with OS X are really interesting I can't take credit for that, Steve McLeod did, I just merely made sure the project got into Maven Central.

Hopefully I can take some credit for the next update, but I'm struggling with this licensing decision. Ideally, I'd like to stay away from GPL and use something more permissive (and simple) than gnu+classpath. But that probably means looking at alternatives (last I checked, jimfs reimplemented AbstractWatchService and others on their own, which is likely licensed under a more permissive license, and thus more interesting here), and/or splitting out the copied-from-jdk code into a separate module to clarify the situation. Or use a giant hack to somehow extract/copy/subclass those classes without having them "physically" in this codebase.

jvanzyl commented 8 years ago

I was going suggest for the time being that we make another similar abstraction for file watching. Make the OSX code here implement that and then adapt the JDK implementations to our interface. But I've looked at Jimfs and they have ASL licensed versions of these files but I'm not exactly sure how that's allowed. Let's ask them and see if they've thought about this issue. I would assume they have as the Google copyright is on the code. If their code is accurately licensed then it can be used here and I believe that will solve the issue.

jvanzyl commented 8 years ago

Ok, I started by writing some tests for the original implementation which look something like this and then I integrated some code from Jimfs to remove all the OpenJDK source files. I used the same test to make sure the new implementation works. I only care about Java7+ and the listening mode of operation. I don't use Java6 anymore but I can probably make this work with Java6 if anyone cares that much. I'm going to add some more tests and clean up the code and then I'll submit a PR. At that point I think we can safely publish it under the ASL 2.0. I talked to the author of Jimfs and it's all it's clear all of Jimfs is ASL 2.0.

gjoseph commented 8 years ago

Hey Jason,

Yes, removing dependency on Java 6 is the intention. I started working on that a while ago, but got stuck writing reliable and consistent tests. It's cool that we can use the Jimfs stuff. Any chance the discussion with the Jimfs guys was public, so we could also refer to it here ?

jvanzyl commented 8 years ago

What I have is working. Didn't do much this weekend but I'll write a few more tests and then make a PR for an initial version that is Java7, a newer version of JNA which is dual license ASL and LGPL, and has no source code from the JDK.

Arcnor commented 8 years ago

Did you ever got around to clean that code @jvanzyl ? I'd like to use this project, but the GPL license is a bit of an issue :)

jvanzyl commented 8 years ago

I did. I have a completely clean version. Been on vacation so I'll try and push it somewhere this week.

Arcnor commented 8 years ago

Awesome, thanks @jvanzyl !

fommil commented 8 years ago

The really annoying thing about the OpenJDK licence is that it's GPLv2 but not compatible with GPLv3. It's got the classpath exception though so as long as it's a runtime dependency it shouldn't affect anybody unless you want to bundle assembly jars.

What licence are you using in the clean implementation?

jvanzyl commented 8 years ago

Here is the all ASL licensed version that I created which also tries to abstract the differences between Linux and Windows. But the watcher code needed by the OSX version is taken from the cleanroom JimFS implementation from Google.

https://github.com/takari/directory-watcher

jvanzyl commented 8 years ago

License and headers are all updated now over at https://github.com/takari/directory-watcher

gjoseph commented 8 years ago

Hey Jason,

I don't have much time to devote to the project anymore - moved across the globe somewhat unexpectedly right after i took it over - which is why I haven't been super responsive here. Do you want to PR your work into this one ? Happy to make you a contributor too.

jvanzyl commented 8 years ago

I think it might be easier to just point people at the new project. It's not just pulling the bits out of jimfs to remove the licensing problem but also provide something that behaves the same across OS X, Linux and Windows which is surprisingly annoying.

mdedetrich commented 6 years ago

@gjoseph @jvanzyl Is it possible to merge the PR in the meantime (as long as there is no confusion with the license?). There are projects like sbt which are looking to use this solution and it can't be done if there isn't clarity regarding the license

gjoseph commented 6 years ago

Oh man, I completely lost track of this, sorry :( @mdedetrich I don't think there IS a PR to merge here :/ Could sbt use @jvanzyl 's project ? (can't really call it a fork at this stage) Alternatively, happy to look at a PR from you and add you as a contributor if you're keen.

gjoseph commented 2 years ago

sorry for the slow response -- as you may have gathered, I haven't had capacity to maintain this project in a long time. I'm finally officially retiring it. I've listed https://github.com/gmethvin/directory-watcher in the README, which https://github.com/takari/directory-watcher is deprecated in favour of. Interesting, the former mentions being largely inspired by the latter, but the latter doesn't mention it was largely inspired by this repo here ;)