First of all, the big disclaimer:
We are not lawyers; we cannot help you decide if you should use the library or how to apply the license, only your lawyer can advise you concerning legal matters.
That said, it should also be noted that we have neither the resources (time, cash, etc) nor the patience to enforce the license (at all); the reality is that all of this is left to your discretion.
If you prefer to leave the lawyers out of it, the rest of this section will help you apply the license to your application.
That statement is an over-generalization that does not apply in this case. Most likely your source is either:
Basically, if you leverage the appropriate sections of the license, it should be fully compatible with the App Store restrictions and requirements.
No, it is not possible. There are multiple problems with this approach, some brief highlights:
You may think of this as the “price” you pay for using our open source library. If you want to make your life easier, you should be petitioning Apple for shared library support...
No, also not possible. In addition to the problems mentioned above, there are even more problems with this:
No, not as such. We won’t discourage you from plugging the library if you like, but it is not a requirement. You should think of our license as a supplement to your own software license, therefore it is appropriate to display it where (and only where) you display your own:
No, it is not necessary:
What is a “modification”? Again, we leave it to your discretion with this guidance:
If you find that you have made changes to the library, you should carefully consider how far you want to proceed down that path. Once you publish your changes you have created a “fork” of the project which you now need to maintain. Are you prepared to merge every time the library is updated?
If your change adds a useful feature to the library, we absolutely encourage you to submit patches. Assuming you can get your patch into the project, then you will no longer need to use a modified version! When submitting patches, ensure that your changes are appropriate for all of our users. Specifically, we are not interested in patches that simply hack up the library to work the way you want. Compare a patch that changes the default behavior to your preference (probably not acceptable), to a patch that adds a new configuration to support the feature you have added (probably fine).
Section 6 of the LGPL v2.1 specifically permits static linking with the library. If your project is not open source, this section does require that you make your object files available to your users. The intent, as indicated in the license, is that a user who has obtained your software may exercise their right to modify the library and then re-link their modified version into your application.
We recommend that you apply Subsection 6c, which only requires that you make a written offer to provide the object files. Now...if you consider the actual utility of this mechanism - that it is only applicable to developers, and only those with in depth knowledge of the tools, the time required for development - all to have a new barcode reader in a specific version of your application that only they can use, the reality is that no one is going to request this. You probably should not even waste time preparing for it until a request is made.
Additionally, to avoid “casual requests” from nefarious types that just want to inconvenience you, also consider charging a fee for the distribution of this material (as permitted by the license); just add up the cost of burning and shipping a disk. If this cost is “large” compared to the price of your app, the likelyhood of a request is reduced even further.
Applying the license in this case is somewhat simpler. These are the basic steps you can follow:
Verify that the rest of your software license is compatible with the LGPL. You cannot use the library if they are incompatible.
For those using the default App Store license, we have reviewed this and believe it is compatible with the LGPL.
At the end of your license text, in an annex or supplement, start by declaring your use of the library and offering a link to the project. Something like this:
This software uses the open source ZBar Barcode Reader library, version 1.2, which is available from http://zbar.sourceforge.net/iphone
If you built your own version of the library, replace the version callout with eg, “cloned from Mercurial revision xxxxxxxx”
Then append the contents of the text file COPYING, included with the library. This is all of the copyright information for the library.
Then append the contents of the text file LICENSE, also included with the library. This is just the LGPL version 2.1 which you may also obtain from http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
You may choose to make the written offer for the object files explicit. Provide some text and whatever link or email address is appropriate.
We intentionally leave this option vague and force you to refer to the license as an underhanded way of encouraging you to contribute back to the project ;)