I have a question about commercial use in my application.
I am using the FFmpeg or the vlc command line to convert a video to mp3,IF the user want to convert.
My question is.
I don’t distribute the vlc or the FFmpeg with my application,and i don’t change anything in the source code of FFmpeg or Vlc.
I will prompt the user to download the FFmpeg or the vlc from the web,and i will use them as external for conversion…
Will be legal issues ?
i hope my question is clear.
What I understood is that most parts of ffmpeg are LGPL except certain parts like H.264 and AAC. So if you don’t use those, you should be fine to include ffmpeg if it’s complied correctly. (See: https://www.ffmpeg.org/legal.html)
If you need above functions, then there seems to be a loophole by not using the libraries but shelling out to binaries and tell the user in the about box how to get the used version of ffmpeg and how it was compiled.
One thing you could do is use one of the static binaries from evermeet.cx or ffmpegmac.net and explain to your users that you included that version and that the user can download and overwrite his own version with yours.
(disclaimer; this is how I understand it. You should verify yourself)
[quote=229850:@Loannis Kolliageorgas]I have a question about commercial use in my application.
I am using the FFmpeg or the vlc command line to convert a video to mp3,IF the user want to convert.
My question is.
I don’t distribute the vlc or the FFmpeg with my application,and i don’t change anything in the source code of FFmpeg or Vlc.
I will prompt the user to download the FFmpeg or the vlc from the web,and i will use them as external for conversion…
Will be legal issues ?
i hope my question is clear.[/quote]
The ambiguity about GPL / LGPL and what is / isn’t allowed is one reason I avoid any GPL code for commercial usage
If you are NOT including the GPL portion of the code IN your app, you may call out to it. Otherwise, NO commercial app written and delivered on Linux would be possible. So long as you simply tell the user that to USE these functions within your app that they must download and install the proper GPL apps / tools / libraries, you are not violating either the letter or the intent of the GPL 2 or 3.
I’m not a lawyer, but I have paid lawyers over the years to answer just this question (we’ve been shipping commercial apps on Linux since 1994 - kernel 0.99pl12).
On the other hand, LGPL is defined specifically to allow you to include the APIs provided in your non-GPL application. Again, without that definition, no app (including Xojo) would be able to be shipped on Linux as closed source since so many external libraries and APIs are used (LibC, X11, GNOME, gmp, ice, etc.).
Whether you have consulted a lawyer or not doesn’t preclude GNU or the FSF etc from litigating.
It may reduce their chances of winning.
Personally I avoid GPL because I dont want to have to defend against any such action in court.
I couldn’t afford it.
IMHO, and I’m also not a lawyer, BSD, MIT, Apache and all other BSD style “free use for any purpose” licenses are to be preferred because they are decidedly unambiguous about whether you can use that code in your software
GNU obviously has their own take on interpretation of various aspects of how proprietary & GPL bits are combined
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLInProprietarySystem
LGPL is a different beast - by its very design
To quote that section and add further validation to what I have found to be legally true:
[quote]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 programsbut 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.[/quote]
This is exactly what I was referring to above. So long as your program only calls or executes the existing GPL-covered tool, you are not bound by the GPL with regard to your application and code.
A very important segment:
Don’t put GPL code in your bundle because then they effectively become the same program in the eyes of the GPL. Instead install it as part of a separate bundle that your program calls.
My point was to tell the user of your application that if they want to use that functionality, they must download and install the package (ffmpeg in this case). If it’s installed, then your program call out as you do normally. This way, you don’t include any of the GPL components in your package / app.
[quote=229928:@Tim Jones]To quote that section and add further validation to what I have found to be legally true:
This is exactly what I was referring to above. So long as your program only calls or executes the existing GPL-covered tool, you are not bound by the GPL with regard to your application and code.[/quote]
As long as your code could plausibly work with a suitably written alternative
ie/ something that is NOT FFMpeg but maybe provides the same API I’d guess you’re OK
But, who has the funding to find out should FSF, GNU, etc decide to take action
I believe that you’re missing the point - so long as the non-GPL app does not COMPILE the GPL code into itself and so long as the GPL tool is not built into the non-GPLd app, the app author is covered. So it should go something like this:
- My App Provides functions A, B, and C natively.
- If you the user have GPL tool GPLApp1 installed, my app is enhanced and now provides functions D and E
- If you the user have GPLApp2 installed, my app if further enhanced now provides functions F and G
- If you the user don’t have external packages GPLApp1 or GPLApp2 installed, you can retrieve their Open source versions from http://someopensourcesite.org.
Under these circumstances, your app is safe. I HAVE paid lawyers and spoken with GPL Jesus himself, Richard Stallman, and his apostles at the FSF about this very scenario.
No need to fear GPLd code under these circumstances.
Right
Having the app allows it to be enhanced - which isn’t quite what the author is asking
If the OP’s application REQUIRES ffmpeg or vlc, both GPL’d, to do anything useful and cannot do anything useful otherwise he’s likely hosed and has to be GPL
This is what i get from the official page of vlc legal page
What are the usage restrictions for VideoLAN software?
Short answer: there are none.
You can use the software in the way you want (within the boundary of law), for personal, educational, research, military, governmental, professional purpose or any other way...Like Tim say.
My application only provide the convert method IF the user have the mentioned software installed.
IF NOT then i just prompt the user to download one of this applications or (Builded library) to provide the convert.
IF the user don’t want to download to extend mt application,then my application work perfect as is without conversion.
VLC have open source code if any development want to use it,but still i don’t use the source code just the builded application from them.
VLC now is the alternate software to Perian and most users have installed.
Notice
IF i want to distribute the the vlc with my application then.
How do I redistribute a piece of VideoLAN ?
You should refer to the GPL license to do so, and notably its 3rd paragraph.
One of the easiest way to conform to the GPL is to accompany the product you want to distribute with its sources.
For example, if you plan to distribute the latest binary version of VLC on a DVD-ROM, you should also include the VLC source code and the source code for the underlying included libraries on the same media.@Loannis Kolliageorgas - you understand the situation perfectly. Your use of VLC and ffmpeg as “additional” external options to your app fall within the acceptable use guidelines of the GPL.
Things like x264, aac, MPEG etc are not just free of licensing. However…
I think… (<- My disclaimer.)
The FFmpeg project maintains several libraries like libavcodec, libavformat, libavfilter, libswscale and some more. Depending on how you compiled it, they fall under LGPL or GPL.
If you want to embed/link into these libraries, these LGPL/GPL licenses apply.
FFmpeg also offers a cli tool/wrapper called ffmpeg (lowercase ‘ff’). If you use this CLI externally (you call it via the Shell), those rules do not apply.
There are quite a bunch of posts about this on ffmpeg.org/pipermail. Here is an example: https://ffmpeg.org/pipermail/ffmpeg-user/2011-August/001854.html
So you should be fine if you Shell to ffmpeg. Just as you are allowed to Shell out to any other program that is already on the customer’s computer. (Excel, Photoshop, Final Cut Pro, whatever)
The thing is, if the user doesn’t have this specific program installed already, you can’t just simply include it (like you cannot simply include Excel, Photoshop, FCP etc. with your App)
However, you are allowed to distribute an ffmpeg build. As long as you supply the source and compile instructions with it that you used for the build.
What you also can do is check if the user already has the correct version installed and if not, tell them how to install it.
Now the ffmpeg cli tool is pretty complete but less powerful than using the libraries directly.
If you want that and you need parts that require licensing (x264, aac etc.), then just license them.
For example; You can contact CoreCodec (.com) for x264 licensing. I understand that the pricing ranges from ~5-10% (of your commercial App price) per copy or less when it’s volume. I don’t know what rules they have but I guess it also depends on your App.
Their website mentions a minimum of xx units but I’ve heard that you can negotiate that away/down depending on your App and volume.
I’m not sure about aac licensing pricing but I assume it’s a lot less. See here: http://www.vialicensing.com/licensing/aac-faq.aspx
I think the MPEG LA fees are not even considered below 1M units and when above, it’s a few cents I believe.
But for everything above, please do your own research.
So, a Mac application cannot simply have ffmpeg in the Resources folder within the app? Darn…
When initiating an app I made, I look at several locations:
When not found I show a message that the user needs to download ffmpeg and place it in the Applications folder. I provide the link to the ffmpeg website.
But I would rather embed it in the app. So that the user isn’t bothered with the extra step installing it.
You can provide the package, you just can’t embed it; so include the default FFmpeg package part of your ZIP/DMG. No one in the M&E industry has an issue with installing separate packages to get tasks done.