Please provide original source, build scripts and clear license information for web interface files

[rbalint]

I see the conversation in https://github.com/ejurgensen/forked-daapd/pull/538 which pulled the in files but unfortunately shipping only minified and processed .js files are not compatible with GPLv2 because those are not in the "preferred form" of the work:

From https://www.softwarefreedom.org/resources/2008/compliance-guide.html#x1-170004.2.2 :

"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."

I can't package package the web interface in Debian until this issue is resolved while I'd like to, and forked-daapd is not distributable under GPLv2 this way anyway.

Disclaimer: I'm not a lawyer and this is not a legal advice.

[ejurgensen]

Thanks, this will of course be a high priority

[rbalint]

@ejurgensen is there any chance this could be resolved soon? I'd like to update forked-daapd to work with latest FFmpeg and I'd prefer not dropping the web interface from the original tarball. From my POV simply merging the https://github.com/chme/forked-daapd-web project to forked-daapd seems reasonable and would also solve the source availability problem.

[ejurgensen]

I think @chme is on a longer vacation or something, so that is why it is taking some time. If merging forked-daapd-web into the source will solve the issue I can try and do that as a quick solution until @chme gets back. Just to be clear, the solution you suggest is to have a copy of the project in say /web-src? And I would probably also have to adjust Makefile.am to have the source included in distro tarballs - right?

[rbalint]

@ejurgensen @chme I'm not sure how you feel about that but IMHO the cleanest solution would be merging the whole web interface project into forked-daapd and building the web interface here without having the built/minimized files in the git tree.

I understand that building the web interface pulls in extra optional dependencies, but it would be much cleaner and verifiable than the current state and make dist could still pre-build the interface for those you would like to please with the pre-built web interface.

[ejurgensen]

I would be ok with that, but I think we have to wait for @chme to be back. It would require a bit of work (I'm thinking adjustments of makefiles, configure.ac and docs), and I would like to have him on board on that.

[chme]

Apologies for the late response ... I am okay with merging the web interface into forked-daapd. But even after searching for a while, i have no clue how configure/make need to be adjusted and how this will work ... are there examples that can be used as a blueprint?

[chme]

As i understand it, we have to options:

1. Merging the web interface into forked-daapd and adapt the build scripts to build the minified javascript (and css?) files.
2. Keeping the projects separate and include unminified versions of the javascript files in forked-daapd. These unminified files will not be the original source code, but will be human readable and editable.

I only found lengthy discussions on the internet from what i take, that option 1 is desired but option 2 is acceptable.

If option 2 is not enough to package forked-daapd, merging the web interface will also mean to include all the dependencies (node_modules directory). Otherwise the build would require to download them, which i think is not allowed.

You can see in https://github.com/chme/forked-daapd/tree/web-src what the result would look like (24,545 changed files with 2,752,037 additions and 2 deletions). The branch is work in progress. At its current state it allows building the web interface from the web-src directory with npm run build, but the build scripts need more work (e. g. to not delete the admin web interface).

So what should it be, merging the projects or including unminified files?

[ejurgensen]

Option 2 sounds fine. Those 24,545 files sound scary, of course. If build-time downloading isn't allowed I think it rules out option 1. If allowed, and it can be done sort of like antlr3 and gperf I suppose it would be ok - though it does add quite a requirement to anyone wanting to build the whole thing.

I'm not myself able to build the web interface on Ubuntu 16.04 (something with the node version, I think). I could probably fix it, but I don't really want to invest too much time in that part. So if we go with option 1 I think you will have to join me here with commit access, @chme, because I won't be able to support/maintain when it comes to building those parts.

Is there an option 3 which would be to have a separate forked-daapd-web Debian package with chme's project as upstream? Then the packaging of that might be the same as other Vue-based projects (if there are such in Debian?).

@rbalint I think we really need you to pitch in with as concrete recommendations you can give. In the end you know best what will work for Debian.

[rbalint]

@chme @ejurgensen from Debian's POV (and IMO) Option 1. would be preferred. It is true that package builds are allowed to access the Debian mirrors thus pulling in extra dependencies during the build is not possible on official Debian build servers, but forked-daapd is free to provide a script for installing dependencies of the web interface. This script wouldn't be used in the Debian build, but build-dependencies would be expressed as packages as build-dependencies when all of them become available in Debian.

As I understand Option 2. that would mean including not minified but bundled JS source which is not the original source and this type of bundling is not allowed in Debian - nor embedding all the dependencies as it is done in the scary branch :-).

Option 3., packaging the web interface separately is technically doable, but per the web interface's README.md it "requires forked-daapd built from git" which sounds like very strict versioned inter-dependency between the projects and if the web interface is accepted by the forked-daapd project it probably should be just merged - not snapshotted like it is done currently.

Unfortunately many dependencies of the web interface seem to be missing from Debian which is not surprising, the JavaScript ecosystem consists of many very small projects, thus the web interface in its current form probably won't be included in Debian very soon. :-( Thinking long-term I still believe that merging the two project (without embedding the deps) would be the best, Debian can then ship the sources for the web interface and users can even build it locally. Maybe that would motivate people to package the dependencies and it can then be shipped by default.

[chme]

Too bad, that it is not possible to include the web interface.

I guess, this applies to the player web interface (introduced in v26.1) and the admin web interface (introduced in v26.0)? The admin web interface does not make use of a build system, but it uses vue.js, axios.js, buima and fontawesome (to see which files belong to the admin interface its best to look at the source for v26.0: https://github.com/ejurgensen/forked-daapd/tree/26.0/htdocs).

[ejurgensen]

It seems difficult to find a simple solution to this problem. @rbalint the lastest Debian version is 25.0, and there have been many improvements and fixes since then, so my suggestion is that I prepare a new release 26.3 (there are a few good fixes since 26.2), and that you update Debian with that, but without the web interface. Would that be ok?

Then hopefully we can find a way of including the web interface for the next Debian version.

[rbalint]

@ejurgensen sure