Good Friday everyone!,
I have a dumb question regarding Patenting. We have a few applications made using Ignition Perspective. Is there anyway we can patent our designs or any part of the projects? Please share your experiences.
Legal advice from Inductive Automation Staff will be highly appreciated!
Thanks
Riddhish
Yeah.... no. Not our place.
Come on, what's the worst that can happen? Get sued and lose your house? Oh wait...
sorry didnt understand your response.
If you want legal advice then you should ask a legal professional.
whats your take in general?
Patents shouldn't exist.
Meh. I prefer 20-year patents over life+99 year copyrights. I'd knock them both down to 10 years, if I was dictator for a day.
wish we could protect our scripts too somehow!
You can, just write them really really poorly or obscurely 
then anyone with half a brain won't use them at all, and probably won't touch the rest of your project either. Win win! 
But if the script does have a value in it that they find it useful, then definitely they would like to use a working piece of code , (however obscure or poorly written it may be) , and use their brain to decipher it and modify and reuse it ! It's becoming increasingly difficult to write modules in Ignition with its ever changing API's its like chasing a moving target . It's easier and safer to achieve results of a module using scripts. If they are not protected we lose our know how to people using them.
[citation needed]
8.1.0 was released November 2, 2020. We've committed to a stable API [1] since that date, and 8.3.0 won't be released any earlier than the end of this year. You absolutely can write a module today that will work with every released 8.1 version and will continue to work with every future 8.1 version [2].
As a tangent: It's essentially impossible to deliver code to end users to run on their machines that they can't ultimately decipher. If it's run on the JVM, it can be trivially decompiled, and the best you can do is obfuscate it, but the bytecode is still legible. If you jump through hoops to deliver native code...you can still decompile it, and reverse engineering compiled native binaries is extremely common. There is no such thing as a free lunch - even if you could somehow perfectly guarantee a black box system to end users, they could duplicate it by watching what happens with given inputs and outputs and reverse engineer any business logic that way. Focusing exclusively on "protecting source code" is the wrong avenue. Deliver value with updates and support.
No offenses implied, but APIs did break significantly from Pre to post 8.0 era, which was natural for a major version change. Writing scripts to achieve our goals was much easier and safer with its comparatively smaller and well thought out and simpler script library which didn't significantly change between versions of Ignition, they only added new ones without breaking the old ones. Hence I found scripting approach way to achieve your objectives.
Any byte code or intermediate code and of course intrepreted code (except for a compiled binary code) can be deciphed if one really wants to. The objective is not to prevent its use, in fact we will be glad if community can benefit from it but it was just to ensure some kind of reward or recognition or an acknowledgement rather than thankless job.
I strongly disagree. I've been writing modules for Ignition since 2015 (v7.7). Most of my modules simply needed recompiling for later Ignition versions, and the most popular (NoteChart and Simulation Aids) could use the same module file in v7.7, v7.8, and v7.9 at one point.
v8.0 had OPC changes that required some shuffling in my drivers, but IntelliJ made short work of that.
The coming v8.1 => v8.3 upgrade looks like the "worst" yet, but that will mostly be due to ripping out Wicket. ( Unqualified Yay! )
The bottom line is that there is a tradeoff between jython and java in Ignition: one is easier to deploy and the other is better for concealing your intellectual property. Wishing to have your cake, and eat it too, is all you've said here. And for structural reasons that I don't see changing, it will never be more than a wish.
Sounds like a great way to inhibit innovation. Why would anyone invest large amounts of money and time that it takes to create something that someone else can just copy when you are done?
Patents are necessary. But there should be limits for sure.
What if they could make it better, cheaper, etc.? As a consumer I'm for that.
Modules are certainly more efficient than scripts but I had done only one module development in Ignition 7.8 or 9 which was an intimidating experience for me with a possibility of causing memory leaks and system crashes especially if one's not confident with the understanding of API's. It may be easier for those who grew up with Ignition but a steep and uphill task for lateral entrants like me. I don't know how many people have developed modules for Ignition with deep integration with its API's. I found Script route easier and more pragmatic for simpler tasks. With scripts we integrate our applications with Ignition at an arms length without having to build any modules to integrate. Module development has remained a pipe dream and an eye wash for me! That may not be the case for everyone of course, just my experience.
I also believe days of third party application integration thru builds and APIs are numbered with REST API approach paving the way for it.
I disagree. As we have over 80 public and private modules developed over a 15 year time span, modules are getting easier to develop and maintain.
I totally agree with your disagreement as expected. IA at least provides the sdk with a possibility for module development. Which other SCADA platforms do! However the API's expose us to the bare metal of Ignition which is quite risky in my opinion unless you are trained on them or you have spent a lot of time to understand them properly or you work in close cooperation with IA. Of course risk is yours and gain is yours is the philosophy here and it depends on how strong is your motivation to learn these API's.
My point is, the SDK does not provide a sand boxed environment for module development with a handful of well planned and documented API's such as the Scripting library does. Even if the Scripting library was converted to a JAVA callable function library I think we would been happier, safer at the same time would have been able to develop our modules faster, version agnostic, more efficient (than scripts) and secure (from IP protection point of view which is the main topic of this discussion).
Possibility of adding our own modules to Ignition and add our own billion dollar worth modules to it is the most attractive value proposition of Ignition that attracts many Integrators including me. However it took me almost 10 years to achieve my first 0.0 th billion dollar business in modules!
There have been enthusiastic posts on the forum asking for a tutor or asking for guidance in module development as if a simple concept is holding them back. How far did they reach with their goals despite equally enthusiastic attempts by IA and others to explain module development to them.
Of course IA has better things to do than provide sand boxes to module development environment, but perhaps it would be desirable to think on those lines starting with Scripts like JAVA library for module development. (not sure if it makes sense, but just a thought, call it a discussion or ignore as a rant)
That might be a superlative too far. IA says you are on your own with the SDK. Some SDK questions are answered on this forum, but others are not. I share some things here for free, and charge $$ for more comprehensive consulting.
So, the enthusiasm is for the value of learning the SDK, even if difficult and possibly lonely.