-
Notifications
You must be signed in to change notification settings - Fork 6
No license defined #1
Comments
The original GENIA tagger appears to be under this license
Does this license also apply to your Java code? |
Hey. Thanks for your interest in the library. As for the license, I would apply an independent license than the original GENIA's, since the code is a total rewrite and some other parts have changed since the translation from c to java. However, the binary models, which are not distributed within the source, are exactly the original ones and should be be accompanied the GENIA's license. I would like to make In any case, I would say that the state of the library is still quite premature for submission to maven central. Some aspects of the API should be better defined. Can I know for what purposes do you use |
I am one of the developers of the open-source DKPro Core collection of components for the UIMA framework (http://code.google.com/p/dkpro-core-asl/). We are always on the look for NLP libraries that can be integrated into the collection. Our aim is, to make as many NLP tools as possible useable as uniformly and conveniently as possible. While we are Java-based, we also do integrate some tools that are using native binaries. However, if there is a Java-port available, we'd much prefer to try that. We are targeting mainly researchers and we are not a commercial project. However, we chose to be liberal and use the Apache Software License 2.0 (ASL) for our code as much as it was possible (not possible for some GPL tools that we integrated). So this is why I ask, because we may attach a warning to components that have specific restrictions beyond what the ASL defines. We also make a point of distributing all transitive dependencies of any integrated NLP tools via Maven Central, so we often get into contact with tool and library providers to determine if and how this can be done, if they want to do it, or if we do a third-party upload. I think some changes with respect to the API would also be useful for jeniatagger to be integrated as a library. E.g. the JeniaTagger class contains many static methods that would better not be static. There are many private, or package private methods that we could well use to circumvent the problem of static methods and lack of certain convenient API methods. It would be useful if the loading of models could happen either by passing InputStreams into jeniatagger or by loading the models externally from whatever source we like, and then pass the model classes into the tagger. That would allow us to package the models as JARs and load the models from the classpath. If it is not clear in which extent the original license may apply to the current code (I believe some parts were basically transcribed from C++ to Java), it might be useful to bring this up with the original author, make a suggestion, and make sure that the author agrees. I believe this would be necessary if there was interest to remove the "non-commercial" restriction. Otherwise, the GENIA tagger license is pretty liberal and requires only the original license text and copyright statement to be maintained - which appears easily doable. I am not a lawyer, though. |
I see. I'm interested. I already contacted the original author some time ago, and had his OK in releasing the java jeniatagger version. I will contact him again to clarify if we also have his blessing for this. As for improving the code and formalizing the API, I totally agree. The new applicability that you propose gives me a better push to complete this. |
After a long time... any news on this? |
Thank you Richard, I just contacted the original author. A priori, I would like to license the Java code using the Apache Software License 2.0 and distribute the original binary models with the original license. If I receive his blessing, I will make the necessary changes to be able to distribute the binary models as packages. As for the API changes, I don't have time now, but I register the issue on #2 |
What is the license of this code? I consider deploying this project to Maven Central, but this is not possible without knowledge about the license.
The text was updated successfully, but these errors were encountered: