Performing a full fork?

[joshuaboniface]

In light of the history of this project and its maintainers, and now the (news-to-me) GPL violations, combined with the virulently toxic attitudes of the "community" around Emby (the "stop whining" crowd) - should we do a full fork? Basically, planning to do what Libresonic did when Subsonic went closed-source?

As mentioned in #25 I don't have any experience with C# development, but I know a few people who do and might be willing to get involved, and I can help with build infrastructure/hosting/etc. as that's my specialty. Frankly I don't care that "99% of users won't care", I care, and will ONLY use OSS software, which is why I even went with Emby in the first place. And I care a lot about keeping it that way for everyone else, since Emby is the only reasonable and OSS alternative to Plex. Plus this gives us the flexibility to start adding useful features (for me, LDAP user authentication support and the ability to choose between Air order and DVD order for TV without manually hacking metadata, things with the Emby core devs have ignored for years at this point).

Some short-term goals could be:

0. Rename to something else. Openby?
1. Opening up the build process and ensuring full GPL compatibility for all parts of the app.
2. Proper packaging for Debian and related distros - no more patching, let's integrate it right into the fork and build compliant packages.
3. Removal of all callbacks/links to the main Emby site from inside the server.

Some longer-term goals could be:

0. Rebuild the Android app with the new name and fully OSS (Fdroid rather than Google Play?)
1. Remove all "premium" components or make them fully available.
2. Add additional features like LDAP, TV order switching/choice, etc. and any other features we might think of.

Any thoughts or interest from those here? Do you think it's worthwhile? Could we get enough devs to keep up?

@nvllsvm @dcrdev and anyone else.

Edit 2018-08-10: My fork is at https://github.com/joshuaboniface/Emby and should build a Debian package right now.

[dcrdev]

This is a subject I've thought long and hard about over the last few months and just the way Emby is going at the moment and the attitude of it's fans and developers towards the GPL, make me want to participate in something like this.

I think if we could get enough skilled people on board, then it's worth exploring but only then. It's one thing to fork the server component, but then the apps need developing from scratch as they have never been open source; you know the moment a fork appears, the Emby team will block it within their own apps.

But I think to be more specific, immediate priorities:

1. Remove binary blobs from the repository and either remove references to those libraries or re implement them.
2. Ensure the build process is as open as can be.

What I can bring to the table:

• Extensive database knowledge ANSI SQL / MSSQL / MySQl (Data Engineering is sort of what I do)
• Some .NET skills (albeit very very rusty now)
• Any sys admin duties (Linux mind you)
• RPM Packaging Skills (Sponsored RPMFusion Packager)

[dcrdev]

Also in regards to a name - I was thinking something like EmbéLibre lol

[joshuaboniface]

I think if we could get enough skilled people on board, then it's worth exploring but only then.

So that's 2 of us, I know @nvllsvm mentioned he does this for a friend in another issue, but I've also got a friend or two with C# experience who might be willing to help occasionally.

It's one thing to fork the server component, but then the apps need developing from scratch as they have never been open source; you know the moment a fork appears, the Emby team will block it within their own apps.

That's a concern of mine as well - given their attitude in general I'd be wary of them taking "retaliatory" action against the fork. It looks like the Android app (https://github.com/nvllsvm/emby-android) is indeed GPL though, which is a start - I'm not sure whether you guys are Android or iOS but I'm Android so that's fine by me to start with.

But I think to be more specific, immediate priorities: Remove binary blobs from the repository and either remove references to those libraries or re implement them. Ensure the build process is as open as can be.

I like these priority-wise, and think they're easy enough to get done as soon as we have a bit of a community. I've already got a working Debian build setup for the emby-server component (see my PR), also "forked" from their source packages, that can hopefully be used as a template for RPM as well.

Also in regards to a name - I was thinking something like EmbéLibre lol

I like that, but accent aigu might cause trouble ;-)

[joshuaboniface]

There's also Streama (https://github.com/dularion/streama). I'm now debating throwing my and my friend's weight behind it instead of dealing with Emby. It's still immature though moving fast and needs more work (it didn't have half the features the last time I checked on it), but it's a good start, and written in Groovy instead of C#. The only breaking issue for me is the requirement to have a theMovieDB.org API key to use it.

[dcrdev]

I did have a look at that a while back and it's certainly a valiant effort, but for me it lacks something critical - music support.

Also I know it's written in Groovy, but it's still Java and to me that's a bit off putting; I have very mixed feelings about Java. Whereas despite C# and .NET Core coming from Microsoft, I feel are generally well designed.

[nvllsvm]

Welp, looks like we need to hard fork. Emby depends upon proprietary blobs else the software won't compile.

https://github.com/MediaBrowser/Emby/issues/3075#issuecomment-371021228

[nvllsvm]

Finally got around to starting a side project I've been thinking about for well over a year.

In a few hours of hacking, I managed to hack together:

• a script to transcode and segment a video file into small chunks
• an HTTP service hosting the chunks, HLS manifests, and hls.js demo UI

Feel free to look at the caffeine-fueld wip. Did I mention it's hacked together? https://github.com/nvllsvm/maelstrom/tree/dev

Anyway - seems to work so far :)

[joshuaboniface]

@nvllsvm That looks great! On the one hand, building a full replacement streaming server is a big undertaking, but on the other, having another option, written in Python (yay) and without a decade of .NET cruft is amazing! I'm definitely keeping an eye on it and will see if I can help! ;-)

[Jab2870]

Hi,

I would be very happy to help anywhere I can. Most of my experience is in front end web dev although I have done some simple things in C, C++ and C# in the past.

I have also got a reasonable amount of linux experience (about 10 years but never in a professional environment). I've only been using Open Source for a while and would love to give something back if I can. I use emby-unlocked a lot so thought this would be a good place to start. Please let me know if I can help.

[SamAtwell]

Not sure how serious this discussion this but I have a couple of thoughts:

1. Is the intent to start over completely (as in a completely new project) or just a hard fork (ala OpenOffice vs. LibreOffice)? @joshuaboniface had a good thought of not dealing with a decade of .NET cruft and that's very appealing but I am not sure how feasible it is to start over and build a complete replacement.

2. I think the new project should focus explicitly on server and the web client (and the underlying API). I realize it may be subjective but I feel building the clients will be easier, if you are using the same API as the web client. Plus we could look at using Xamarin, so there isn't as much effort required to create an app for all the various platforms.

3. As far as developers go, there are a bunch of other projects on GitHub that we should explore and see if they would be interested in collaborating. Obviously, everyone has different goals but even if you get a couple people interested, that would be a win.

Here are a few projects that seem like a good place to start:

https://github.com/nmaier/simpleDLNA

https://github.com/MediaPortal/MediaPortal-2 (this one might be difficult, since it's already a mature application but this is the closest to what Emby is)

https://github.com/TwitchBronBron/PlumMediaCenterSharp

https://github.com/einsteinx2/WaveBox

Edit: A couple more relevant projects:

https://github.com/sqirrel99/FreeMi

https://github.com/GyrosWorkshop/Wukong

[joshuaboniface]

Thanks for the feedback everyone!

I think @SamAtwell 's point #1 is the big rub - we're hitting the "POSIX filesystem" problem: we can't attract any users until we have a feature-complete system (for a limited feature set, but it must be relatively close to what Streama has now if not what Emby/Plex have), but getting there is a non-trivial amount of work. I'd be more open to doing this for the reasons I mention, but it would need several solid developers (I'm not one) to dedicate to it. @nvllsvm's proof of concept looks really nice as a starting point though!

Given what we have today though, and especially with @Jab2870's offer maybe just hard-forking emby-server is a good plan. We can take @THEYsuxx's suggestion of decompiling the non-compliant DLLs, and just go from there. This is a lot less work right now, but would we have momentum long-term? And is it worth all of our effort to support a "new Emby"? It would still be the same codebase which is pretty gross. It's a hard problem.

For #2 I agree completely (again, as a non-developer) - client apps are "easy" once there's a scalable API in the backend. I've never heard of any of the projects in #3 so I can review some of them to see where they're at.

[dcrdev]

I'm contemplating something else at the moment... bear with me:

Whilst I have ended my issue on their GitHub page due to them having cleaned up a few things and there no longer being a technical GPL Violation. I still believe that the way they are handling things goes against the spirit of the GPL and the fact that one cannot build it themselves is absurd even if they are claiming those releases to be a "re-licensed version" , they are not highlighting that fact to end users.

So what I'm thinking of at the moment is forking it, writing some python to patch the csproj files dynamically and then having some shell scripts merge any changes from upstream. I could then set up builds for Fedora, CentOS/RHEL and OpenSUSE via copr - anyone else would be free to chime in for Debian/Ubuntu/Docker.

Then in regards to the propriety blobs, they could be reverse engineered but purely to get the class definitions and any methods would just throw not implemented exceptions. So in effect as a starting point we would have an entirely free version of Emby and that would not be a direct threat to them e.g. we might get away with still using their apps, but they'd have to be purchased on a single device basis due to lack of premiere; that would also continue to bring in an income for Emby.

Finally the pièce de résistance...

As you may have noticed Emby doesn't really have that many contributors from outside, a large part of this I suspect is down to their CLA. The proposed fork would apply no such restriction - hopefully this may begin to attract interest from developers.

At which point it would hopefully have enough traction to warrant the creation of new apps, a re-brand and the re-implementation/re-imagining of some of those premiere features.

Thoughts?

[dcrdev]

Also not ruling out a completely new solution - I too would like something that isn't dependent on netcore as it's a pain to manage a build system on Fedora/RHEL. I like the sound of something in C++ or Rust maybe.

But realistically that's going to take a lot of man-power from the get-go and would likely take quite a lot of time before it comes to fruition. But very open to the possibility...

[SamAtwell]

Also not ruling out a completely new solution - I too would like something that isn't dependent on netcore as it's a pain to manage a build system on Fedora/RHEL. I like the sound of something in C++ or Rust maybe.

Would using something like FAKE or Cake help with that?

The one benefit to using C# (and .NET) is you get to re-use a big portion of your code for building client apps through Xamarin & Mono. IMO that's a huge advantage compared to other platforms, though I suppose you can do the same JS with React Native, Ionic, etc.

[Hippyjake]

My main concern is that is can be compiled on Linux, sooooo mono support is a must :wink:

[dcrdev]

I have started work on modifying Emby to build under netcore / scripting the automation to merge changes from upstream.

Have 75% of the projects building, a couple I need to iron out the dependencies for. https://github.com/dcrdev/Emby

Also need to work out what's supported in netcore in terms of unit testing.

[dcrdev]

There's a portion of code missing from their repo that would allow you to build a fully working version under .net core. That is the server application itself - in the repo only exists the mono server application and the windows one.

I'm re implementing it to the best of my abilities at the moment, but looks like there's also some missing constructors in the 'Emby.ServerImplementations' project to support this. That and the fact every single javascript file (not 3rd party) is minified, really gives me the impression they don't welcome contributions.

So whilst I'm probably going to be able to get this working, my dream of automating it has gone swiftly down the drain - I've had to make significant changes. I've also stripped out Windows support entirely because I can't test it, also have stripped out Mono as that will become redundant anyway. Anyone like to chip in?

[nvllsvm]

@dcrdev - Look around in the other MediaBrowser repos. Pretty sure the minified JavaScript files exist as their original forms in other repos. I know Emby.ApiClient.Javascript contains some of the original Javascript files, but not sure if it has them all.

[dcrdev]

Little taste of what's coming: https://gist.github.com/dcrdev/9fd1652ebeb2e5701161882439d09765

[Hippyjake]

I'm excited!

[joshuaboniface]

Looking good @dcrdev!

[Sockolet]

Waiting for this 😀

[Jab2870]

Looking good.

[dcrdev]

I've rewritten the apphost library now and have it up and running, just 3 things to go before I push the missing piece to the repository:

• Either ask Luke to update the NuGet package for MediaBrowser.Naming so that it targets .net standard or core, or pull in Emby.Naming into the solution directly.
• Removal of proprietary binaries as described here: https://github.com/dcrdev/Emby/issues/2
• One final ambiguous "Object reference not set to an instance of an object” exception being thrown in the logs which I need to identify and squash.

I'm quite shocked at the extent to which what Emby is publishing in their git repo differs from what's coming out of their releases. For instance:

• .NET Core App Host application isn't published at all.
• The project files and NuGet setup are in no way set up for .NET Core.
• There are hard dependencies on things that do not target .NET Core.

It's so much more than missing build scripts as we had previously thought!

Also I discovered that ThirdParty/emby/Emby.MediaEncoding.dll is not open source and that's not even part of premiere, it's integral to the functionality of the core server.

[koopjm]

I've been following this for a little while now, got interested in Emby since it was advertised as open and I run on an arm based platform w/ internal/non-standard decode/encode HW.

Just a crazy thought on the "new solution" topic above. I've dabbled in Kodi on occasion, how bad would it be to make a server version of it?

[benpye]

As far as I remember, Plex started as a server version of Kodi.

Also, I have ended up forking the Emby repo, I am not happy with the current state of affairs with Emby and so would like to try and move away to a fully open source fork. I have taken the last fully open source commit of Emby and gotten it building as a netstandard20 project.

I have pulled in the dependencies Emby provides too as I don't want to rely on them going forward, I do need to make attribution and licensing clearer however as some of these components are MIT licensed rather than GPL. I still need to pull in and reproduce the build system for the front end JavaScript and HTML.

If interested you can check out the fork at https://github.com/benpye/Emby , as I have included some other non GPL projects from Emby (MIT licensed) I do need to make sure the licensing is clearer.

[nvllsvm]

Looks like the Emby team has completely fucked over open source fans - they've closed up critical components in the latest release. https://github.com/MediaBrowser/Emby/issues/3075#issuecomment-406841199

[voxadam]

It looks like this has been rectified.

https://github.com/MediaBrowser/Emby.Common

[nvllsvm]

@voxadam - License is still ambiguous, hopefully just an oversight https://github.com/MediaBrowser/Emby.Common/issues/1

[voxadam]

I don't disagree; I was only commenting on the most recent issue.