Question about license for including AviSynth in my software.

[skaven65536]

Hi, I have some questions about license for AviSynth.

Our software takes a set of video files as input. We have added support for AVS files, because of user's requests. So, our program supports AVI files (via our own lib) and VOB, MKV, d2v etc. (by AviSynth, mostly by DirectShowSource and MPEG2Decode functions). We have added sample scripts, but for a lot of users it is difficult, to understand how to open VOB, for example, using Avisynth scripts. So, I want our program to generate this scripts automatically, so users don't need to know anything about AviSynth to use our program. We have two versions: free (not open-source) and commercial.

So, I have a set of questions:
Is it legal to include AviSynth setup files to distribution kit of our program (it will be installed automatically)? In free version? In commercial version? Of course, it will be some notes about usage of AviSynth on our website, etc.

Is it legal to include avisynth.dll or directshowsource.dll in distribution kit of our program (to use them without installation of avisynth)? In free program? In commercial program?

We don't have a plans to use any part of AviSynth source code, only files from it's distribution kit, or setup files.

Thanks.

[MfA]

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Or in other words, no one really knows.

The best you can get is some tacit non legally binding approval from some of the main developers, until they pipe in I would like to say that if you hid the presence of avisynth (ie. not having it's own shortcuts in the start menu for instance) I would find that in poor taste ... regardless of it's mention on the webpage.

[Fizick]

IMO, all it is legal (but I am not a lawyer).
Please read GNU GPL license and license terms of Avisynth (see v2.57 doc).

Seems, according to GPL, you must:
1. put with program distribution the full GNU GPL license text, and all Avisynth copyrigt notices (most simple is probably to re-disrtibute the Avisynth license.htm file)
2. Put to your web site the full source code of Avisynth to download (it is simple of possible options).

[skaven65536]

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
I would like to say that if you hid the presence of avisynth (ie. not having it's own shortcuts in the start menu for instance) I would find that in poor taste ... regardless of it's mention on the webpage.

Main idea of usage avisynth files (.dll etc) without installation is to prevent such thoughts of our users, when they will see AviSynth's folders & icons "Oh! AviSynth? WTF? I havent installed it. Maybe I should remove it?".
But now I agree with you, maybe full installation of AviSynth is better.

[Leak]

Main idea of usage avisynth files (.dll etc) without installation is to prevent such thoughts of our users, when they will see AviSynth's folders & icons "Oh! AviSynth? WTF? I havent installed it. Maybe I should remove it?".
But now I agree with you, maybe full installation of AviSynth is better.
Wouldn't including the full AviSynth installer inside your installer and running it after installing your program suffice, with an option to disable it's installation in case someone doesn't want it or already has AviSynth installed?

In case it's shipped on a CD you could also just put the AviSynth installer alongside your's and make it optionally run AviSynth's installer if it's in the same directory as your installer...

[Fizick]

Legal addition:

Please note, that Avisynth has no internal "MPEG2Decode" function.
It is from DGDecode plugin. And this plugin (like most other plugins) is under strictly GPL without Avisynth license exempion.
So, legally you may not dynamically link it with your program (even via Avisynth)

[IanB]

If you include both the installer .EXE and the source tarball files on your distribution media with an attribution readme.txt documenting where you downloaded these files, where to get updates and a summary of our licence you should be covered.

An appropriate mention of Avisynth would be appreciated. (sucking up never hurts ;) )

The installer is part of the product and under GPL also, so if you modify it, you will need to include the modified installer source with appropriate credit given.

If you are doing this as part of a commercial endeavour I advise you get a professional legal opinion to fully cover yourself.

[sh0dan]

@Fizick: Not necessarily so. If AviSynth is used via VFW, it is no different than using a VFW codec, and last time I checked, my software did not have to be GPL to use XviD.

[Fizick]

Well, it is illegal to DISTRIBUTE strictly GPL program (or plugin) with non-GPL program.
http://list.xvid.org/pipermail/xvid-devel/2003-April/002776.html
(But Avisynth has exeption)

[MfA]

Misconceptions about misconceptions from 2003 aren't really the best way to understand the GPL. Just read the license.

The only thing which is really unclear is what is the difference between "mere aggregation" and "combining two modules into one program"?. That's unclear because the GPL tries to be as strong and general as possible and it leaves it up to the courtrooms of the world to define what constitutes a work based on a GPL program.

[Fizick]

modern xvid license was created in that 2003 discussions.
http://www.xvid.org/FAQ.42.0.html#c44

[Guest]

Please note, that Avisynth has no internal "MPEG2Decode" function.
It is from DGDecode plugin. Nor does DGMPGDec have a "MPEG2Decode" function! But you are right about DGMPGDec licensing. It is full GPL.

[Fizick]

Mpeg2source

[sh0dan]

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
>>>I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?
You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too.

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and "incorporating" the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs--but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

If people were to distribute GPL-covered software calling it "part of" a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.


and....

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

>>>What is the difference between "mere aggregation" and "combining two modules into one program"?


Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.


I would say interfacing through a 3rd part OS API isn't exactly close. But it seems to be greyish country.

[Smetvid]

Now what if all your software does is write text files that can be read by AVISynth? Creating text files is not really a grey area is it?

Once the text files are created as *.avs a program then justs reads those back in as AVI files.

Either that or each script outputs a single image and that image is sent to your program to display what is going on at that certain frame. When you make changes or advance to another frame the program just runs the updated script and imports the new still image.

You of course are still using AVISynth but only in a automated fashion. None of the code or guts of the program are being touched at all.

I wouldn't think it would be all that much different then Adobe Premiere being able to open up AVS files. Except now the program can also write avs files and load them back in.

[Richard Berg]

I agree with sh0dan. It is comparable to a "an editor and a shell." When you run VI inside Bash it's an integrated user experience, but there is no doubt that they are separate programs communicating by a standard OS mechanism.

Like the FAQ says, the main thing is to make sure users know that two separate programs are at work, and one of them (Avisynth) is free software that entitles them to certain rights the other program does not.

[MfA]

I wouldn't think it would be all that much different then Adobe Premiere being able to open up AVS files. Except now the program can also write avs files and load them back in.
Adobe premiere isn't shipped with avisynth, so it's moot.

I'd say that if avisynth is installed as a hidden component then the interface stops being relevant ... it is presented as a single program.

[DonQ]

IMHO to be on safe side, just make your installer optionally chainload full Avisynth installer at the end of install (if it is not installed already). Of course you should include some information screens about why is Avisynth needed (support for specific formats) and why is it installed separately (it is different product).

[Leak]

IMHO to be on safe side, just make your installer optionally chainload full Avisynth installer at the end of install (if it is not installed already).
That's another argument against just installing it silently - don't just unconditionally overwrite an existing (and possibly newer) installation.

np: Vladislav Delay - Whistleblower (Whistleblower)

[Fizick]

seems, hcencoder includes dgdecode.... a very simply. ;)
(probably under special permission)

[Smetvid]

Adobe premiere isn't shipped with avisynth, so it's moot.

I'd say that if avisynth is installed as a hidden component then the interface stops being relevant ... it is presented as a single program.

Fine then just make the installer inform the user that they will need the latest version of AVISynth and provide a link to the website. If the user is connected to the internet the installer could be made to automatically download AVISynth and install it for you. That way it wouldn't be included on the disk.

Besides how can commercial versions of Linux sold at Best Buy or any other store contain certain applications or parts of code that are under GNU? Isn't Linux itself under GNU even though commercial versions are sold?

[Leak]

Besides how can commercial versions of Linux sold at Best Buy or any other store contain certain applications or parts of code that are under GNU? Isn't Linux itself under GNU even though commercial versions are sold?
Where does the GPL say you can't sell GPLed software?

It's all about access to the source code and not about restricting your ability to sell something...

(Although paying for those commercial versions usually has more to do with getting paid-for support for them as opposed to having a printed manual and installation media...)

np: Vladislav Delay - Stop Talking (Whistleblower)

[Smetvid]

My whole point wasn't that Linux couldn't be sold but that it was being sold while some of it's parts or included software is still covered under GNU and included in one package.

I also know of one major NLE that uses FFmpeg as an export module for certain web formats. FFmpeg is a open source program but this NLE is very far from open source. The setup installs both the NLE and FFmpeg so it is included on one disk. The setup or NLE also never really informs the user that FFmpeg is being used until you export using FFmpeg. I'm sure this company had enough lawyers to make sure things were ok to use opensource programs from another program as long as the code itself isn't touched or linked which is the case.

I don't know if any of this means anything or not but I just thought I would ask.

By the way the company I'm talking about is Avid.

[Fizick]

Seems FFMPEG is not GPL but LGPL.
And probably it is used as independent FFMPEG.EXE file? (or not ?)
anyway it may not be distributed 'silencely'.