Open hacker1024 opened 4 years ago
LGPL is not workable, but MPL looks potentially less probleematic. It will take me some time to review the license terms.
I remember encountering another drop-in replacement for AVPlayer written in Swift before but I didn't bookmark it. It would probably be a good idea to consider a list of alternative options at this point before making a decision, comparing the feature set and licenses.
Oops, I forgot about the licensing. I did a bit of poking around to see if there was an API-compatible AVPlayer replacement, but I couldn't find one. I'll do some more research.
Here is another that looks interesting:
https://github.com/sbooth/SFBAudioEngine
However, it's missing certain streaming protocols.
It's also only compatible with macOS 10.15+ and iOS 13+, which isn't really ideal. I haven't been able to find anything else other than VLCKit - perhaps additional codecs aren't really an option for this plugin.
I haven't ruled out VLCKit, although I would need time to look at its license.
How about MPV? It's GPL 2+/LGPL 2.1+, which could be an issue but MPV should support all platforms, including Android and iOS (https://github.com/ldwardx/mpv-build-mac-iOS).
I'll copy a message I wrote on #103 which is also relevant to this discussion:
The LGPL is basically incompatible with iOS because iOS doesn't provide a way for users to install their own version of a DLL. There are ways you could get close by having a separate app to hold the LGPL code and then use IPC between the two apps, but as far as I can see the same developer needs to own both apps, so the user couldn't substitute the LGPL one and have the non-LGPL one use it. Android might be a bit more flexible with IPC but still it's not convenient for most users to have to install the LGPL'd component as a separate app. [...] That is why I do not accept any LGPL-licensed code in just_audio.
But, this issue only exists for mobile apps. Since we're talking about Windows and Linux, it is possible to meet Section 6a of the LGPL, so there is no problem using an LGPL'd library.
The federated plugin model makes it possible to keep the LGPL'd portion separate from the rest of the plugin so that the license files can be separate for each part. You can read about federated plugins here:
https://flutter.dev/docs/development/packages-and-plugins/developing-packages
Note that my comment above on Windows and Linux above would also apply to macOS, and so in theory we could also do this under the federated plugin model which would make it possible for a GPL/LGPL-based implementation to be added as a separate pubspec.yaml dependency. I think this would be a good way to leverage these GPL/LGPL libraries in contexts where it is legal to do so.
(It is interesting that many Android/iOS developers are unaware of the compliance issues surrounding certain licenses. Reading: https://betanews.com/2011/03/08/are-mobile-developers-violating-open-source-licenses/)
Is your feature request related to a problem? Please describe. I need to play an uncommon codec, and AVPlayer doesn't support it.
Describe the solution you'd like VLCKit seems to support a lot more formats than AVPlayer does. If we switch to it, the Darwin implementations should be more like the Android one - at the moment, my media only plays on Android.
Describe alternatives you've considered I could use a different audio plugin on Darwin, I suppose...
Additional context It seems like VLCKit can do queues, so that shouldn't be an issue.