Commercial gstreamer-based application
Locked
 
|
Hello, everybody!
I wonder if I could make my own gstreamer plugin under commercial license? And will I be able to use commercial license for gstreamer-based application (e.g. video player)? Will I have any restrictions such as using only self-written plugins for gstreamer and not using plugins from common packages (gst-plugins-bad, gst-plugins-good and so on)? Under "commercial license" I understand mainly that source code of my plugin and application will not be opened. Thank you! |
Re: Commercial gstreamer-based application
|
|
On Wed, Sep 28, 2011 at 10:56 PM, Siber <[hidden email]> wrote:
> Hello, everybody! > I wonder if I could make my own gstreamer plugin under commercial > license? And will I be able to use commercial license for gstreamer-based > application (e.g. video player)? Will I have any restrictions such as using > only self-written plugins for gstreamer and not using plugins from common > packages (gst-plugins-bad, gst-plugins-good and so on)? Under "commercial > license" I understand mainly that source code of my plugin and application > will not be opened. > Thank you! The core gstreamer libs, and the -base, -good and -bad plugins should all be licensed under the LGPL, which would allow you to make proprietary software based on it, as long as you don't modify the gstreamer sources. BTW, use the term "proprietary"; the term "commercial" is misleading. It's possible to write commercial software that is also free software; for example, Red Hat Enterprise Linux. What you mean to say is that you intend to write non-free software. If your software merely *uses* gstreamer, you can license it under any license you want (the LGPL gives you that right). But any modifications you make to gstreamer must be released under the LGPL or GPL. This is *NOT* necessarily the case if you use plugins from gst-plugins-ugly. "Ugly" contains plugins under other licenses. If you *either* use *or* modify any plugins from gst-plugins-ugly, you will need to comply with the license terms of each plugin you use; those license terms may differ from the LGPL in surprising ways. You might also need to be cognizant of some well-known software patent issues associated with certain gst-plugins-ugly plugins. That isn't to say that all of the other plugin packages are immune to software patents, but just that the community consensus so far is that we don't really see there being any credible, publicly-known patent threat related to the use of the -base, -good, or -bad plugins (and you can also infer a similar level of weak "community consensus" regarding the licensing terms of said plugins, and the implications thereof.) None of this should be taken as legal advice, and especially if you are considering doing a large and visible project with a high dollar value associated with it, you should hire a lawyer and go to great pains to make sure that you are not violating any copyright licenses or software patents in any country where you intend to do business. I am only speaking in generalities, and my recommendations to you are largely based upon my limited knowledge of software licensing and the patent landscape in the United States. The situation might be very different elsewhere. Lastly, I am kind of glossing over the issue of adding your own, completely new plugin. There is ongoing debate about the meaning of the term "derivative work", and there is no clear process for determining whether any given piece of code is a derivative work of any given third-party copyrighted body of work. Therefore you shouldn't assume that, just because of some technical detail, your code wouldn't be considered to be a derivative work of gstreamer. This is relevant because, if the software you write *is* deemed a derivative work of gstreamer, then you would be required to release your derived work under the LGPL or GPL (the LGPL lets you choose between these two licenses; you can always move an LGPLed codebase to GPL, but never the reverse.) Instead of guessing or assuming, it's better to ask a lawyer. But if you're cheap, you can also read some essays by Richard Stallman to hear one perspective, or search the internet about modifying LGPLed software for the perspectives of many other developers. For example, http://answers.google.com/answers/threadview/id/439136.html I know you want licensing to be as abstract and clear-cut as coding itself, but the fact is that the legal apparatus is a complicated machine that requires intricate knowledge to accurately traverse. You wouldn't want a lawyer untrained in programming to write your gstreamer plugin; by the same token, a lawyer wouldn't want a programmer untrained in law to make legal decisions for themselves. It goes both ways. Do what you're good at, and defer the rest to a qualified expert. The free software community (that is, people who write and contribute free software to the public) often tries to establish guidelines and best practices that help us avoid legal fees by taking a safe, peer-evaluated, often legally-evaluated route towards developing free software. This is all in the spirit of sharing: someone pays for a lawyer to make a legal determination (such as a lawyer belonging to the Software Freedom Law Center), and in return, the lawyer shares their opinion with everyone, in the hopes that their opinion will help save the hard-earned money of free software contributors. If you were writing free software, you could rely upon those guidelines. But since you seem to want to proprietize your software, I am going to rather brusquely shrug you off now, after having given you this much advice, and leave you to your fate. Good luck, Sean > > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Commercial-gstreamer-based-application-tp3854185p3854185.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Commercial gstreamer-based application
|
|
In reply to this post by Siber
Sure, that's exacly what Fluendo does since 2007 with our codec pack and DVD player application.
Best regards, Julien MOUTTE C.T.O. FLUENDO Influencing the Multimedia World San Francisco, USA & Barcelona, SPAIN Spain: +34 933 175 153 United States: +1 415 773 5353 www.fluendo.com Please consider the environment before printing this e-mail. On Thu, Sep 29, 2011 at 4:56 AM, Siber <[hidden email]> wrote: Hello, everybody! _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Commercial gstreamer-based application
|
|
In reply to this post by Sean McNamara-4
Hi Siber,
Just wanted to clarify on some of the issues Sean touched upon. In general the GStreamer community choose the LGPL v2.1 to allow people to write both proprietary applications and proprietary plugins. As far as GStreamer is concerned there is no different between the two, they are both software linking to the core of GStreamer. There is a legal FAQ here: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-legal.html It contains a set of legal questions that where answered by the FSF lawyers some time ago, trying to make the legal implications of using GStreamer clearer. The most important thing you need to be careful of is distributing your application along with GPL licensed code, for instance some of the GPL licensed plugins in -ugly or -bad. GStreamer does not function as a licensing barrier. So stick with GStreamer-plugins-base and -good and cherry pick as needed from bad what you need after checking the license of a given plugin. Be also aware that the LGPL and GPL terms only apply to distribution, not use. So if for instance you provide a proprietary application which is going to use any plugins provided by a system install of GStreamer (including GPL ones, like what is on most Linux distributions), that is fine, it only becomes an issue if you distribute them together. There are a lot of companies distributing GStreamer plugins and/or applications on a commercial basis these days so the general setup is well proven and accepted. By as Sean says, it is always good to get your own legal advice on these kind of things, just for peace of mind if nothing else. Christian n Wed, 2011-09-28 at 23:41 -0400, Sean McNamara wrote: > On Wed, Sep 28, 2011 at 10:56 PM, Siber <[hidden email]> wrote: > > Hello, everybody! > > I wonder if I could make my own gstreamer plugin under commercial > > license? And will I be able to use commercial license for gstreamer-based > > application (e.g. video player)? Will I have any restrictions such as using > > only self-written plugins for gstreamer and not using plugins from common > > packages (gst-plugins-bad, gst-plugins-good and so on)? Under "commercial > > license" I understand mainly that source code of my plugin and application > > will not be opened. > > Thank you! > > The core gstreamer libs, and the -base, -good and -bad plugins should > all be licensed under the LGPL, which would allow you to make > proprietary software based on it, as long as you don't modify the > gstreamer sources. BTW, use the term "proprietary"; the term > "commercial" is misleading. It's possible to write commercial software > that is also free software; for example, Red Hat Enterprise Linux. > What you mean to say is that you intend to write non-free software. > > If your software merely *uses* gstreamer, you can license it under any > license you want (the LGPL gives you that right). But any > modifications you make to gstreamer must be released under the LGPL or > GPL. This is *NOT* necessarily the case if you use plugins from > gst-plugins-ugly. "Ugly" contains plugins under other licenses. If you > *either* use *or* modify any plugins from gst-plugins-ugly, you will > need to comply with the license terms of each plugin you use; those > license terms may differ from the LGPL in surprising ways. You might > also need to be cognizant of some well-known software patent issues > associated with certain gst-plugins-ugly plugins. That isn't to say > that all of the other plugin packages are immune to software patents, > but just that the community consensus so far is that we don't really > see there being any credible, publicly-known patent threat related to > the use of the -base, -good, or -bad plugins (and you can also infer a > similar level of weak "community consensus" regarding the licensing > terms of said plugins, and the implications thereof.) > > None of this should be taken as legal advice, and especially if you > are considering doing a large and visible project with a high dollar > value associated with it, you should hire a lawyer and go to great > pains to make sure that you are not violating any copyright licenses > or software patents in any country where you intend to do business. I > am only speaking in generalities, and my recommendations to you are > largely based upon my limited knowledge of software licensing and the > patent landscape in the United States. The situation might be very > different elsewhere. > > Lastly, I am kind of glossing over the issue of adding your own, > completely new plugin. There is ongoing debate about the meaning of > the term "derivative work", and there is no clear process for > determining whether any given piece of code is a derivative work of > any given third-party copyrighted body of work. Therefore you > shouldn't assume that, just because of some technical detail, your > code wouldn't be considered to be a derivative work of gstreamer. This > is relevant because, if the software you write *is* deemed a > derivative work of gstreamer, then you would be required to release > your derived work under the LGPL or GPL (the LGPL lets you choose > between these two licenses; you can always move an LGPLed codebase to > GPL, but never the reverse.) Instead of guessing or assuming, it's > better to ask a lawyer. But if you're cheap, you can also read some > essays by Richard Stallman to hear one perspective, or search the > internet about modifying LGPLed software for the perspectives of many > other developers. For example, > http://answers.google.com/answers/threadview/id/439136.html > > I know you want licensing to be as abstract and clear-cut as coding > itself, but the fact is that the legal apparatus is a complicated > machine that requires intricate knowledge to accurately traverse. You > wouldn't want a lawyer untrained in programming to write your > gstreamer plugin; by the same token, a lawyer wouldn't want a > programmer untrained in law to make legal decisions for themselves. It > goes both ways. Do what you're good at, and defer the rest to a > qualified expert. > > The free software community (that is, people who write and contribute > free software to the public) often tries to establish guidelines and > best practices that help us avoid legal fees by taking a safe, > peer-evaluated, often legally-evaluated route towards developing free > software. This is all in the spirit of sharing: someone pays for a > lawyer to make a legal determination (such as a lawyer belonging to > the Software Freedom Law Center), and in return, the lawyer shares > their opinion with everyone, in the hopes that their opinion will help > save the hard-earned money of free software contributors. > > If you were writing free software, you could rely upon those > guidelines. But since you seem to want to proprietize your software, I > am going to rather brusquely shrug you off now, after having given you > this much advice, and leave you to your fate. > > Good luck, > > Sean > > > > > -- > > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Commercial-gstreamer-based-application-tp3854185p3854185.html > > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Thanks all who has written here, it helped and clarified a lot! Thanks for your attention!!!
|
Re: Commercial gstreamer-based application
|
|
In reply to this post by Julien Moutte
Hi,
we have a mp4 video which is playing by vlc. But gstreamer with fluvasink crashed. I use: gst-launch playbin2 uri=file:///daten/Media/FREDDIE-doppel-full-hd-mpgstr.mp4 Video: Resolution: 3840 x 1080 Codec: H264 - MPEG-4 AVC (part 10) (avc1) Frames: 24 Audio: MPEG AAC (mp4a) 48000 Hz Bitrate: ~12000 kb/s Dropbox link for download: http://dl.dropbox.com/u/35129960/FREDDIE-doppel-full-hd-mpgstr.mp4 Could you help us? Thanks, -- Andreas Rödig null821 media services Weberstr. 2 86462 Langweid/Foret Tel.: 0821 / 800 60 -34 Fax.: 0821 / 800 60 -55 Email: [hidden email] Web: www.null821.de ________________________________________________________________ null821 media services GbR Ralf Walz, Alexander Mohr Weberstraße 2, 86462 Langweid/Foret Steuernummer: 102/181/07201 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
It's probably better not to use playbin but to build pipeline manually, e.g.:
filesrc location=file:///daten/Media/FREDDIE-doppel-full-hd-mpgstr.mp4 ! <decoder component name> ! <video sink component name> This way you will get an opportunity to change some of the components in the pipeline and see how it reflects on the result, whether it still crashes or not. 12 октября 2011, 18:18 от Andreas Rödig [via GStreamer-devel] <[hidden email]>:
|
Re: Commercial gstreamer-based application
|
|
In reply to this post by Andreas Rödig
On Wed, Oct 12, 2011 at 10:17 AM, Andreas Rödig <[hidden email]> wrote:
> Hi, > > we have a mp4 video which is playing by vlc. But gstreamer with fluvasink > crashed. > > I use: > gst-launch playbin2 > uri=file:///daten/Media/FREDDIE-doppel-full-hd-mpgstr.mp4 > > Video: > Resolution: 3840 x 1080 > Codec: H264 - MPEG-4 AVC (part 10) (avc1) > Frames: 24 > Audio: MPEG AAC (mp4a) 48000 Hz > Bitrate: ~12000 kb/s > > > Dropbox link for download: > http://dl.dropbox.com/u/35129960/FREDDIE-doppel-full-hd-mpgstr.mp4 Wow, that's a BIG video (resolution). If you're using fluvasink (and fluvadec), you'll probably need a lot of free video RAM. That seems to be a downside of hardware acceleration such as VDPAU. I had a similar problem playing a 1280x720 H.264 video with fluvadec and fluvasink on an NVIDIA GPU with only 128 MB of video RAM. It crashed until I disabled X's Composite extension to free up some video RAM. Even after I got it working, 128 MB was just barely enough. If you're using an NVIDIA GPU, you can use the nvidia-smi program to see how much video RAM is available and in use. Matt _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Commercial gstreamer-based application
|
|
On Wed, Oct 12, 2011 at 11:20 AM, Matt Hurne <[hidden email]> wrote:
> On Wed, Oct 12, 2011 at 10:17 AM, Andreas Rödig <[hidden email]> wrote: >> Hi, >> >> we have a mp4 video which is playing by vlc. But gstreamer with fluvasink >> crashed. >> >> I use: >> gst-launch playbin2 >> uri=file:///daten/Media/FREDDIE-doppel-full-hd-mpgstr.mp4 >> >> Video: >> Resolution: 3840 x 1080 >> Codec: H264 - MPEG-4 AVC (part 10) (avc1) >> Frames: 24 >> Audio: MPEG AAC (mp4a) 48000 Hz >> Bitrate: ~12000 kb/s >> >> >> Dropbox link for download: >> http://dl.dropbox.com/u/35129960/FREDDIE-doppel-full-hd-mpgstr.mp4 > > Wow, that's a BIG video (resolution). If you're using fluvasink (and > fluvadec), you'll probably need a lot of free video RAM. That seems > to be a downside of hardware acceleration such as VDPAU. I had a > similar problem playing a 1280x720 H.264 video with fluvadec and > fluvasink on an NVIDIA GPU with only 128 MB of video RAM. It crashed > until I disabled X's Composite extension to free up some video RAM. > Even after I got it working, 128 MB was just barely enough. If you're > using an NVIDIA GPU, you can use the nvidia-smi program to see how > much video RAM is available and in use. I also just noticed that when I play the video in two different non-GStreamer-based video players on a non-Linux platform, the player shows the video length as 2:26, but stops playing the video at around 0:34. It seems like there is something wrong with the video itself. Matt _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |