Please include full copy of LGPL 2.1

[sebastinas]

src/vapoursynth/VapourSynth.h is licensed under the LGPL 2.1 or later. However, the full text of the LGPL is not included in repository nor the source tarball. Could you please include it?

[dwbuiten]

More to the point, should we include those headers at all? VapourSynth installs them anyway, and it feels "too AViSynth-y"?

@myrsloik @tgoyne Opinions?

[tgoyne]

Needing to have vapoursynth installed to build ffms2 would be pretty annoying. Is there any particular reason the header needs to be LGPL?

[myrsloik]

Not really, I just blindly copied and pasted the LGPL header everywhere. Tell me something saner to put on the top and I'll change it.

[tgoyne]

I think the simplest thing for ffms2 would be to just change the copy in this repo to MIT.

[myrsloik]

Ok

[dwbuiten]

Needing to have vapoursynth installed to build ffms2 would be pretty annoying. Is there any particular reason the header needs to be LGPL?

I more meant just the VapourSynth portion, but I guess this works too.

[sebastinas]

Looking through more of the files I also found src/avisynth/avisynth.h which is covered by GPL 2 or any later version. I can't find a copy of that version of the GPL in the repository/source tarball. As this file is also only used to build the plugin support I'm wondering if it would be possible to split the shared library into the library itself and separate sos for the plugins which link against the main library. These plugins then could be built whenever the appropriate header files are found. Just a thought as I'm currently updating the Debian package of ffms2 and wondering what we should do with the VapourSynth plugin support.

[tgoyne]

There's no real point in not building the vapoursynth plugin. It doesn't add a compile or runtime dependency on VS and doesn't meaningfully increase the library size. The Avisynth plugin isn't supported on Linux at all (due to that Avisynth itself doesn't work on Linux) but I guess the header is still in the tarball.

[sebastinas]

I'm not worried about a dependency on VapourSynth or the size. It's the symbol VapourSynthPluginInit that's added to the public ABI of the library that makes we wonder.

[tgoyne]

Why is that an issue?

[sebastinas]

Suppose that VapourSynth updates the plugin API and the init function is then named VapourSynthPluginInit2. This will mean that the symbol VapourSynthPluginInit will disappear from libffms2's ABI and VapourSynthPluginInit2 will be added. Will this cause the SONAME of libffms2 to be bumped?

About the context: I'm currently creating a symbols file for libffms2 (you can read about them here http://manpages.debian.net/cgi-bin/man.cgi?&query=dpkg-gensymbols). Rephrasing the question in this context: should the symbol generated for VapourSynthPluginInit be marked as optional since it might disappear at any point?

[qyot27]

At least in regard to avisynth.h, detecting its presence just isn't feasible - classic AviSynth is a Windows-only, MSVC-only project, and has no install rules that are congruent with buildsystems that put public headers in include/ under whatever the specified prefix was. The AviSynth docs even go so far as to tell plugin authors to include copies of avisynth.h or avisynth_c.h with the plugin sources.

However, this type of situation will almost certainly change when AviSynth+ gains cross-platform support. The issue there is whether it will need its own plugin stub (which it might if it's got high bit depth support by that point), and that would mean nothing in the case of the existing AviSynth plugin. A discrete avsplus stub probably wouldn't change anything about header detection anyway, given the convenience argument (the same reason why AvxSynth's headers are included despite it having a normal install routine).

To note, the c_plugin branch* can build the AvxSynth plugin, which is only relevant on non-Windows (and at least that would make the inclusion of the full GPLv2 text a need). So between that and avisynth.h it's probably a good idea to go ahead and include a copy of it now and get it out of the way.

• 'c_plugin' is a bit of a misnomer for *nix, since the AviSynth C-interface plugin is Windows-only. But the alternate buildsystem it uses is general purpose and can be used to build the library with or without the AvxSynth/VapourSynth plugin interfaces enabled (separately or as a single dual-interface plugin) on OSX and Linux.

[dwbuiten]

Suppose that VapourSynth updates the plugin API and the init function is then named VapourSynthPluginInit2. This will mean that the symbol VapourSynthPluginInit will disappear from libffms2's ABI and VapourSynthPluginInit2 will be added. Will this cause the SONAME of libffms2 to be bumped?

This will not happen. VapourSynth is designed specifically to avoid this.

Furthermore, it's not part of the actual API.

[tgoyne]

Even if VapourSynthPluginInit2 should prove necessary I don't think it'd be a big deal to keep the original around until the soname needs to be bumped for other reasons.

[sebastinas]

On 2013-12-05 15:51:01, Thomas Goyne wrote:

Even if VapourSynthPluginInit2 should prove necessary I don't think it'd be a big deal to keep the original around until the soname needs to be bumped for other reasons.

Okay, thank you. That helps.

Sebastian Ramacher

[sebastinas]

On 2013-12-05 13:58:54, qyot27 wrote:

At least in regard to avisynth.h, detecting its presence just isn't feasible - classic AviSynth is a Windows-only, MSVC-only project, and has no install rules that are congruent with buildsystems that put public headers in include/ under whatever the specified prefix was. The AviSynth docs even go so far as to tell plugin authors to include copies of avisynth.h or avisynth_c.h with the plugin sources.

I've been going through the avisynth repositories and tarballs to check the headers license. I've found several copies of the GPL, but none of these copies contains the exception given in the file header. Did I just miss a copy somewhere?

[myrsloik]

No, the exception is only mentioned in the header and nowhere else.