Using smooks UN/EDIFACT sources - please add license

[Christian Ciemniak]

Dear Everyone

We would like to use the UN/EDIFACT bindings and mappings.

Problem is, no license is provided, thus all rights are with the author and no permission to use them has been granted.

At least for the bindings (e.g. d07a-binding-1.7.1.0.jar or https://mvnrepository.com/artifact/org.milyn.edi.unedifact/d07a-binding/1.0) the repository seems to be 

https://github.com/smooks/unedifact

The mappings (e.g. d07a-mapping-1.7.1.0.jar or https://mvnrepository.com/artifact/org.milyn.edi.unedifact/d07a-binding/1.6) I am not sure of they come from the same repository.

I know the repository is archived and no longer maintained. Do you see any way possible to add a generally accepted open source license to the mapper and the bindings? If no license is supplied, we assume the following is valid:

https://opensource.stackexchange.com/questions/1720/what-can-i-assume-if-a-publicly-published-project-has-no-license

If a repository has no license, then all rights are reserved and it is not Open Source or Free. You cannot modify or redistribute this code without explicit permission from the copyright holder.

Is a license in any way possbile for anyone of you? At the moment I am allowed to see the sources but not to use it.

Thank you for your help,

Christian

[Claude]

Welcome to the forum Christian. The repository is archived because those bindings are for Smooks 1. For Smook 2, we've revamped the EDIFACT cartridge to leverage DFDL so those bindings have been replaced with DFDL schemas. However, I glanced at the generated schemas and some of them don't include the license header. We'll be sure to add them in the next milestone release.

Claude

[Claude Mamo]

I created an issue: https://github.com/smooks/smooks-edi-cartridge/issues/51

Claude

--
You received this message because you are subscribed to a topic in the Google Groups "Smooks Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smooks-user/qWq_sSfLp6c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smooks-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/985a4901-733f-4b15-9036-547f9b15d232n%40googlegroups.com.

[Christian Ciemniak]

Hi Claude

Thank you :-)

But smooks 2 is in a pre-release state, right? And smooks 1 has missing licenses and parts of it are unmaintained. 

We start a new project right now, and we have to read DELFOR messages and write DESADV . 

 

This will be a big big project and it feels courageous to build it on a pre-release version of smooks 2.
And building it on top of smooks 1 seems even illegal because parts of smooks 1 have no license. Without license is the above mapper, the bindings and the before unmentioned 'javax.transaction:jta:1.1' which is a transient dependency of smooks 1.

What would your suggestion be?

[Claude Mamo]

Not familiar with the jta license but you can always exclude it from your project's POM if it doesn't break the application. I can't comment on what you're attempting is actually illegal; I would consult with a lawyer if it was me. Keep in mind though that Smooks 1's overall license (LGPL v2.1) limits you considerably in terms of modifications while Smooks 2's dual-license (Apache License & LGPL v3) is much more permissible. 

I would have to know more about the project before I can give a suggestion. The next milestone release will bring major breaking changes to the Java API but your team should be more or less insulated from these changes if they stick to the XML. It's even possible that you might not need Smooks and Apache Daffodil (the library powering the EDIFACT cartridge) is sufficient for your requirements.

Claude

On Thu, Sep 10, 2020 at 2:57 PM Christian Ciemniak <christian...@gmail.com> wrote:

Hi Claude

Thank you :-)

But smooks 2 is in a pre-release state, right? And smooks 1 has missing licenses and parts of it are unmaintained. 

We start a new project right now, and we have to read DELFOR messages and write DESADV . 

 

This will be a big big project and it feels courageous to build it on a pre-release version of smooks 2.
And building it on top of smooks 1 seems even illegal because parts of smooks 1 have no license. Without license is the above mapper, the bindings and the before unmentioned 'javax.transaction:jta:1.1' which is a transient dependency of smooks 1.

What would your suggestion be?

Christian

On Thursday, September 10, 2020 at 1:43:21 PM UTC+2, Claude wrote:

--
You received this message because you are subscribed to the Google Groups "Smooks Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smooks-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/e93217e2-f48b-4c58-b420-794f9a679bbfo%40googlegroups.com.

[Tom Fennelly]

I think it's important to not confuse LGPL and GPL.

But anyway, in Christian's first email on this thread he linked to this stackexchange article that said "... without explicit permission from the copyright holder".

I see no reason why we can't give such "explicit permission". We just need to figure out what is the right way to do that.

T.

To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/CADvAAugOn16hS66b7vUuGspns3OrO9_7CCRbOH%3DbHq6qxywgoA%40mail.gmail.com.

[Claude]

The "right way", assuming that the copyright holder is each individual who contributed code to the EJC module, is for Christian to contact each contributor and request their explicit consent.

Claude

[Tom Fennelly]

Fairly sure I did all of that EJC stuff, but if there were others involved it would only have been one or two people (maybe Bard or Renat) and I know they would have no issue giving consent.

To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/abb51986-39fb-4fc1-a176-18528b2414den%40googlegroups.com.

[Christian Ciemniak]

Hi Everyone

Thank you very much for your support :-)

We had further discussions about how to handle that. Generally we would like to use smooks for EDIFACT parsing. We will probably migrate to 2.0 once there is a stable release, but we would like to start development with the current version.

The main problem are the missing licenses, as mentioned. While the transient license of jta seems to be resolved (license texts are in the individual files instead of a common license header) the issue remains with the UN/EDIFACT module. You offered to give us explicit permission, which is very, very much appreciated. 

This is probably how that would work: We dig out some standard text that allows us and any organization that is the legal successor of this organization full commercial use. We would UPS that to everyone of you, including an envelope that you can UPS it back to us. And for this we should probably move the conversation to a more private place :-)

But this is probably a bit of undesired work for you, but if all other options fail and if you would do this for us then I'd like to come back to you for this. 

But we would also like to offer an alternative, which we consider to be the preferred way:
We do a pull request for the license texts in the unedifact repo. To my understanding you would have to un-archive the github repository, we do the pull request(s) with your preferred license ( Apache-2.0 OR LGPL-3.0-or-later ??? ), you would review and approve the PR and archive the repository again. After discussion here we believe that you would not have to re-publish to maven since we can link the versions that are currently published to maven back to the repository and since no other things will have been touched than the license texts.

Do you think that this proposal might work?

Thank you very much for all your work,

Christian

To unsubscribe from this group and stop receiving emails from it, send an email to smook...@googlegroups.com.

[Claude]

I'd say that you would be breaking at least the Apache license if you add the license text to the repo but don't include it with the binary distribution:

"You must give any other recipients of the Work or Derivative Works a copy of this License"

In other words, if I'm understanding the above clause correctly, you must re-publish the binaries to include the license (in the META-INF directory?). I think it would be easier for us if you fork the necessary repos, add the licenses to the forked repos, and then publish the binaries incorporating the new licenses to Maven coordinates of your choosing. You are already have permission to license Smooks under Apache-2.0 OR LGPL-3.0-or-later as per https://groups.google.com/g/smooks-dev/c/vM6JzPmICEY.

Claude

[Christian Ciemniak]

Hi Claude

Maybe you are right right regarding the inclusion in the binary distribution. It was our experts opinion that legally we are safe with the combination of this google groups conversation and the license added to the github repository.

However I am rather sure that we can not fork the repository since without any license allowing that it is not legally possible. Otherwise I could just fork any code and add a license of my choosing. At the moment I am only allowed to see the code, but nothing else.

Thank you for your continued support,

Christian

[Claude Mamo]

I'm no lawyer as I said earlier but this is my two cents. You can't use or distribute the code because it's not licensed or, at least, not correctly. You do not have permission to add a license of your choosing to the fork because the code contributors did not give you such permission. However, you do have permission to license the code under Apache-2.0 OR LGPL-3.0-or-later because said permission was given in https://groups.google.com/g/smooks-dev/c/vM6JzPmICEY. It doesn't matter who adds the license text just as long as it's included in the right places in order to comply with the license/s.

Claude

To view this discussion on the web visit https://groups.google.com/d/msgid/smooks-user/d195aeb3-c235-4926-a430-9ad8a67bf7cdo%40googlegroups.com.