Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove all AGPL licensed YOLO references from Frigate #10717

Merged
merged 7 commits into from
Mar 30, 2024

Conversation

blakeblackshear
Copy link
Owner

I have been made aware by Ultralytics that Frigate is in violation of the AGPL-3.0 license because it is MIT licensed.

Some public discussion unrelated to Frigate is here.

This project cannot include any reference to models, code, or content that are AGPL-3.0 licensed from Ultralytics. In my understanding, this even includes novel code written to interface with their models that does not utilize any source code published by Ultralytics. Their position is that the models are not considered an output, but rather an extension of the source code published under AGPL-3.0.

At this time, I am not interested in changing the license to AGPL-3.0. Unfortunately, I believe this means that Frigate will never be able to support Ultralytics models published under this license even if I was to obtain an Enterprise License. This pains me as I am obviously a big fan of open source projects with a business model that enables them to be self sustaining.

Copy link

netlify bot commented Mar 28, 2024

Deploy Preview for frigate-docs canceled.

Name Link
🔨 Latest commit b806dfa
🔍 Latest deploy log https://app.netlify.com/sites/frigate-docs/deploys/660590704bbb7d0008fe1b06

@blakeblackshear blakeblackshear changed the title Remove all YOLO8 references from Frigate Remove all AGPL licensed YOLO references from Frigate Mar 28, 2024
@andrey-skat
Copy link

andrey-skat commented Mar 28, 2024

They stated that you should modify the license if you use their model or perform inference on it.
But you don't run inference on YOLO models or distribute them. Users perform the inference.

PS: I believe what they stated there are just their imaginations :)

@andrey-skat
Copy link

Or maybe you could consider renaming all 'yolo8' references to 'model8', for instance? The script itself is not very specific to yolo8 without explicit reference.

Removing from Frigate will ruin all my surveillance :(

@NickM-27
Copy link
Collaborator

@andrey-skat the models being run come directly from a source that is AGPL licensed, changing the name does not change that fact.

@alexyao2015
Copy link
Contributor

Perhaps the way around this is Frigate adopts a remote detector approach similar to the deepstack connector. Different detectors could be packaged as separate containers and licensed accordingly to not break the agpl license.

@NickM-27
Copy link
Collaborator

NickM-27 commented Mar 28, 2024

We are currently migrating parts of the codebase to use ZeroMQ so that could be a potential avenue to accomplish that (preferable to http)

@andrey-skat
Copy link

andrey-skat commented Mar 28, 2024

the models being run come directly from a source that is AGPL licensed, changing the name does not change that fact.

It was half-joke and I understand you will not do that. But the point is that you don't run model, user does. This code has zero references to yolo8 code or models. And, for example, if your program can only copy files it doesn't mean you should forbid users from copy AGPL files. If in future, code in branch elif self.ov_model_type == ModelTypeEnum.yolox: suddenly starts properly inference yolo8, 9 or any other future versions it does not mean you should remove it :)

@jmtatsch
Copy link

I am really sorry to hear that, but that sounds a bit like an overreaching lawyer.

Could you maybe publish the relevant text parts, here so we can dissect them in the community?

This project cannot include any reference to models -> pretty sure that one can link to / name whatever the hell one wants
code, or content that are AGPL-3.0 licensed from Ultralytics -> yes that is protected

In my understanding, this even includes novel code written to interface with their models that does not utilize any source code published by Ultralytics.

From my understanding nobody can forbid you to write code to interface with their models as long as one didn't use private knowledge from the (A)GPL-3.0 licensed material of Ultralytics. Fortunately yolo models were widely published in the scientific literature and are a favourite in the open source community so it will be insanely difficult to prove with what knowledge frigates ancillary code was built unless it was directly copied.

If just the switch to AGPL-3.0 is the problem, one could just freeze everything to version 8.0.77 before AGPL-3.0 was chosen.

If GPL-30 has been the problem all along, frigate has to make sure it doesn't distribute Ultralytics work i.e. no exact copies of their code and no models. But everything else can and should stay.

By the way contributors to the ultralytics repo have only agreed on their contributions to be GPL-3.0 since Dec 5, 2022.
so probably half of their contributions DONT even have a license for Ultralytics to use/sell commercially.
Their CLA bot has been established only on January, 10th 2023.

Maybe @glenn-jocher can chime in on what Ultralytics really wants to be removed.
After all ultralytics seem hardcore open source just like the frigate author but understandably both want to be able to make a living from their work.

@MarcA711
Copy link
Contributor

As I understand it, you can use AGPL Code in your own code (even under a different license) as long as you keep the GPL part separate (for example by using dynamic linking, in case of source code) so that the user can change the GPL parts. Here the user can easily change the model.

@andrey-skat
Copy link

andrey-skat commented Mar 29, 2024

Sorry for many responses, I'm still a little bit upset about this :)

I read again linked thread. And what they say is if gpl program create, compile, encode, encrypt, save file in own file format or compress file then non-gpl programs can't use that file.
Compressed file is also some "weights" created by program based on some input data = "dataset". So if GPL program compress the file then non-GPL program can't read it or include in distribution? :) It's obviously not.

The fun fact is that nobody can be sure what program created particular type of file. Even model in YOLO8 format can be created by another software. Weights can be created even manually. All this looks like new version of patent trolling.

Anyway "GPL focuses on the source code and how modifications are handled, but it doesn’t restrict file compatibility". Models are not a programs nor "extensions" of software.

@TechnikEmpire
Copy link

This would mean that any program that reads files created by GPL programs would be forced to be GPL. This is the most insane interpretation of copyleft licenses ever and you should ignore them. However, their models aren't even the best. Look at Yolo NAS and architectures based on efficient former etc.

Sorry you're dealing with profiteers weaponizing open source.

@blakeblackshear
Copy link
Owner Author

It's going to be ok. There are many alternatives to evaluate. Based on the linked thread, I would prefer not to touch it with a 10 foot pole for now. I understand that they are trying to protect their business model by limiting commercial use to channels they control. It's a tough line to walk with an open source code base.

@andrey-skat
Copy link

andrey-skat commented Mar 29, 2024

The main mystery is how they create non-GPL models for they commercial product

It's going to be ok. There are many alternatives to evaluate.

@blakeblackshear Do you plan to add support of YOLO-NAS? Maybe it even requires same code :)

@MarcA711
Copy link
Contributor

MarcA711 commented Mar 29, 2024

Well, the YOLOV-NAS license is also pretty restrictive...

You are only allowed to use it with their tools see here:
"The YOLO-NAS model is available under an open-source license with pre-trained weights available for non-commercial use on SuperGradients, Deci's PyTorch-based, open-source, computer vision training library."

Moreover, you are not allowed to modify the model see here:
"You shall not, without Deci's prior written consent: [...] (V) reverse-engineer, decompile, disassemble, alter, enhance, improve, add to, delete from, or otherwise modify, or derive (or attempt to derive) the technology or source code underlying any part of the Software"

This means, I cannot use YOLOV-NAS on the rockchip platform, because I need to rebuild the model into an rknn format and use the rockchip tools to perform inference.

Maybe, this is different for other platforms.

@andrey-skat
Copy link

andrey-skat commented Mar 29, 2024

So, you're right in pointing out that using weights without directly including or integrating GPL-program code in a distribution doesn't automatically impose GPL constraints on the user.

Does it mean they change their position? :) link

@alexyao2015
Copy link
Contributor

I will also add seems like all comments from @glenn-jocher on the yolo repo seem to be chatgpt responses. It really seems that they aren't necessarily reading anything and doing mostly a copy paste job. There's even an issue on the repo discussing this problem.

@alrassia
Copy link

So, you're right in pointing out that using weights without directly including or integrating GPL-program code in a distribution doesn't automatically impose GPL constraints on the user.

Does it mean they change their position? :) link

Not really, they just suggest to talk to a lawyer and take it from there. I doubt they can make it stick in court, but until then it’s a potential headache and best to stay away.

@blakeblackshear blakeblackshear merged commit 14235c4 into dev Mar 30, 2024
13 checks passed
@blakeblackshear blakeblackshear deleted the remove-yolov8-dev branch March 30, 2024 10:46
Repository owner locked as resolved and limited conversation to collaborators Mar 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants