LVGL is included unmodified as git submodule, so I think it is not part of EEZ Studio source code. We use LVGL cmake files to build WASM module using emscripten toolkit. This WASM file which is similar to DLL is loaded at runtime and used by the JavaScript. Having said that,
we will gladly add any kind of attribution texts at any place.
1 Like
This is one of those things where if using the strictest sense of the way that license files work… Yes it would need to be licensed under GPL3. Now doing that might come into violation with the licensing that SVG has over their file format.
This is one of those things that is kind of a really funky. I am not a lawyer and I think even a lawyer would have a hard time with that one. What I do know is that any program that is distributed is licensed under the license the program has. Its all about packaging and what is being provided in terms of licensing for any code that is being used. GPL has this thing where anything that is included will inherit the GPL license. I can tell you that much.
You have to look at this from a company standpoint. Say you are a company that has gross income of 250 million dollars. Would you want things to be licensed 100% correct or would you rather use something and say… Meh, chances are nothing is going to happen. Trust me when I tell you that the same thing came up when copilot was being written. The"Meh, chances are nothing is going to happen." decision didn’t work out so well for them.
You have to remember that LVGL is not just a diy’ers thing. There are very large companies that use it and they would want any kind of a wysiwyg piece of software that writes code to be 100% compliant with all licensing aspects or they are not even going to consider using it. It poses too much risk for them to potentially loose a very large portion of their profits.
1 Like
if any portion of LVGL included in the distributed version of the program? source code or compiled it doesn’t matter. If it is then it needs to be listed in the license files.
I understand, this will be corrected.
1 Like
I can’t make heads or tails if LVGL is being compiled into the program. It looks like it is.
I am not able to locate anythign that is editable where the files used to generate the source code are separate. It looks like they are compiled into the program and that would make the output GPL3 licensed.
They say: “All files either saved or exported from Inkscape (svg, png, pdf etc) are owned by the creators of the work (that’s you) and/or the original authors in cases you use derivative works.”
SVG files are able to be created a distributed with only one requirement. If the svg file is to be sold or used in a program that is sold the created SVG files must be licensed. If inkscape is 100% free and there ios no version of it where it is being sold so long as the author is not selling the work that they have created then it is free to distribute. if a dollar is exchange either for the software that created the files or to the user that used the software that generated the file then the svg file MUST have a paid license attached to it.
1 Like
SVG is a specification. The only thing that I can see that is copyrighted are the actual documents to the specification. So the output xml file format itself would not be copyrighted the contents that makes up the things that are not in the SVG specification, meaning the user data is what gets copyrighted and because this is not something that would be hard coded inside of inkscape then there would be no licensing requirement unless the user wants to add one.
SVG example
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="391" height="391" viewBox="-70.5 -70.5 391 391" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect fill="#fff" stroke="#000" x="-70" y="-70" width="390" height="390"/>
<g opacity="0.8">
<rect x="25" y="25" width="200" height="200" fill="lime" stroke-width="4" stroke="pink" />
<circle cx="125" cy="125" r="75" fill="orange" />
<polyline points="50,150 50,200 200,200 200,100" stroke="red" stroke-width="4" fill="none" />
<line x1="50" y1="50" x2="200" y2="200" stroke="blue" stroke-width="4" />
</g>
</svg>
and this is what can be copyrighted
391 391 -70.5 -70.5 391 391
#fff #000 -70 -70 390 390
0.8
25 25 200 200 lime 4 pink
125 125 75 orange
50,150 50,200 200,200 200,100 red 4 none
50 50 200 200 blue 4
The code generated by the EEZ Studio is all original code which is product of the user work. It doesn’t contain any licensed code that is copied from the EEZ Studio source code or any other source code. I don’t see any problem here, or maybe I’m too naive 
1 Like
I see that a lot of legal opinions were expressed and the imagination stretched even to corporate scenarios. The idea that once offered software under GPL3 blocks the author from changing his mind is a bold idea and I would like to see from legal practice if anyone ever had a problem because of this and therefore that EEZ Studio could become a precedent.
The idea that output from a GPL3-licensed tool also falls under that license is interesting, and if that’s really true, then we made a complete mistake in our choice and it will need to be corrected. I am now thinking of an electrical generator that is covered by the GPL3 license which would have the effect that the generated flow of electrons (aka electric current) also falls under that license and should not flow towards a non-GLP3 licensed bulb.
The choice of GLP3 for EEZ Studio was made for one reason only: to discourage all those who would simply copy EEZ Studio, possibly change the logo and continue to offer it commercially without any compensation or even try to patent modified EEZ Studio. Of course, that does not mean that someone will not do such a thing, which I think Prusa and others like him experienced.
Let’s go back to the 250 million corporation that has its own legal department, whose job is not only to approve or reject the use of some software just by reading the licenses, but also to contact the authors directly and, for example, if they need to get a signed statement that they can use the code generated by EEZ Studio without further restrictions use for commercial and any other purposes.
@kdschlosser thanks for all the opinions, but as you said yourself you are not a legal expert, and we will always remain open to discussing all aspects of using EEZ Studio with any corporate lawyers if they ever contact us.
The whole EEZ adventure was started on the basis of cooperation and sharing with others, and we will continue to work on our contribution to the open source community (both in software and in hardware), which I believe is in line with the LVGL worldview and that is why we chose to add it to the EEZ Studio regardless of the fact that even before that we had an EEZ-GUI type project that offers the same thing in a different way.
1 Like
I’ve just tried our EEZ Studio.
What I started the appimage it showed this in the terminal all the content was disappeared from the dashboard:
VISA dll Name librsvisa.so
Failed to load VISA dll
I’ve installed it from the deb package ans now it works well. 
Guys, I was amazed by how complete this work is. A lot of features that shall exist in SLS for long are just there. Namely snapping, adding styles, resource monitoring, double click on the project to open it, etc. To be honest there were some feature that weren’t that intuitive and I couldn’t figure out how to use them, but I’m sure that these could be improved.
I also felt a few things were inspired by SquareLine (such as checkbox for style properties).
Can you tell a little bit about how it work internally? How do you interact with LVGL? Do you use Emscripten and/or the Micropython binding?
Frankly speaking, we had a strategy about what to do next, but we have received so many positive and exciting feedback and input after the announcement that we need to reconsider our strategy.
It would be amazing to know @eez-open and @mvladic better. If you are open to a call please send me an email to gabor@lvgl.io.
I build a simple GUI to test the LvGL functionality.
The process was easy. However, when comes to porting the GUI to my MCU, it needs ton of dependencies in order to make it run.
Is there solution to remove these dependencies?
1 Like
Are these LVGL or EEZ Studio related dependencies?
EEZ.
The LvGL is already ported and working with the every demo available on LvGL.
IDK why I edited a post above but I want to have it placed here at the end
you can get around the whole licensing of the output code that is generated by the program by simply not distributing the code that is used to generate the output code
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 beneficial 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 due to there being the backwards compatibility definitions and typedefs that @kisvegabor 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.
see where I am getting at with that?
Here is an example of a crazy complex build system. MicroPython. I have spent the time and stripped the crazy out of it. It is a single entry point to have it compile. It takes care of collecting all submodules that are used and it takes care of running clean command and compiling mpy_cross. It does this all in a single command line.
as an example.
want to build for an ESP32-S3 with SPIRAM
python make.py esp32 clean submodules mpy_cross BOARD=ESP32_GENERIC_S3 VARIANT=SPIRAM_OCT
or say you want to compile it to run on unix
python make.py unix clean submodules mpy_cross
want to add a custom manifest file to add some files that get frozen into the firmware
python make.py unix clean submodules mpy_cross frozen_manifest=/some_path_to/frozen_module_list
any MCU that MicroPython supports works in this manner. Right to the point of the user being able to change the version of MicroPython they are using. adding command to the command line parameters so they can select if they want to use MicroPython 1.21 or 1.22 would be easy to do.
Another great thing would be providing a way for a user to make a config file without having to go and edit the file manually. There are all kinds of undocumented dependencies between the widgets and other parts. a UI that would provide checkboxes and it would deselect a widget if one of the dependancies is not selected would same a lot of hair pulling.
I have all of the dependencies mapped out for the various macros in the config file is anyone wants that.
This GUI builder has some serious potential. There are bugs in it that need to be handled but that comes with time. Things like the resizing of say a text widget by clicking on the dots not working. And elements being added not showing up or updating properly also needs to be fixed but those are bugs and not too huge of an issue.
I think that this has a hell of a lot more potential. Add in the code that I have made that makes the entire API for LVGL into a JSON file which can auto build the different UI element menus would greatly reduce efforts by the authors when new versions of LVGL are released. I have a build system I wrote for LVGL that can compile it as a shared library which would allow a user to select a specific version of LVGL that they want to use.
This it a better design than Squareline is It’s actually less complicated in how it runs and it has the ability to add a very large amount of additional flexibility that can be used by novices and also advanced users alike.
Things like the resizing of say a text widget by clicking on the dots not working.
When label widget has its width and height set to “content” (i.e. fit to content size) then resizing handles are not present, like this:
But, if you set width and height to “px” then you will be able to resize using (dot) handles:
I agree with you that at some point we will need more abstraction for the code generator to support for example different output languages (as you mentioned) and custom widgets written by the user or third party. As you notice we already have extensions manager so these specific generator could be extension downloaded from the internet with different license. For the time being, it is too early to design specification for the code generators to allow such extensions. But as specific use cases arises from the real life usage of Studio we will know better what are the requirements. I’m not sure that simple XML file could be used for this because I know that code generator has some logic inside which must be written using some programming language.
Thank you Gabor for your attention and invitation. Expect our mail soon.
1 Like