Legal issues with gTTS API?

[fquirin]

I've just posted an issue about potential legal issues with this API in the gTTS repo: https://github.com/pndurette/gTTS/issues/309

From the plugin description people will only understand that the service can break anytime but there are more risks. Imagine someone will build a system that goes into "production" with this plugin active (you know how people are ^^) and commercializes it. In the best case Google will just ask the owner to shut it down, in the worst case they will get sued :-/.

Personally I don't think an undocumented and unstable API moving in a legal gray area should be included in a system called OpenVoiceOS. For the same reasons it is not part of SEPIA OpenAssistant Framework.

That said I know first hand how hard it is to find an alternative that has comparable quality, is free (=self-hosted) and fast enough to run on Raspberry Pi etc., but I think services like gTTS are just a distraction on the path to become really "open"!

[j1nx]

Thanks for the heads up. OpenVoiceOS is a non-profit organisation without commercial ambitions it self, however everyone is free to use it and commercialise it. Hence we even would like that as long some of the money is used to give back into the organisation / development.

I will have the Python devs look into it.

[JarbasAl]

OVOS uses mycroft-core, this is one of the default options they offer (and they are a commercial product)

By using mycroft-core we will be supporting gTTS even without this plugin, i suggest an issue is opened in https://github.com/MycroftAI/mycroft-core

Will discuss this with the team, as things currently stand even if we deprecate this plugin gTTS support will still be in the code base

[ChanceNCounter]

With respect to a public API, I think it's generally accepted that you need to check the API's terms and pricing before utilizing it. It's not the module author's problem, nor would it necessarily be ours on that account. I also think you'd have to do some impressive mental gymnastics to call what we do an "automated query;" it's an occasional, one-step, frequently unique API call initiated by end user action.

I do think it could do with a disclaimer.

I'm leery of gTTS for all the other, obvious reasons, and I wouldn't mind dropping support, but I don't think OVOS is at any risk just from offering native support for this or any particular API.

Between us and MycroftAI, a number of proprietary STT and TTS systems are supported. It goes without saying that you need access to the system in order to use it with your assistant.

You can run Mycroft with ResponsiveVoice, but any commercial implementation needs to comply with their terms. There are a couple systems, I forget which because they're of no consequence to me, which you simply can't use without an account. That we or MycroftAI ensure compatibility doesn't mean we're facilitating illegal access to those systems. In those cases, we can't even offer OOTB access, just the ability to plug in credentials.

Lastly, being as it's a plugin, "dropping support" would consist of killing this repository, so if I'm wrong, and there is a problem, I can't imagine how the problem could get worse over time. It's a binary thing. Either Google finds both a reason and a legal cause to object to this thing's existence, or they don't. If they do, ☠️, and in the meantime, 🤷‍♂️

[fquirin]

I didn't want to scare anybody and I get it when you say it's not the responsibility of OVOS. I just think people should be informed better when using this plugin. The average user will probably not understand that this is basically a hack and not a Google service.

The hack has been around for ages in some form or another and I guess Google doesn't really care since there are thousands of people using the API for the intended purpose (Google Translate ^^) and Google most likely uses the same servers for Android and Chrome native TTS as well. But I think it's safe to say that the correct way of using Google TTS is via the official, paid service ;-).

Actually the biggest problem I see with this plugin is that people get used to it, because its convenient, "free" and has excellent performance but at some point you have to find an alternative and depending on your use-case this can be a non trivial problem.

[JarbasAl]

I think at very least the readme deserves a big fat warning!

long term our objective is to use coqui for the online female voice option, but thats require infrastructure.

I agree we should not expose this as a default option, if a user manually installs the plugin and reads the warning then thats their own choice, but i do not want to expose this in any user facing UI

[ChanceNCounter]

But I think it's safe to say that the correct way of using Google TTS is via the official, paid service ;-)

To be clear, these are different APIs. I assume Android and Google Assistant native TTS use the product called Google TTS. This is, unless I completely missed the point, the software that runs when you push the TTS button in Google Translate, which is not the same as what you get from Google TTS.

I do, however, believe that our default and suggested voices should and will be Google-free, and that users should need to install plugins to use privacy-negative systems. In the long run, Coqui as a public service seems inevitable, but we aren't in a position to provide it =P

[fquirin]

To be clear, these are different APIs. I assume Android and Google Assistant native TTS use the product called Google TTS

Different APIs leading to the same servers I assume. For German for example Google Translate's voice is identical to Google TTS WaveNet A. The latter currently charges 16.00$ for 1 million characters btw..

In the long run, Coqui as a public service seems inevitable, but we aren't in a position to provide it =P

Did you check-out Larynx (put together by Micheal for the Rhasspy project)? I've managed to run it on RPi 4 with 0.5 RTF which is almost good enough now. Nicholay from Vosk mentioned that TensorFlowTTS in the Cpp version is pretty fast too, but I haven't had time to install it yet (its a bit tricky). I like Coqui, but its too slow atm. I've tried to push people to focus on fast TTS with good enough quality but most projects are research projects that run their models on CUDA systems first :-(

[j1nx]

Could you please be so kind to create an issue on the mycroft-core repository which Jarbas linked above as well?

that would be the root cause of the issue👍🏻

[fquirin]

I don't know the details about OVOS and how it is connected to Mycroft and SEPIA is independent of both. If you are working closely with Mycroft and are interested to fix this upstream I'd kindly ask you to create this issue. You could also link the gTTS issue there. I just wanted to inform you that there might be issues with this plugin ;-)

[ChanceNCounter]

Different APIs leading to the same servers I assume. For German for example Google Translate's voice is identical to Google TTS WaveNet A.

Do utterances passed through those voices actually sound identical, though? The voice is only part of the equation, and other users have indicated better results from "real" Google TTS. I've never heard them one beside the other.

[JarbasAl]

@fquirin if the added disclaimer is not satisfactory please reopen this issue and I'm happy to revisit

[fquirin]

Looks good :+1:

Do utterances passed through those voices actually sound identical, though?

@ChanceNCounter I haven't investigated it in detail because there are dozens of voices and you have to find the right match first, but for German WaveNet A I can't hear any difference between both systems.