I have been playing around with Ignition and am admittedly pretty impressed.
As Ignition is based on Java, it's theoretically an ideal candidate for using our PLC4X Java drivers, which could add a number of very interesting protocols to Ignition.
However we can only add an Ignition module to PLC4X, if the libraries needed to compile the code are available under a permissive license. I did try searching this forum for "License" but I was swamped with results that were unrelated to my question. So please forgive me, if this has been asked before.
So I guess I would need to know which license the libraries are released under, that we would need to depend on in a PLC4X integration module.
If the licenses are not permissive, then such a module can't be provided by Apache PLC4X and would have to be a separate effort done outside of the project.
@PGriffith or @Kevin.Herron from IA or @pturmel integrator and provider if thrid party modules and PLC drivers could certainly provide you accurate information about this topic.
I would assume that the license of Ignition itself will most definitely and totally understandably not be a permissive license. However the APIs and modules we would need to add as dependencies could theoretically be totally open-soucrced and accompanied with a permissive license.
Also are regular vendors of third party software usually not affected too much by non-permissive licenses. However at Apache we have very strict rules regarding licensing.
I see the archetypes are Apache 2.0 licensed, which is perfect. The maven plugin however has no license attached and therefore the default GitHub License applies, which is not compatible with Apache, as I remember. Same applies for the module-signer.
The maven artifacts in the groupId com.inductiveautomation.ignitionsdk don't contain license information inside them, so I am not quite sure which license they are distributed under.
I hope you now better understand my question.
The problem is: If we can't build a PLC4X module for Ignition inside Apache, then I will not want to do this as open-source (as I would not be under the legal shield of Apache and I have had threats from the side of the automation industry in the past, that I am not willing to risk anything) ... so it would only be a commercial product in the other case. (I'd love to do it as open-source though)
Here's a link to the Apache license policy:
The Ignition SDK API artifacts are not open source nor permissively licensed (though... I don't know what license these are intended to be available under, but the source is not available). They're only referenced as "provided" scope, though, if that makes a difference. They're not included in the module file that gets built.
The module-signer project could be given an open source license.
I've taken the matter to our legal department ... even if I'm expecting to get a "NO" from them, I still think it's worth asking, because this situation is different in one important aspect: It's not about including Ignition code into PLC4X but generally the other way around. So possibly it even could be ok. But I'm not expecting it to be.
There should be no issue including PLC4X code in an Ignition module because the Apache license allows it.
I think the question is whether you can claim an Ignition module you develop is Apache licensed, and without a license (compatible, or at all) on the API dependencies I'm not sure that's allowed. Certainly not as an official Apache project, which I'm guessing has strict IP validation requirements the same way Eclipse does.
Yeah ... that direction is not a problem.
Just implementing a module that "references" proprietary code as part of an Apache project might not be possible. If they give me a "No", then the only option is to build something outside of Apache that uses PCL4X.
So excited to see new native driver in Ignition ..
good news ... so It seems I've received a green light from Apache. Another something I've learned, even if I'm working on Apache open-source for 20 years now
So as soon as I'm finished with the Apache IoTDB/TimechoDB Historian and probably after the next Apache PLC4X release, I might start working on this.
I really hope this is not going to take too long to build the Historian ... admittedly this part of the SDK is slightly "underdocumented"
Hello, Kevin. We are designing a pacing mechanism project for our line which will be like a visual stopwatch for the product being built. It will give our operators a visual of the cycle time. Can the sdk add more functionality to our project, any suggestions?