I am making a website (in a commercial context) where users can upload videos to our server
naturally that causes problems with browser compatibility. the solution would be to transcode them using FFmpeg on the server.
the problem is i have been reading on FFmpeg and it's license and i am very confused, does the use of FFmpeg on the server count as distribution ? and that is before talking about patented code.
if it is not possible to do it without risking the entire company in legal disputes. are there any alternatives that can be used ?
thank you very much
does the use of FFmpeg on the server count as distribution ?
No. "use" and "distribution" are specifically different things in a legal context. The FFmpeg license (LGPL) only limits distribution rights; it gives you the "freedom to run" (this is freedom 0) which means you can use it in any you want. That freedom is explicit and intentional.
and that is before talking about patented code.
As for patents: ask a lawyer.
are there any alternatives that can be used
Not really, most alternatives end up using FFmpeg internally.
I would like to build SaaS application (with free and not free tiers).
And I want to use one of the editors: ckeditor or tinymce.
I don't want to pay for it.
Can I legally use it?
Can I use it if I will make my client app (which using editor) - open source (MIT license)?
P.S.
CKeditor - GPL, LGPL, MPL
Tinymce - LGPL
From the CKEditor FAQ:
CKEditor is distributed under the GPL, LGPL and MPL Open Source licenses. >this triple copyleft licensing model is flexible and allows you to choose >the license that is best suited for your needs.
The GPL grants the recipients of a computer program the rights of the free >software definition and uses copyleft to ensure the freedoms are preserved, >even when the work is changed or added to.
The LGPL places copyleft restrictions on the program governed under it but >does not apply these restrictions to other software that merely link with >the program. The main difference between the GPL and the LGPL is that the >latter allows the work to be linked with a non-(L)GPLed program, regardless >of whether it is free software or proprietary software.
The MPL allows covered source code to be mixed with other files under a >different, even proprietary license. However, code files licensed under the >MPL must remain under the MPL and be freely available in source form.
From the Tinymce FAQ:
Are there any restrictions to using TinyMCE in my commercial
application?
Yes, there are restrictions including the following. All
copyright notices must be intact as Moxiecode Systems are the
copyright owners of the source code. You cannot use the source code in
your applications without complying with the LGPL. According to the
provisions of the LGPL, any modifications or add-ons you make to the
source have to be released for the community's benefit. We recommend
that you always contribute your changes back to the TinyMCE community,
regardless of the situation. If you start to make a lot of revenue
from using TinyMCE, please remember the time and dedication that has
been put into this by other developers, respect this and give credit
to those who deserve it.
As long as you don't mess with the source code you are fine to use it for your use case (own tinymce plugins are no problem regarding this license).
If i were you i'd would go for Tinymce.
I need to parse a MIB file for OIDs and alarm types. However, I can't use mibble as it is GPL licensed. Is there any other tool or sample code I can use to parse MIB files in Java?
Before dismissing Mibble totally, perhaps worth mentioning there are non-GPL options with it. Quoting http://www.mibble.org/doc/faq/license/#Q12
Q12: Ok, GPL doesn't work for me. Now what do I do?
The GNU GPL licensed version of Mibble may not work for everyone.
There are a number of ways to approach this:
Purchase a Commercial License - As an alternative to using the GNU GPL, a non-exclusive commercial license for Mibble can be purchased.
Use an Older Version - Versions 1.2 to 2.3 of Mibble were licensed under GNU GPL but with an exception allowing linking with non-GPL
code, effectively making the license LGPL. All these versions contain
bugs and are unmaintained, but they may still work for you.
Relicense to GNU GPL - Any code licensed under the GNU GPL may freely use the Mibble library. By relicensing your software (or only
the applications dependant on Mibble) under GNU GPL you may continue
using the latest version of Mibble.
We'd like to take an existing Linux base AMI, install our software on it, and make the modified AMI available publicly. What are the licensing implications of doing this? Our software is an open source bioinformatics tool, but does not use a GPL compatible license. I haven't been able to find any discussion of this in the Amazon documentation. They explain how to build a customized AMI from a public AMI, but no mention is made of any IP or licensing issues.
My concern is that the modified AMI would be a derived work, which I think would obligate us to license our software under a GPL compatible license.
Assuming you don't have any GPL code actually in your software, including it in the AMI would only require you to release your software under GPL if it was part of the terms specific to the AMI.
The part I am unsure about is if you would be required to supply the source code to all of the GPL software in the AMI, hopefully someone else can clarify this for you. The safest option would be to just release a package for the distribution and possibly a shell script to automatically install it and any necessary repositories.
Is there a particular reason why Firefox does not support playback of MP3 files in <audio> elements, only Ogg format?
Is it a licensing issue?
Are there any plans made for a possible future implementation?
Is it possible to develop an addon to support MP3 playback in <audio> elements?
Update October 2012: Wooohooo! Brendan Eich just announced on his blog that work for MP3 and H264 support in Firefox is underway. You can track the work on BugZilla: Support H.264/AAC/MP3 video/audio playback on desktop Firefox
Update February 2013: After much heavy lifting from Firefox developer Chris Pearce, this patch flips the switch to enable MP3, MP4, H.264, and AAC playback by default in HTML5 <audio> and <video> elements when running on Windows 7 and later. We should see some native web MP3 support in the next stable FF release.
Update April 2013: Woohooo! The latest stable Firefox has experimental support for MP3. To turn it on, type about:config in Firefox, find media.windows-media-foundation.enabled and set it to true. Restart Firefox, and you're all set; go to a site with HTML5 audio (e.g. my radio site) and you'll see Firefox is indeed playing the native MP3 and not resorting to a Flash fallback.
Update May 2013: At last! Firefox 21 was released today, and it includes native HTML5 MP3 support on Windows. I just verified it supports native MP3 audio out-of-the-box, provided your operating system supports it. I tested on Windows 8, but I believe this will automatically work on Windows 7 and Vista.
Update December 2013: Firefox 26 was released today, which gives native MP3 audio support for all versions of Windows going back to Windows XP.
The currently-accepted answer by Ian Devlin is obsolete. The new answer is: while Firefox has historically not supported native MP3 playback for licensing reasons, this will change in the future; we'll soon see a Firefox that plays MP3 natively via the HTML5 <audio> tag.
In March 2012, Mozilla did an about-face on this issue, stating publicly they'll support MP3 and H.264 in their native HTML5 implementation, provided the codec is already available on the end user's system.
In the linked article, Mozilla's director of research, Andreas Gal, makes the following public statements:
“We will support decoding any video/audio format that is supported by
existing decoders present on the system, including H.264 and MP3.
There is really no justification to stop our users from using system
decoders already on the device, so we will not filter any formats.
I don’t think this bug significantly changes our position on
open video. We will continue to promote and support open codecs, but
when and where existing codecs are already installed and licensed on
devices we will make use of them in order to provide people with the
best possible experience.”
This is in contrast to their previous position, which didn't attempt MP3 and H.264 playback even if the operating system supported it.
Bottom line: Firefox will eventually support MP3s in its HTML5 <audio> implementation. As of September 2012, I see no information about when this will happen. It appears to be under development for Firefox on Droid; I speculate we'll see support in desktop Firefox soon afterwards. Edit October 2012: Indeed, this speculation was correct: native MP3 and H264 playback in desktop Firefox is now under development.
Licensing issues: HTML5 video and H.264 – what history tells us and why we’re standing with the web and Mozilla defends Firefox's HTML5 support for only Ogg Theora video (despite their titles, they both also talk about MP3 licensing, albeit briefly).
All you can do is fall back to Flash and play them through that.
UPDATE: Native MP3 (and H264) support is now available on desktop Firefox version 20+
I'm using it to follow podcasts, and the occasional mp4 video, too.
If it doesn't work, there's an hidden option to enable:
about:config → media.windows-media-foundation.enabled → true
It also works with HTML5 YouTube
(that should anyway use webm, but might be more fine tuned for h264)
MP3 usually is a Fraunhofer/Thomson patents problem. They sell their licenses on the slightly shady mp3licensing.com domain.
Regarding patents (update 2016/6) (Wikipedia):
The basic MP3 decoding and encoding technology is patent-free in the
European Union, all patents having expired there. In the United
States, the technology will be substantially patent-free on 31
December 2017 (see below). The majority of MP3 patents expired in the
US between 2007 and 2015.
and
[...] patents expire 20 years after the initial filing date, which can be up
to 12 months later for filings in other countries. As a result,
patents required to implement MP3 expired in most countries by
December 2012, 21 years after the publication of ISO CD 11172.
As to patents finally expire in the US in December 2017:
Except for three patents, the US patents administered by Sisvel had
all expired in 2015, however (the exceptions are: U.S. Patent
5,878,080, expires February 2017, U.S. Patent 5,850,456, expires
February 2017 and U.S. Patent 5,960,037, expires 9. April 2017.
as well as
[...] the MP3 technology will be patent-free in the United States on 30
December 2017 when U.S. Patent 5,703,999, held by the
Fraunhofer-Gesellschaft and administered by Technicolor,
expires.
There is software circumventing those patents, like the LAME MP3 encoder, but they do that by distributing only in source code form.
The LAME developers state that, since their code is only released in
source code form, it should only be considered as an educational
description of an MP3 encoder
Then there are binary distributions of LAME, and, as you can easily see from the domain, they originate from Argentina. This can happen because MP3 patents are deemed invalid in many countries where the very concept of software patent was never legislated upon.
(I'd like to have an exhaustive list of countries, but the situation evolves quite rapidly, and I don't even known what side of the soft-patents divide my country stands in. That's not a level of uncertainty Mozilla wants to cope with)
Then again, Mozilla may have found THEIR way around the patent problem.
It's not perfect. (i.e. it leaves linux in a puddle of mud)
Andreas Gal, Mozilla’s director of research wrote:
(but the discussion revolved around B2G, really read the whole article to form an opinion)
“We will support decoding any video/audio format that is supported by
existing decoders present on the system, including H.264 and MP3.
There is really no justification to stop our users from using system
decoders already on the device, so we will not filter any formats,” he
wrote. “I don’t think this bug significantly changes our position on
open video. We will continue to promote and support open codecs, but
when and where existing codecs are already installed and licensed on
devices we will make use of them in order to provide people with the
best possible experience.”
So, from what I see:
On Windows and Mac (using, already licensed by the OS, dlls/dylibs) Mozilla could end up supporting MP3.
On Linux... I'd like to know. Maybe in selected countries, you'll end up installing some unlicensed libs and get away the way Audacity does.
There's a light at the end of a tunnel, but let's just hope it's not a fast approaching train.
Taken from Wikipedia, for MP3:
MPEG-1 or MPEG-2 Audio Layer 3 (or
III), more commonly referred to as
MP3, is a patented digital audio
encoding format using a form of lossy
data compression.
Taken for Ogg:
Ogg is a free, open standard container
format maintained by the Xiph.Org
Foundation. The creators of the Ogg
format state that it is unrestricted
by software patents and is designed to
provide for efficient streaming and
manipulation of high quality digital
multimedia.
Mozilla doesn't want patent issues, so Ogg was chosen as the better candidate.
It is possible to make such an implementation, so that Firefox can play mp3 in <audio> tag, but this won't be done because of issues I mentioned.
Sometimes politics, and other real world issues, dictate what gets implemented and what doesn't.
For Linux to turn on HTML5 streaming for MP3, MP4, H.264, and AAC, you got to set media.gstreamer.enabled to true into about:config!
Gstreamer is present in most, if not all, Linux distributions!
I believe that the Mozilla developers decided against implementing MP3 support, in order to avoid paying for patent licences from a number of organisations (Technicolor/Thomson Consumer Electronics, the Fraunhofer Institute, Alcatel-Lucent, Sisvel and potentially others, from what I can gather).
Decoding of various audio formats, including MP3 files, can now be done in modern browsers using JavaScript. http://audiocogs.org/codecs/mp3/
If a site used this kind of code (or a Firefox add-on did), Firefox would play MP3 files just fine.
As already said it's a patent problem. There are already plenty of open source MP3 decoders and encoders implementations (among them are LAME and FFmpeg), the problem is that to ship binaries somebody has to pay for the patent license. Here's a quote from LAME wikipedia article confirming this:
Like all MP3 encoders, LAME implements some technology covered by patents owned by the Fraunhofer Society and other entities. The developers of LAME do not themselves license the technology described by these patents. Distributing compiled binaries of LAME, its libraries, or programs that derive from LAME in countries that recognize those patents may be patent infringing.
The LAME developers state that, since their code is only released in source code form, it should only be considered as an educational description of an MP3 encoder, and thus does not infringe any patent by itself when released as source code only. At the same time, they advise users to obtain a patent license for any relevant technologies that LAME may implement before including a compiled version of the encoder in a product.
Mozilla obviously cannot afford to pay patents for any copy of Firefox that gets downloaded.
The two possible solutions are:
use external codecs already preinstalled in the system Firefox is installed in. This solution is the one that has been adopted when running in Windows as mentioned in this other answer. In this case, if the Microsoft MP3 codec is used, Microsoft is the one who paid for the patent license, cost which is part of the Windows license;
wait for MP3 patents to expire. The last one will probably expire on April 16, 2017 which is roughly 3 years and a half from now, but time passes steadily! Firefox 1.0 came out on November 9, 2004, which is more than 9 years ago!
That's why using patent free codecs is, from a user perspective standpoint, more desirable!
2017 UPDATE: patents have expired and open source projects are now starting to pick up MP3 support, e.g. Fedora. Let's hope Firefox does the same soon!
It's now 2020 and I got this issue on Firefox 83.0 on Windows 10. At first I thought my issue was with my profile being too old, from the Firefox 2.x era maybe, and that I got some leftovers such as the mentioned in other answers media.windows-media-foundation.enabled. Unfortunately that wasn't the case.
After searching for a bit in about:config for media decoding, playback and MP3 codec configurations I've found the culprit: media.ffvpx.mp3.enabled. It was set to true and that was preventing a podcast from playing, with Firefox complaining about not finding any compatible codecs to play an audio/mp3 file. Just toggled it false and refresh the podcast page and it started working fine.