Difference between Source and Site licenses

Site License

The site license grants you the right to use the SDK as a compiled and obfuscated DLL, validated for a single company site (postal address), regardless of the number of developers or redistributable applications.

With the site license:

• You receive only the compiled, obfuscated DLL, not the source code.
• You can download the binary from GitHub Releases or include it via NuGet.
• You can use and adapt all the samples available on GitHub to speed up your integration.

---

Source License

The source license gives you access to the internal C sharp solution of the SDK.

It includes:

• The full documented C sharp solution used internally.
• A large code base with access to the internal algorithms and implementation details.
• Access to the same compiled outputs that are used and generated automatically by UnderAutomation tooling.

---

Upgrade from Site License to Source License

You can start with a site license and later upgrade to a source license if the SDK becomes more strategic for your projects. When you choose to upgrade, the amount already paid for the site license is fully deducted from the price of the source license, so you only pay the difference between the two options.

Integration and Activation

Activation

To activate the site license in your application, call the static method: RegisterLicense("licensee", "secret key")

• licensee is usually your company name or the licensed entity.
• secret key is the license key you receive by email after your order.

The secret key:

• Is delivered by email after purchase.
• Is confidential and must not be shared outside of your organization.
• Must be stored securely (for example in configuration or environment variables, never in public repositories).

Trial license

To obtain a 30 day trial key, visit the license page on the website and follow the instructions.

---

.NET

The SDK is available for multiple .NET targets, so it can be used in a wide variety of applications, such as:

• Desktop applications
• Services and background workers
• Web applications and APIs

You can integrate it like any other .NET library from NuGet or GitHub Releases.

---

Python

Python is supported through a wrapper around the .NET library:

• The core logic remains in the .NET engine.
• The wrapper exposes a Python friendly API, so you can use the SDK from Python scripts and applications without dealing directly with .NET interop.

---

LabVIEW

LabVIEW is supported through a set of VIs:

• The VIs are designed to fit the LabVIEW way of programming, with dataflow and block diagram logic.
• Internally, the LabVIEW layer is a wrapper around the .NET library, using adapted objects that make it natural to work with in LabVIEW.
• This allows LabVIEW developers to benefit from the same engine without writing any .NET code.

---

Preview of the code structure

A preview of the public API surface can be found in the .NET GitHub repository:

• A folder named ObfuscatedSources contains the empty shell of public classes and objects.
• These files are commented and show the structure, public members, and documentation.
• Internal logic and implementations are not present in this folder and remain part of the full source package reserved for source license customers.

No trial for sources

Because the source license exposes the full internal implementation, it is not possible to provide a trial of the sources.

---

Advantages of Having the Source Code

Below are the main advantages of choosing the source license instead of using only the compiled DLL.

1. Technical control and customization

• You can adapt the SDK behavior exactly to your business rules and specific scenarios.
• You can remove unused parts, simplify execution paths, and keep a version perfectly aligned with your internal architecture.
• You are free to adjust error handling, logging, and integration patterns to match your existing codebase and standards.

2. Long term safety and reduced vendor risk

• You are not locked into a black box component that can only evolve through vendor releases.
• If the product roadmap changes, or if a feature you need is not prioritized, you still have everything you need to maintain the current version in house.
• You keep a fully usable version of the library even if the product is discontinued, renamed, or heavily refactored in the future.

3. Performance and optimization

• You can profile the code in your real environments and optimize the critical paths that matter for your workloads.
• Performance tuning can be done directly in the engine instead of adding complex workarounds on top of the public API.
• This is especially useful for high volume, low latency, or resource constrained scenarios.

4. Transparency, audit, and compliance

• Security teams can audit the source code, check dependencies, and validate how data is handled.
• It is easier to meet regulatory or internal compliance requirements when you can show exactly how a component works.
• You can apply your own quality gates, static analysis tools, and code review process to the SDK, just like any other internal project.

5. Developer productivity and troubleshooting

• Debugging is much easier when developers can set breakpoints inside the SDK and step through the code.
• The source code serves as a living form of documentation, helping new team members understand both the domain and the behavior of the SDK.
• Many issues can be diagnosed and sometimes fixed internally without opening a support ticket.

6. Total cost of ownership over time

• The source license is a higher initial investment, but it reduces long term costs linked to delays, blocking bugs, and dependency on external release schedules.
• Your teams are less likely to be blocked by a limitation that cannot be worked around with only a compiled DLL.
• When the SDK becomes central to multiple projects, the ability to evolve it internally often pays for itself.

7. Technological independence and future proofing

• You can port the SDK to future .NET versions or platforms as your stack evolves.
• The code can be aligned with your internal standards for security, observability, telemetry, and testing.
• As your architecture changes over time, the SDK can evolve with it instead of becoming a rigid external dependency.

8. Innovation and differentiation

• You can extend the SDK with features that are specific to your company and your products.
• These internal customizations can become a competitive advantage, built on top of a robust and proven base.
• You can experiment with new ideas inside the engine, without waiting for them to appear in the official roadmap.

9. Strong argument for IT and management

• The source code is an internal software asset, not just a license to use a black box binary.
• During architecture or investment committees, owning the sources significantly reduces the perceived risk of adopting the SDK.
• It is often easier to justify a strategic purchase when you can guarantee autonomy and long term maintainability.

10. Simple positioning compared to the site license

A short way to explain the difference:

• Site license: you use the SDK as a compiled and obfuscated DLL, with samples, support, and updates. Ideal when you want a ready to use component with a simple integration.
• Source license: you get the full documented C sharp solution, internal algorithms, and the ability to adapt, debug, and extend the SDK in house. Ideal when the SDK is a strategic component and you need maximum control and long term security.