Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think you mean LGPL where you say iOS in the first sentence.

I can't answer your question, but just point out that huge chunks of iOS itself are LGPL already, such as webkit, and the LGPL version of ffmpeg is already widely used.

There has been some speculation in the past that because iOS mandates static linking that this is a problem for using LGPL libraries, but I fall into the 'linking creates a compilation, not a derived work' camp and if the compilation interpretation is correct then static linking isn't a problem.

But every time I dig into LGPL interpretation and linking issues, eventually my head starts hurting and I give up.



1. Apple distributes source to the LGPL pieces, so that is not an issue for them.

2. The rest of what you said doesn't make much sense to me. I'm not clear on what distinction you are trying to make.

There are those that believe that the question of linking is mostly irrelevant to whether something is a derivative work. Lawrence Rosen is the canonical example of folks in this camp. But even in that camp, static linking may be a problem, it just depends on what is being done.

So it's not really true that "static linking isn't a problem".


Well, stop reading the LGPL interpretation, and start reading the LGPL itself - it is written in English (rather than legalese) and is very clear on most subjects.

Specifically, it cares that the end user can "swap out" the LGPLd code for their modified version, which is not available in the iOS AppStore regardless of compilation vs. derived work interpretation (a distinction without difference if I understand it correctly).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: