Is that just their changes to the LGPL components or the whole app? My understanding is that if you dynamically link to an LGPL library you're only required to distribute changes to that library not the whole app.
Also I don't get these two license clauses. If the point is to conform to the LGPL they can't just add another license on top.
Could this be a clumsy excuse for opensourcing Sparrow without having Goolge complain?
Also didn't the Apple Store license explicitly prohibit GPL code? Does that include the LGPL as well I can't recall off-hand?
Edit: As pointed out in the responses this is really just a bunch of .a files (static libraries), a couple of diffs against the libraries code and a script for linking sparrow together. The page provides little details and I though it was a source release This is apparently a way to conform with the LGPL on a system where dynamic linking is impractical.
For iOS, at least, this is a requirement to conform with the license.
Since you cannot dynamically link with libraries on iOS, sparrow is using static linking. The letter of the lgpl requires that you provide the application in a way that it can be relinked - either using dynamic libraries (4.1) or providing the object files to relink (4.0) [1].
Taking a look at the OSX app, it looks like they link with only static libraries there, too, which puts it in the same boat.
A lot of people think LGPL means "library", but that's wrong.
If you use an LGPL component, the end user must be able to replace the LGPL component. With a dynamically linked library, no problem. In sparrow's case, they apparently used used static linking. Since end users still have the right to replace that LGPL component, sparrow needs to supply their intermediate (.o) files so end users can re-link with a modified LGPL component.
"the end user must be able to replace the LGPL component" seems to be too one-sided IMO.
The user must be able to get the source, modify it, and make his modified version work with any (proprietary) application that chose to use the LGPLed code as a component. For that to be possible the proprietary application's authors must distribute their software with clear documentation stating which LGPLed components were used and provide source code and build scripts to rebuild these parts and relink them with the rest of their application. They also have to give you all the rights under the LGPL to further distribute and use any of their modifications to the LGPLed code for any purpose (not limited to use with their application).
Generally?
Not without permission. They are allowed to place further restrictions on the non-LGPL pieces, as long as they allow the two things they have allowed.
LGPL 2.1 is a weird license.
The section that allows for object code release does not require object code release under any particular license, it only requires that the LGPL portion stay LGPL.
Apple doesn't prohibit GPL. It's the other way around, GPL prohibits certain aspects of the App Store distribution model (I forget precisely what). In any case, this is LGPL, not GPL.
Thanks for clearing that up. Indeed the GPL forbids further restrictions on the rights it provides. Which makes it incompatible with app store distribution.
I though I saw something in the App Store rules as well. I double checked and they mention the GPL and basically say that you should respect FLOSS licenses such as the GPL and avoid those licenses that would have an effect on Apple's code.
Thats a pedantic difference. The GPL (version 2) was written in 1992(ish), well before the "App Store distribution model". The GPL was not written with the "app store distribution" model in mind. However it was written specifically to prevent certain closed source programmes.
Thanks AntiRush, KSherlock. I now understand more about LGPL than before. In my mind it was that only dynamical linking was allowed, and did not thought clearly about the static linking opportunity.
I'm not sure why everyone is so gung ho about Sparrow, the reviews haven't been good and my personal experience using it was that it was a very underwhelming product. It doesn't offer the whole set of gmail features, and for anything other than gmail it's even worse. I thought we'd all moved on from thick-client email apps. Admittedly gmail on IOS is awful, but since gmail supports exchange access, it's possible to use the built in email client and get push notifications. Even before Sparrow was acquired, teh reviews were less than stellar.
Everyone keeps trying to change email, let's leave it alone, it works fine, its one of the few technologies that has lasted any length of time and still be on top. nntp, gopher, etc all faded away, but pop, smtp, and then imap have flourished and become the de-facto way the world communicates.
> I'm not sure why everyone is so gung ho about Sparrow
There just aren't enough good email clients. Having another one is good.
> I thought we'd all moved on from thick-client email apps
Speak for yourself. I hate using webapps for a number of reasons but email is one of the worst cases for them IMO.
> its one of the few technologies that has lasted any length of time and still be on top. nntp, gopher, etc all faded away, but pop, smtp, and then imap have flourished and become the de-facto way the world communicates
Sparrow uses those protocols so I'm not sure what you're getting at, but it's easy to cherry-pick dead/dying protocols. HTTP and DNS are also ancient protocols that still exist but it's not because of any technical superiority, it's because of having critical mass for adoption.
We must know different people. I think (aside from the iOS built in email client) I don't know anyone that would even think of using a thick client, except to keep a backup of their gmail. Obviously it sounds like your experience is different, depends on the crowd we hang out with I suppose.
> I don't know anyone that would even think of using a thick client, except to keep a backup of their gmail. Obviously it sounds like your experience is different, depends on the crowd we hang out with I suppose.
All my friends used webmail when I was 20, too. That was in the 90s.
True, but it still doesnt compare to using the m.google.com exchange access from the built in iOS client. It's sluggish,nut does have some nice features, like easily switching between accounts. And of course search, it's faster than using the local search. iOS gmail is getting there...
If you play with LGPL you have to stick to the terms, it's a fair trade off. What I don't get is why Sparrow doesn't OSS it to save some face and allow it to be run under community guidance as they've obviously decided to mothball it.
It's not like Google is a stranger to the world of OSS anyway, might salve some annoyed buyers.
Okay to put in less licensing, more technical-wise way:
As far as I know on the iOS dynamic linking is possible, but not allowed (I could be wrong). For my pet projects (luajit on the ios) I'm using it without problems, but I don't plan on publishing anything.
So back to the licensing - LGPL is about dynamic linking...
1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
It's possible that I'm posting something out of context, or that the Tokyo Cabinet authors have changed their permission.
Another thing is that whatever was submitted by the Sparrow folks - was precompiled .a static libraries and some frameworks - not source code changes. Well there were few diff files, and that was it.
"Alternatively, a statically linked library is allowed if either source code or linkable object files are provided." But with no citation.
From reading on it, the consensus is that if your wrote your code such that it was possible to replace the LGPL part with a different (API compatible) library, and all you would need is a recompile then it's legal.
But if your code is written such that the LGPL parts can not be replaced then it's not.
the citation for that should be LGPL 2.1, section 6.a
"a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); 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. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)"
I've read the KSherlock and AntiRush's explanation above, and it seems that what you are saying is true. I just haven't realized that it could be done this way :)
Almost certainly true. I doubt the Sparrow developers were deliberately misusing the libraries (which LGPL code was used, btw?). It's just that packaging and shipping a relinkable binary was way, way down the priority list and they probably just never got around to it.
But for a big corporation with an established IP policy, that's a big no-no.
That's exactly right. I was part of a similar audit at a past company during their exit. We essentially had to inventory the license of every Rails plugin, script, etc. we had ever used.
<quote>If you do not or cannot agree the license[sic], please do not download the files.</quote>
Sounds like they're trying to enforce an LGPL-incompatible license on the changes to the LGPL'd libs, and pass it on as complying.
I'm fairly certain they are referring to the license to their code. In other words, the fact that there are LGPL bits involved which can be redistributed does not mean that the entire application is "fair game".
Quite funny they write that they release to conform to LGPL 2.1 part 6.a. But by writing "You may download those files only for your own use. Customer may not redistribute any work based on those files." they are quite clearly in violation of at least LGPL 2.1. part 2.c "You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License." and part 10 "[..] You may not impose any further restrictions on the recipients' exercise of the rights granted herein.[..]"
You are confusing two completely different sections.
Section 2 deals with the Library, that is, the LGPL code.
It says this quite clearly "2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:..."
Section 6 deals with a work that uses the library, and combining it with the library, which is the combined work of the LGPL code + whatever else.
You're right, I overlooked how they restricted their license restriction "The following restrictions apply to everything [..] in these downloads, except for the open source pieces. ". Now it starts making sense.
These are patches to the LGPL'd components they use, not Sparrow itself, right? (The LGPL specifically requires that you only release your modifications to the library, not your own code.) The only interesting things are some images, and some patch files inside lib/ -- nothing appears to be Sparrow's own source code.
It looks like they also toss in some compiled versions of Sparrow-proprietary code for debugging reasons, which I _think_ explains their incongruous licensing terms, but they're still strange.
The LGPL requires you, if you static ally link against such libraries, to release all of the rest of the build environment required to rebuild a working program from changed LGPL components; this involves releasing binary objects.
You can even sell the binary for money, distribute the source with it and simply ask your client to not-redistribute the source to someone else and it's fully legal.
Well, ask and compel are different. I'm pretty sure you can ask them to do anything, up to and including barking like a seal. You can't compel them to do it under GPL though.
These LGPL clauses say the binaries for the work that uses the library must be released with the modified source code of the library itself. Does that imply that people would be free to use binaries (and thus the product)? Am asking for the general case, not specifically for Sparrow.
They only have to distribute these binaries to people who already brought the product. My guess as to why it is public ally accessible is that due to selling it through the app store they can't tell who actually brought it and the amount of people who can compile this, would pirate it, couldn't pirate from somewhere else and would have brought it if they couldn't pirate it is pretty minimal.
Also I don't get these two license clauses. If the point is to conform to the LGPL they can't just add another license on top.
Could this be a clumsy excuse for opensourcing Sparrow without having Goolge complain?
Also didn't the Apple Store license explicitly prohibit GPL code? Does that include the LGPL as well I can't recall off-hand?
Edit: As pointed out in the responses this is really just a bunch of .a files (static libraries), a couple of diffs against the libraries code and a script for linking sparrow together. The page provides little details and I though it was a source release This is apparently a way to conform with the LGPL on a system where dynamic linking is impractical.