Hello everyone. We would like to share with you our free and open source cross-platform EEZ Studio. It is a visual “drag & drop” tool for creating desktop and embedded GUIs. Several types of projects are supported, including of course LVGL, which is why we decided to present it here.
EEZ Studio was created for the needs of quick creation of GUI and remote control for our open hardware projects (H24005 and BB3) as well as for test and measurement automation, so it can be used as an open source alternative for commercial solutions such as NI LabVIEW and similar.
EEZ Studio also enables flowchart-type visual programming (EEZ Flow), so that in addition to GUI design, it is also possible to create very complex program logic.
For more information, we invite you to visit our website www.envox.eu, and feel free to download EEZ Studio, which has over 40 templates and examples of simple projects in which various functionalities are used and you can try them immediately thanks to the simulator.
You can join our Discord for support. The project is actively developing, so your feedback and comments are more than welcome.
It looks like the project hasn’t had a release since 2021. with the release date being so old I cannot imagine it is up to snuff with the current releases of LVGL.
It looks very interesting and I have installed it to have a play with it. At first sight, I have to congratulate you on how good it looks, it must have taken a lot of effort to get to this point!
It does seem quite tightly integrated with your EEZ brand, the T&M instrumentation applications and your opensource hardware so I wonder if this could cause confusion for users of LVGL if it was to be promoted as the tool to use for creating GUIs visually…
It’s open source GPL3 though so a fork could be made so that it could be modified and branded to be focused only on LVGL but I wonder what your thoughts would be in this case? Is this something you would encourage?
Thank you for your comment and the time you spent evaluating EEZ Studio. It is true that EEZ Studio supports T&M and different project types (Dashboard for desktop applications and EEZ-GUI for embedded UI) but once you create and open LVGL project you are 100% in LVGL world.
It should be understood that EEZ Studio has all the necessary infrastructure to create ready-made templates for quick project creation, for example new project templates could be added to all LVGL certified boards so that new users can have a functional project in a few clicks. Likewise, EEZ Studio has the possibility of visual programming (aka Flow), and regardless of what hardcore programmers think about the low-code/no-code paradigm, it has the potential to attract new users to the world of LVGL and really accelerate the development of prototypes and functional applications. Of course, C/C++ developers do not need to use the mentioned Flow at any time.
A hard fork is always an option, after all, it’s in the spirit of open source, but it usually means dispersing resources and talent instead of increasing the team and pushing things even harder and faster. So if there is anyone interested in such a thing, it might be good to see what the options are. EEZ Studio cannot currently progress faster than it is because there is only one person working on it full time. If only some of the contributors who have worked on LVGL so far would join us, things would improve quickly. Maybe the existing contributors under the leadership of Gabor could create e.g. pull requests to implement it in EEZ Studio, which would then be up to date with all the features of LVGL. It is possible that NLnet (from which we have received donations several times) would be interested in financing all the involved parties and that the whole thing rises to a new level. Of course, this kind of discussion is not possible without Gabor.
It could not be forked by LVGL and altered to work with only LVGL. This is because the licensing is GPL3 and not MIT. an MIT licensed library/project can be added to a GPL3 project but a GPL3 library/project cannot be added to an MIT licensed library/project. It could not be forked and modified and distributed by LVGL it would be in violation of the licenses. This is the single largest downfall of using any of the GPL licenses. It’s basically a one way license.
This is where the biggest problem is. Because this program generates code the generated code must also carry the GPL3 license. This means that any of the code that is generated by this program MUST be open source and it cannot be sold. Here is why, there is no obligation of an MIT licensed program for it to be made public or open source or any of the code it creates to be made public and open source. The only requirement is for the license to be added to each source file. The GPL3 license prohibits me from taking someone else code and selling it as my own. Because a program generates the code I am not the author of said code so I would not have the right to sell that code.
GPL3 is too restrictive because of hardware manufacturers using LVGL for things like smart watches and other devices that would use it to create a UI. Most of these companies are not going to release the UI code for their devices as open source. It’s simply not going to happen.
Now here is the real kick in the ass. Because this software has already been released as GPL3 it cannot have it’s license changed to something else. This can cause all kinds of issues if someone has updated any of the code and those updates are released under the GPL3 license which is what they would have to be because of the restrictive nature of GPL3. If the program license changes to say MIT than any modifications that have been authored by a different person would have to retain their GPL3 license which would no longer have a compatible license. It poses a problem with code that has been written using this program as well because the previous code it has written would be under the GPL3 license and new code that would be written would be under the MIT even tho the written code is identical. That is a problem.
As far as I know EEZ Studio is not adding any license in the generated code - so author can set any license to generated code - probably regarding what libraries it is using.
regardless of whether or not you add it the code is generated by a GPL3 licensed application and by definition it will also carry the same license. it should be added in order to be in compliance if it is not there.
Licensing is a really fickle thing and it causes a HUGE amount of grief especially with GPL. This is why GPL has been falling out of favor and 70% of the open source code that is written uses MIT, BSD or similar licenses that are less restrictive.
personally I like this license.
Even tho I don’t drink. It is a license that cannot be “interpreted” it is written in plain English and there is no hidden meaning to anything.
When a public code is released under a permissive open-source license, such as LGPL, others may use the code without any license restrictions as long as there is proper attribution. But when an open-source licensed code is repeated as generated code by a generative AI tool, there may be copyright violation when the usage of such code does not follow the open-source license terms, such as attribution and distribution in a certain manner.
Because the generated code is statically written into the GPL licensed code it carries with it the GPL license. That is what it boils down to.
The compiler is using your explicit code to generate the binary so no. In this case the generated code comes from some other licensed code. You are not feeding in your code to get an output. That is the difference.
It’s all about where the output comes from. In the case of this program the output is generated using blocks of code this programs author wrote. It is not outputting code blocks the user has written. Not all of them anyway.
If I am able to take a chunk of the output code and search the source code for the exact same block and it is found then guess what? The output code has to be licensed as GPL3. It’s all about derived work.
Take this for example. Say I generate a UI using this program and I license the UI as MIT. and then another user uses the same program to generate what as a whole is a different UI but… It has code in it that is identical to what the first user has. This user has their code as proprietary and it is being sold. That is going to cause an issue.
If the program has the ability to generate code but the code it generates is not included with the main program and the user is able to supply say xml files that contain the code then whatever license the XML file has been given is what would be applied to the output code. In a situation like this the addition of a downloader built into the program that points to repositories on github or to a local drive path that contains the xml files then the xml files can be licensed differently if the xml files are being collected from an external source. So long as they do not come bundled with the program this can be done.
I think they know about that and code that is generated is not located in the studio itself.
But I do not know that much about what is in source.
I do understand that generating same code under different licenses could be problematic.
So maybe generated code really need to have some license that is less restrictive and not be without any license.
This is really uncharted territory and it’s something that is going to explode sooner or later. Githubs copilot is going to come under some serious fire pretty soon. This is because about 1% of the code it uses in it’s AI gets output exactly how it has been read. copilot reads all kinds of code to learn and it doesn’t care what the licensing of that code is. That’s a big ooops.
There is all kinds of information that can be read on the internet about this. Thetre is currently a class action lawsuit against Microsoft because of copilot doing this.
It’s not about the code coming from external files. The code CANNOT be distributed with the main program because of the GPL license being a copyleft license. That means that any code that gets distributed under the GPL license ends up inheriting the GPL license. The generated code cannot be distributed with the main program. it’s really that simple.
I know it is a really inconvenient thing to have to tell the program where to get the software from and it has to do this at runtime not install time. It has to be something that can be dynamically changed while the program is running.
XML files are a fantastic way of distributing this kind of a thing because they are not binaries. you can create schemas that define the structure to make a standard way of having the information that is needed in order for it to work. The user has the ability to very easily modify or create their own that they would be able to license however they want.
The key here is if different licenses are used for different XML files then all of the licenses need to be added to the output code. I would also have a disclaimer stating that it is the users responsibility to ensure that the licenses are compatible of using code that has different licenses. It would need to be a legal ease things stating the developer of the program is not in any way shape or form responsible for the code that is being used as input to generate the output code.
Wow, that gets complicated! I have learned something useful, thank you for explaining.
So, there is still an option to fork the project and then modify it so that the code it includes, and which ultimately gets in to the generated output, comes from an external file (e.g. XML file) which has say an MIT licence.
It sounds like a fork of the project might be beneficial since the original eez-studio would be able to benefit from being able to make use of any improvements made for/by LVGL users. Similar to how the OrcaSlicer was forked from PrusaSlicer however PrusaSlicer regularly incorporate improvements made by the OrcaSlicer team - it’s a win-win situation.
The generated code may be structurally similar, but it will not be the same because it depends on what screens, widgets, etc. are contained in you GUI definition files.
The situation is similar to, for example, the Inkscape program that generates SVG files, i.e. XML files, which by nature is also a code. I’m sure there are fragments in those files that are repeated in every SVG file that is generated. Does this mean that all SVG files generated by Inkscape are also under the GPL3 license?
In principle, the code it generates is not included in the main program already, it doesn’t use some kind of template files. The code is generated by the program, i.e. it is compiler that translates GUI definintion JSON files into CPP files. This can be obscured even more with introduction of CodeEmitter module which will have a functions like this: generateFunctionDeclaration, generateFunctionDefinition, generateIfStatement, generateForStatement, etc…
@kisvegabor ou can get around the whole licensing of the output code that is generated by the program by simply not including the code that is used to generate the code into the distributed package.
This is why I mentioned going the XML route. You already have a plug in manager built into the program. It would not be that hard to add into that the ability to download the XML files.
This is highly benificial in more than just the licensing aspect. It allows the program to output any code. It could be MicroPython code, c code or Rust code simply by changing the set of XML files that are used to output. It also makes it easier if LVGL changes API because then only modification to those XML files would need to be made in order to support the new API. You wouldn’t have do a complete recompile and a new distribution for this purpose. The functionality of LVGL may not have changed and only the naming has changed so there would be no need to change the internals of the program that use LVGL die to there being the backwards compatibility definitions and typedefs that the author has added. You would want the output code to have the newer API. so from a maintenance standpoint it would save you guys a hell of a lot of work. It would also add the users to make changes to those files to allow for tailoring of the output that they need.
If you provide a file that the user could update that would add that to the code so they would have an out of the box working code without having to modify anything. Maybe allow the user to create several of the " startup files" and provide a way for the user. to select which one they want to use based on the display they are using.
at a single user level it is not that that big of a deal when wanting to add say display drivers or that kind of a thing. But when you are dealing with a company they might want to have 30 different display driver setups and having a point and click interface for which one to use would make it a whole lot easier to use. This is one of those things that Squareline did not provide a way to do. so all of the output code would always need to be modified.
The idea is to make it easy for the user. You can do this right to the point of even flashing the firmware based on the the device they are using. That would be plugin based to add board specific routines and dialogs for this kind of thing. The dialogs would be to allow the user to select the com port and the speed and whether or not they want to erase the flash ahead of time. For something like micropython giving them the ability to adjust the partition sizes and also include frozen modules if they wanted to. There are things that would not be that hard to incorporate into your current design. I would recommend using somethign like an XML file or even a toml file to handle those kind of things. templates for the different LVGL pieces being used that have formatting markers to to replace with values or variable names.
so long as those files are released under a less restrictive license like MIT because that is what is being used to generate the code and it is not built into the distributed package the MIT license would then be passed to the output code that is generated.