Sparrow made downloadable to conform to LGPL
sprw.me
sprw.me
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.
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 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).
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.
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.
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.
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.
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.
No, "we" haven't.
Yes. This is likely.
> 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.
Besides the main contenders, gmail, yahoo, et al. The thin-client email app ecosystem seems even worse than the thick-client app ecosystem. AFAICT.
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...
"Linking this library statically or dynamically with other modules...."
But according to this:
http://www.gnu.org/licenses/lgpl.html
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.
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Licen... says:
"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.
"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.)"
But for a big corporation with an established IP policy, that's a big no-no.
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.
That's the American English spelling of the British English noun "licence", not a typo.
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.
In other words, do the build scripts become subjected to the LGPL?
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.
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.
Well it's a good thing I'm not a customer!
Anyone else managed to build a bundle from .sh file?
What's size of your produced .app package? The one I purchased is around ~48mb.
"customer may not reverse engineer"
oh joy.