Hacker News Reader

Comment by JoeAltmaier | Hacker News Reader

our company recently expunged all LGPL code from our product. The cost of that license outstripped the usefulness. We wrote or got around the need for any of it; it wasn't too hard. Generally we were after a fraction of the IP, and there were alternatives.

LGPL is fine for non-commercial folks. For business I need a license to do as I please with the code, with no futzing around.

<edit: LGPL>

View on HN

LGPL lets you do as you please with the code. If you need to modify the code, which in my experience isn't all that often, you simply provide the patch back to the committers. They're not required to take it, but that doesn't affect you. You simply had to provide it.

And since you took from the community, doesn't it make sense to contribute back when you have something to contribute?

LGPL requires us to ship the libraries in particular ways. Our product runs on mac, windows, android, pad and phone. It was impossible to conform.

An now, we don't take from the community, so no we don't feel the need to give back in that way.

And in my experience, much of open source does have to be modified. Usually to extract the IP needed without the cruft sticking to it - all the assumptions made by the authors about how it was going to be used.

IANAL, but I believe you're incorrect about shipping the libraries in particular ways. My understanding of the LGPL is you don't have to ship the libraries with your application, you just need to provide the relevant copyright notices - usually in your Help/About.

I worked with the legal department at my company to get a list of approved open source licenses for components included in our applications. The GPL was immediately ruled out. Because of the GPL they spent several weeks scrutinizing the LGPL. They approved it.

Obviously your mileage has varied with your lawyers. And if we want to keep our jobs we can't cross the lawyers, even if we believe them to be wrong. It'd be nice if our community had a common understanding of the LGPL. There seems to be a lot of confusion.

You have to provide a way for your users to relink to a different version of the library. This is hard for iOS easy if your target is Linux.

Our target is everywhere. So no, not possible on many platforms.

And the terms become more restrictive with every iteration. That general theme may be present but in the end you have to conform exactly to how the license is written. The verbiage about linkages etc becomes meaningless on some platform (those without a loader for instance). Where does that leave you, legally? I learn to never ask a lawyer techical engineering questions - like the old line about teaching a pig to sing.

Your last point is actually pretty wrong. I've helped write linkers and loaders, and can sit around and have a combined technical and legal discussion about the impacts of linking in various ways all day if you like.

If you've learned never to ask a lawyer technical engineering questions, you need better lawyers.

Realistically, if your lawyers don't actually understand how your code operates or what it does, at a deep technical level, the advice they give is not going to be all that great or even right.

Sounds like we need you, in fact!

Nope. The LGPL basically requires you to make sure that the end user can replace the LGPLed code with a modified but ABI-compatible version (for instance, because there's some bug in the code). Think back to the libpng security vulnerability a few years ago, for example - because that was under a more permissive license than the LGPL, users of proprietary software that included the insecure version couldn't update to a fixed version by themselves and were reliant on the companies that supplied them the software.

That may be correct, but its an engineering description of a legal document. We're great at deconstructing things - lawyers are great about enforcing the letter. SO I'm not sure anything that boils down to "The LGPL basically requires..." can be trusted - certainly that argument has no weight with our lawyers.

Consider for a moment anything shipped on an iPad or iPhone. How does the user replace pieces of your application, exactly? Its not possible, by design (thank you Apple).

Speaking as an open source lawyer, the question of whether it's legal to use LGPL 2.0/2.1 software in an app store app is a very open one, exactly for the reason given above. You will find people taking opinions on both sides.

It certainly happens that people use LGPL 2.1 code in IOS apps, but that doesn't mean it's okay.

The answer is more clear for other licenses, including LGPL v3.

I wouldn't trust what you see app stores doing as "okay". Among other things, I do due diligence on mergers/acquisitions, and without a doubt, app store apps are one of the places I see the most license problems.

Its not about contributing back, but the way the dependencies have to be deployed. For example, static linking is a violation.

Strictly speaking, the requirement is that they be able to upgrade/modify the library. Static linking coupled with shipping only an executable is a violation. I believe that shipping source (or even un-linked object files?), such that users can rebuild the application with a statically linked updated version is allowed - no requirement that they be permitted to modify or redistribute the application proper.

LGPL is fine for 'commercial folks' aswell, as long as they are willing to make changes they've made to the 'LGPL licenced code' available in source form.

If you are not willing to do this then no, LGPL is not right for you.

As an example, Apple uses the LGPL licenced Webkit in their proprietary Safari browser.

Read "willing to .. .make available" as "spend engineer hours/money".

Wouldn't the checkin to your source code repository already have those patch(es)?

Sure. But what about rewrites? What about code fractions extracted and used in other modules? What about makefiles to integrate the code, or package builder scripts? ALl that is part of our stuff, but taken from their project.

So we expunged all of it, wrote our own or got rid of the feature (found alternate encodings of files we were decoding; used different rendering agents etc).

WebKit is BSD licensed; WebCore, which WebKit uses, is under LGPL. Apple seems to actively put as much code as they can in WebKit as they can, so they can avoid open-sourcing their fork, and they have carefully isolated WebCore sufficiently that many of the more interesting changes they make to it (such as those that give them advantages on mobile) can be done by adding binary .o files (as allowed by LGPL) as opposed to new source.

What issues did you have with the LGPL that made it necessary to expunge all LGPL code?

Spending engineer hours (money) on packaging the libraries in the proscribed ways. As posted elsewhere in this thread, shipping separate libraries isn't always possible.

The effort was triggered by an investor requirement - that we not endanger our commercial viability with LGPL code of any kind. I.E. The lawyers told us to.

Reply on news.ycombinator.com