Open source part of a code to avoid the empresarial license

[felipequentino]

Hi! I have a startup that has a product that detects objects. The product has 2 parts: one part I detect and do tracking of objects using Pytorch, that has MIT License, and is the "unique, important" part of my product, the other part is a simple ALPR using YOLOv8 to complement my product. Both parts sends information to a Dashboard, but they are INDEPENDENT, so the ALPR isn't connected in any way with the Pytorch part. The only thing that the two parts do in common is to send informations to the dashboard, here is a Venn diagram:

When I launch the product, I want to deploy the ALPR part in a jetson nano and make the ALPR code open source, avoiding paying for the empresarial license. This is OK to do? Making open source ONLY the ALPR part? 

[UltralyticsAssistant]

👋 Hello @felipequentino, thank you for reaching out and sharing details about your use case 🚀! Your application sounds fascinating, and we appreciate you considering Ultralytics solutions as part of your product.

For guidance regarding licensing and the use of YOLOv8 within your project, we recommend reviewing our LICENSE and consulting the YOLOv8 Quickstart Guide. These resources can be instrumental in clarifying your questions, although it's always wise to consult a legal professional for specific scenarios like this.

To better assist you, here are some general guidelines depending on the nature of your inquiry:

• If this is a 🐛 Bug Report, please ensure you provide a minimum reproducible example so we can understand and troubleshoot the issue effectively.
• If this is a ❓ Custom Usage Question, please share additional context, including code snippets, system setup, or examples, so we can provide more tailored insights.

In case you'd like to explore alternative configurations or deployment setups for your ALPR system, this might interest you:

Verified Environments

YOLOv8 can be run in any of the following environments, verified for efficiency and compatibility:

• Notebooks:
• NVIDIA Jetson devices, like the Nano you mentioned: We recommend verifying hardware compatibility with the latest ultralytics releases and referring to any specific acceleration configurations for Jetson setups.
• Docker solutions: See our Docker Quickstart Guide.

For more assistance or real-time discussions, consider joining our Ultralytics community:

• Discord for live help and conversations 🎧
• Discourse for in-depth discussions
• Reddit for sharing and learning with the community

Additionally, ensure you're using the latest version of ultralytics to take advantage of all enhancements and bug fixes. You can upgrade with the command below:

pip install -U ultralytics

This is an automated response to help guide your discussion. An Ultralytics engineer will review and provide further assistance soon. Let us know if there’s anything else you’d like to share in the meantime! 😊

[glenn-jocher]

@felipequentino thank you for your question. To comply with the AGPL-3.0 license, you are required to open source your entire project that uses any Ultralytics models, code, or architecture, not just a part of it. This includes the ALPR component, the PyTorch part, and any shared or independent components that interact with it, directly or indirectly, such as the dashboard. If you prefer not to open source everything, you must obtain an Ultralytics Enterprise License. You can learn more or apply here: https://ultralytics.com/license.

[felipequentino]

Ok Glenn, thanks for your answer.

[glenn-jocher]

@felipequentino you're welcome! Please feel free to reach out if you have further questions about Ultralytics or YOLO.

[coxep]

@glenn-jocher, I'd like to get your thoughts in this alternate scenario:

1. A third-party developer creates a generic, MIT-licensed plugin loader in C++ that can dynamically load detection model plugins at runtime using dlopen. The loader interacts with an abstract base class that defines a standard interface for detection models, ensuring the loader is agnostic to the specific implementation of any plugin.

2. The third-party developer developes plugins which implement the base class for various detection models, each as a standalone, dynamically loadable library:

   • YOLOv8 Plugin (AGPLv3) – Implements the base class to support YOLOv8 models.
   • YOLOv4 Plugin (Apache) – Implements the base class for YOLOv4.
   • Custom NAS YOLO Plugin (Proprietary) – Extends the base class with custom model support.
   • Etc.

   Each plugin adheres to the base class interface, and the license of each plugin corresponds to the model it implements.

3. A developer builds a closed-source dashboard that uses the MIT-licensed plugin loader. The perception pipeline interacts only with the abstract base class and is agnostic to any specific plugin implementation. This pipeline is sold to clients under a proprietary license.

4. A client purchases the proprietary perception pipeline. At runtime, the client:

   • Downloads and installs the YOLOv8 plugin (AGPLv3) separately.
   • Uses the pipeline’s runtime parameter (path to the plugin) to dynamically load the YOLOv8 plugin.
     Alternatively, the client can load MIT-licensed plugins (e.g., YOLOv4) without interacting with AGPLv3 software.

Key points:

• The dashboard operates independently of any specific plugin and can function without AGPLv3 components.
• The plugin loader does not contain AGPLv3 code—it simply loads plugins that implement the base class interface.
• The client is responsible for acquiring and loading AGPLv3 plugins.

Questions:

• From Ultralytics' perspective, can the client legally point the dashboard to the AGPL-v3 plugin implementation?
• From Ultralytics' perspective, is there anything preventing the developer from using their own dashboard internally with any of the third-party's plugins?

[glenn-jocher]

@coxep thank you for your detailed scenario. Under the AGPL-3.0 license, if the YOLOv8 plugin is used at any stage (internally or externally, directly or indirectly) within a proprietary system or pipeline, the entire project must comply with the AGPL-3.0 requirements, meaning it must be fully open-sourced under AGPL-3.0. This includes cases where the plugin is dynamically loaded at runtime. Alternatively, an Ultralytics Enterprise License would be required to use YOLOv8 in a proprietary or closed-source context. For more details or to apply for an Enterprise License, please visit https://ultralytics.com/license.

[coxep]

@glenn-jocher By your logic, would it not be fair to claim that Windows OS is violating this license (since someone might run YOLOv8 in Windows)?

[glenn-jocher]

@coxep no, the AGPL-3.0 obligations apply only to software directly incorporating or interacting with AGPL-3.0 code, not to independent platforms (like Windows) where the software may run.