Remove Binary Blobs from Repository

[dcrdev]

Goals:

1. Remove third party binary blobs from this repository.
2. Remove Emby LLC proprietary binary blobs from this repository.

Implementation:

1. Where possible obtain these from NuGet.

2a) Replace these with dummy libraries, just throw not implemented. This will allow the new 'EmbyServer' implementation to build unencumbered.
2b) Within the new EmbyServer implementation add a method that checks whether the assembly properties contain the word 'Dummy', if they do then download those binaries from upstream and replace them before sigterm'ing the process and starting it back up.
2c) Not sure how friendly this is to the GPL... might implement passing a parameter containing the upstream repository url and handle the passing of that in packaging which would be done in a separate repo under a seperate license.

[benpye]

I have been looking to see where these binaries have been introduced. It looks like, at least in the case of Emby.Server.MediaEncoding.dll, Emby.Server.Connect.dll and Emby.Server.Sync.dll they have taken previously open source code, removed it from the repo and now distribute it as a binary. I have been going back to find where these changes have been made.

Emby.Server.MediaEncoding.dll:
Introduced: dec3644
Last FOSS: 197574f

Emby.Server.Connect.dll:
Introduced: 8c0bf13
Last FOSS: 6e4c9df

Emby.Server.Sync.dll:
Introduced: 758445d
Last FOSS: 84daad6

In early versions of Emby there are other binaries but these seem to have since been removed, though they appear to follow a similar pattern. The last commit with no closed source binaries appears to be 6e4c9df , there are still some Emby binaries however the source code appears to still be available. The last commit with no Emby binaries appears to be e9a5758 , there are still binaries from third party projects though these should be reproducible. Interestingly, back in these commits the .NET Core build scripts were also open source.

Back to GPL violations, if these are just derivations of previous work, and that previous work had external contributors that did not sign the CLA then that would not look great for Emby.

I intend to fork at 6e4c9df and attempt to get this building, I will keep this updated. Whilst I respect that Emby want to make money, I cannot get behind a project that I was duped into believing was open source when quite clearly, it no longer is. I would rather use Plex at that point, at least they don't pretend to support open source.

[joshuaboniface]

@benpye Awesome detective work! So it looks like we can revert these components to an earlier version and eliminate the binaries without license violations? If so that would mean we can have a completely OSS build of Emby without much rewriting. Please let us know how your testing turns out!

[dcrdev]

Yes that is useful - but there's potentially a lot of API changes that need to be accounted for to get those components working with a current version.

@joshuaboniface have you done any additional work on your fork?

[joshuaboniface]

Yea I worry there's a lot of change there as well. I've only been messing around with the auth so far, trying to understand it, but otherwise not really - it's been a really busy month! I'm hoping to have more time to dig into it in September.