Comment by yalok | Hacker News Reader

Comment by yalok | Hacker News Reader

Just anecdotally, but this aligns with my observations on the trend/growth of successful useful open source projects that go with permissive BSD-like license. ~20 years ago there were way less of those than now.

And as a SW developer doing client side/apps as well, using GPL/LGPL is a total pain and basically cost prohibitive, unless I work on my personal small project where I don’t care about having to/risking to open source the rest of the code and getting sued/cloned…

Real life example from ~2010 - we ended up including an LGPL library in our mobile app code, and published/upstreamed all the modifications we did to that code (mostly ARM optimizations). Once the app became popular, our competitors came to us demanding the source code of our app - just because iOS didn’t support dynamic libraries (so we had to statically link it), and giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL), because they really wanted to see how we hacked around iOS camera input APIs…

> giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL)

Doesn't that also satisfy the letter of the LGPL v2?

> Accompany the work with the complete corresponding machine-readable source code for the Library [...] and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library

Deliberately so, moreover, because distributing object files for relinking used to be common[1].

[1] https://lock.cmpxchg8b.com/linux123.html

> giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL)

So they can take a hike?

I agree that permissively licensed projects are more successful if you define "successful" as "having the most number of users possible". Of course, this "success" often results in the unpaid volunteer maintainers being inundated by bug reports and feature requests from employees of major corporations, so there's drawbacks to that approach.

Yeah, you're saying that BSD code, which you can get for free and give nothing, is the most convenient thing for you in helping you create closed source commercial programs. Well sure.

I'd mention for a commercial library creator, say QT, the GPL can be quite convenient because the commercial clients they have can't just take their stuff for free and use it but instead can use the GPL to sample and then come for a commercial license when they're going to use it that way.

That is to say, just about every license that is used today serves a particular purpose for vendors and thus none of the licenses are likely to go away as long as we have different vendors with different aims.

> using GPL/LGPL is a total pain and basically cost prohibitive

It's not, if you can comply with the license.

If you want to take advantage of free (L)GPL code in statically linked binaries without providing the source code to your customers, then yes, that is a problem. Although with LGPL the linkable binaries should probably be enough.

> just because iOS didn’t support dynamic libraries (so we had to statically link it)

if you develop closed software for a walled garden then relying on gpl is still possible but a rather contradictory philosophy. i guess the alternative would have been developing all that from scratch, or getting it from elsewhere, likely paying for it, which would have made those costs even more prohibitive ... otoh i really don't understand those prohibitive costs because supplying the object code was all you needed. what were those? lawyers?

I think the LGPL is becoming particularly irrelevant. I’d like to use GEOS (LGPL 2.1) in a macOS app but the risks are high as you point out. I think it’s going to be significantly less risky long run to rebuild GEOS in Swift. The complexity and lack of clarity in the licensing is a real burden.

I don’t think this is the spirit of the LGPL - it’s just code signing prevents the use of dynamically linked libraries in the way LGPL intended.

Perhaps you'll find MPL 2.0 less complex and more "in the spirit of the LGPL":

https://www.reddit.com/r/rust/comments/msjil9/opinions_on_th...

https://www.reddit.com/r/opensource/comments/msjk93/licensin...

https://www.reddit.com/r/opensource/comments/1g2sprd/could_a...

Although that won't help you with GEOS, which is already licensed as LGPL-only.

Reply on news.ycombinator.com