Often we’ve seen when working on machines, no one can confidently say which version of code is running on a machine. No one knows for certain “did I transfer last? Did this bug fix get applied to the machine?” This is a problem that gets exponentially larger the more people that have access to transfer to a machine. So, we created BuildVersion to help combat that.
BuildVersion is a tool that pulls git repository and PC version information automatically and adds it to a project to display in an HMI. It is added to a project using the Framework Import tool added to Automation Studio when you install the mapp Framework. Once added to your project you can then use pre-build standard mapp View widget to display the relevant information on an HMI widget
Separately, if you’d like to look at the individual repositories for the two components (the buildversion task/script and the buildversion mpView Widget library) can be found here and here.
Reporting Bugs / Feedback
For bug / feedback reports, please use the GitHub repository to report them here.
Is there a reason, why you didn’t include the “dirty” information? In my opinion this would be a helpful information if you build and transfer manually (not as part of a pipeline). How would you ensure that everyone commits all changes before building and transferring to target?
Additionally it would allow you to highlight this deficiency on the HMI. Like this, people would ensure that such a build is never shipped…
I don’t know what I am doing wrong but in the mapp Framework Importer the BuildVersionProject is not showing up. I already installed AS4_TS_BuildVersion_1.0.1.0.exe several times and restartet AS, with no effect. Has anybody an idea?
Please take the role of a commercial software developer, and explain what are the rights and the duties when using GPL-3.0 licensed software in your own project.
And AI answered:
As a commercial software developer, I see the GPL-3.0 (GNU General Public License) as a powerful but “strict” license. It is designed to ensure software stays free, which creates specific legal requirements for companies.
Here is the breakdown of your rights and duties:
Your Rights (What you can do)
Commercial Use: You are allowed to use the software for any purpose, including commercial ones, without paying license fees.
Modification: You can modify the source code however you like to fit your project’s needs.
Distribution: You can copy and distribute the software (original or modified) to your customers.
Your Duties (What you must do)
The GPL-3.0 is a Strong Copyleft license. This is the most critical part for businesses:
Source Code Disclosure: If you distribute your product (e.g., via sale, download, or pre-installed on hardware) and it contains or is based on GPL-3.0 code, you must make the entire source code of your project available to the recipients.
Same License Requirement: You cannot keep your own code proprietary if it is “linked” to or derived from the GPL code. Your entire work must also be licensed under the GPL-3.0.
Copyright Notices: You must preserve all existing copyright notices and provide a copy of the license with the software.
Anti-Tivoization: You cannot use hardware locks (DRM) to prevent users from installing modified versions of the software on the device it came with.
Patent Grant: By distributing the software, you automatically grant users a license to any of your patents that are necessary to run the code.
The “SaaS” Exception (Crucial for Modern Devs)
In the commercial world, there is a major distinction: if you run the software only on your own servers (e.g., as a backend for a website or a Cloud service) and never actually send the binary/code to the customer’s machine, the duty to disclose your source code is generally not triggered. (Note: If the license were AGPL, this loophole would be closed.)
Summary for Practice
If you are building a proprietary desktop app or embedded firmware and you statically link a GPL-3.0 library, you risk having to “open” your entire intellectual property. This is why many companies prefer LGPL (for libraries) or MIT/Apache (permissive licenses) for their commercial products.
Thanks @alexander.hefner , this is the part that is most concerning:
”you must make the entire source code of your project available to the recipients.”
I believe we should be able to change this license as we were the sole contributor but we are double checking that at the moment. In order to change the license we will have to create a new release. We can not change the licenses of previous releases so all users would need to update to the new release with the MIT license when and if it is released.
Everyone should update to the version in order to start using it under the MIT license as we are not legally allowed to change the license of previously released versions.
Sorry, didn’t see that. But you name it, that’s perfect 
