1

Without knowing anything I wrote a big application, almost 1 year coding.

It does Video/Audio such as softphone for commercial use (we sell it). I used a framework which was licensed under the LGPL, lesser Gnu Public License. Now before I release it to production, since I used the H.264 video codec and a 'LGPL' framework, what should I know and what should I do? Or I do not need to do anything? This is my employer releasing and selling the application, I just did my job making the application and getting it to run without crashing.

Do I need to apply for a license to court? Or do I apply for license to the framework programmers? How do I make myself valid before I let it go to my company management.

Follow up:

H.264 Encoder has GPL license

H.264 Decoder has LGPL license

Where do i buy encoder license? http://www.x264licensing.com/features

Where do i buy decoder license? http://www.mpegla.com/main/programs/AVC/Pages/AgreementExpress.aspx

How much does it cost me license? http://www.zdnet.com/blog/bott/h264-patents-how-much-do-they-really-cost/2122

Improve this question
5
  • 1
    I cleaned up your English the best I could. Sorry if I presumed anything.
    – Philip
    Dec 15, 2011 at 17:47
  • 6
    Wow. These questions should have been asked a year ago. You may be able to ship it as closed source (LGPL is pretty loose), but doing a year's worth of work and then asking these questions is ... stupid. Sorry, but that's the only word for it.
    – Peter Rowell
    Dec 15, 2011 at 18:02
  • Is the code from the LGPL framework statically or dynamically linked into the application you are selling? I.e., is the entire framework code used shipping as a separate DLL or SO?
    – jeff charles
    Dec 15, 2011 at 18:48
  • 4
    @Google Also, you have got to get a different name. Seriously dude.
    – Philip
    Dec 15, 2011 at 19:13
  • @jeff charles: yes separate SO entire framework.
    – YumYumYum
    Dec 15, 2011 at 21:01

2 Answers 2

Reset to default
1

1) If you're in a country where software patents are upheld, your company is required to pay licensing royalties for the use of the H.264 codec since you are a commercial user.

2) If you used a framework that was licensed under the LGPL, then it depends on how you used it. If you developed a module, or a library, or a plugin that the framework uses, then I believe you're good and don't have to do anything. If you have modified the framework itself and used that as a base for this application, then you are required to freely share the source-code for your derived work. (Which would make it hard to sell.)

Improve this answer
9
  • 1
    The way I read it (based on my total lack of legal training) is that if you modify the framework you don't necessarily have to share the source code of your derived work, but you do have to follow all the rules the LGPL sets forth about making the modified framework available. Roughly speaking, you just have to share the modified framework, not your application that uses it.
    – psr
    Dec 15, 2011 at 18:08
  • 1
    @psr. mmmm yeah, I think you're right. Except for "your derived work". If it's derived from LGPL, the LGPL license follows it. A LGPL framework can call your proprietary closed code, which isn't "derived". It's "linked", "called", or whatever. "Derived" means you expanded the original into the new one.
    – Philip
    Dec 15, 2011 at 19:06
  • 1
    @Google If it was LGPL, the license can really only be changed to GPL, which is more restrictive. You can't "unlicensed" code. That's blatantly breaking copyright law. And while I have a loose grasp of the open source licenses, I have only the merest idea about how H.264 licensing works.
    – Philip
    Dec 15, 2011 at 19:08
  • 1
    @Google - Once someone relinquishes some of their copyright privileges, they can't take them back. If they could, basically no one could ever use them safely. So if you comply with LGPL 1.0 you are good. Many open source licenses stipulate that you may also pick a later version. If that's true for LGPL (I think so, but I'm not sure) then you could choose to comply with 1.0 or with a later version at your preference. (Phillip refers to a provision of LGPL that says you can make a derived work and release it under GPL, but you don't want to do that anyway).
    – psr
    Dec 15, 2011 at 19:41
  • 1
    @Philip - While the copyright owner can't effectively change the license on the original code (it's already out there under that license) they can distribute any version they like under whatever license they like, as they are the copyright holder. They could make the license more restrictive (LGPL to GPL or AGPL) or more permissive (LGPL to BSD or MIT).
    – Mark Booth
    Dec 16, 2011 at 11:38
2

I don't know anything about H.264 licensing, but Philip addresses that point.

On the LGPL side though, if your application uses an LGPL library, then you must make the source code to that library available for download, if you include the binary of the library in your application download. If you have made any enhancements to the library, then the source code to those enhancements must be made available. This is the simple bit.

Next is the tricky subject of derivation or aggregation. If you statically link a GPL library to your application then you are producing a derived product and so your product must be licensed as LGPL or under a compatible license (such as GPL).

If you dynamically link the LGPL library to your application, then you are aggregating, so your application may have whatever license you wish. The tricky point here is that it should be possible for anyone to compile their own version of the library, substitute your dynamically linked library with their own and for your application to use that library as if it were the one you originally supplied.

The question Can I legally incorporate GPL & LGPL, open-sourced software in a proprietary, closed-source project? has a few answers which touch on some of these things, but I think the answers by Dark Shikari, Jonathan Mitchell and Mark Bessey are the most relevant.

Improve this answer
4
  • 1
    +1 for addressing the issues of derived vs aggregating. So far I've been able to avoid the LGPL for commercial products so I haven't needed to understand exactly what I would need to do.
    – psr
    Dec 15, 2011 at 19:48
  • @psr - the LGPL is designed for commercial software. All you have to do is to bundle the LGPL part as a dll/so and make available the source to the LGPL lib (and any mods to it) online. You can even abide by the LGPL with a static linked app with a bit more effort
    – Martin Beckett
    Dec 16, 2011 at 16:56
  • @MartinBeckett - My understanding that a static linking is a problem, at it means people cant easily compile their own version of the library (to fix a bug for instance) and substitute for the on used by your app. It is the substitutability thats important.
    – Mark Booth
    Dec 17, 2011 at 0:40
  • @Mark you can have a static app if you also allow the users to relink it with a new version of the LGPL lib, typically this means supplying your object files - although you could provide some sort of patch utility that would let them relink the LGPL lib. Unless you are on some sort of embedded platform without dynamic linking it's easier to just use so/dll
    – Martin Beckett
    Dec 17, 2011 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.