You can still write free software that uses it and produces a not-entirely-free artifact when compiled, though, right? (Is there a distribution restriction on the artifact, or is it impermissible to link it with GPL apps, or something?)
I'm curious if the free software apps are compelled not to link it to preserve the free software status of their code, or just voluntarily refusing on principle (which is laudable, to be clear).
Only if you are the author of all the code, so that the GPL doesn't actually apply to you.
In this case, the Telegram-FOSS people take the original Telegram source (which is GPL licensed) and redistribute it, so they can't distribute a non-entirely-free apk without violating the original license.
Other apps using, for example, GPL licensed libraries or accepting third-party contributions under the GPL exclusively are also forbidden from redistributing non-entirely-free stuff.
Other apps using, for example, GPL licensed libraries or accepting third-party contributions under the GPL exclusively are also forbidden from redistributing non-entirely-free stuff.
Or even just copying bits of GPL-licensed code in themselves.
There seems to be a lot of Telegram bashing but every assertion I saw eventually failed to be backed up†, if at all attempted. This ends up triggering my BS detector every single time, and the significant influx of such occurrences makes me think of some astroturfing/FUD campaign.
† I also do my homework when fact checking, but failed to turn up anything relevant, only more non-backed up assertions or obviously inflated beyond proportion facts twisted beyond recognition. I may very well miss something, that's why if backing up material is known by the detractors it's always worthwhile to share (which applies to any pro/con discussion really)
I’m doing the research work for you, though it’ll be a while before I can stop procrastinating for long enough to write a whole thing about it. While you wait, https://github.com/overtake/TelegramSwift/issues/163 is probably a good start.
I have a thing I’m writing that will go into more detail, but in short Telegram’s client applications (which are licensed under various incarnations of the GPL) are updated frequently while the source code in their publicly available repositories lags far behind. In addition, they use a number of open source libraries that at the very least require attribution, but Telegram does not follow their terms.
> while the source code in their publicly available repositories lags far behind
I don't think this violates GPL. GPL requires you to be able to receive the source if you want to, not that it be on an online repository. You might have to request it and have it sent to you.
I mean, I could, but I think it's fair for me to assume that the GitHub repository that the official website links to as the source code for their client is where they’d publish up-to-date code.
They might well publish it right there if you ask. Just saying they haven't violated the license as long as they have a written offer to provide you with the source code somehow if you ask. (That's what GPLv2 seems to require.)
They provide no alternative "written offer". On the website, they directly point to GitHub for the source code offer: https://telegram.org/apps#source-code
I’m not fully aware of the situation regarding Telegram-FOSS, but I’d assume Telegram can sue them for license violations regarding code that they own the rights to.
I have yet to see any proof of this. Granted, it's true that Telegram's backend is closed-source and that part of the infrastructure is completely opaque, but at least they're sincere about it, unlike Signal's open-but-not-quite[1] approach.
> The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
so anything that is not distributed with the operating system needs to be available as source code, so that you can credibly offer to distribute the source code to the recipients.
Thought experiment: write an application that automatically downloads and combines code with all sorts of legally incompatible licenses to create an application and installs it on an Android device. If personally doing it is legal (and basically unenforceable), what about making it easy for others to? Besides, unless you're a "radical Stallmanist" (for lack of better term), chances are you have a mix of proprietary and FOSS and use it together on whatever data you work with.
This is why I think IP laws make no sense, arbitrary restrictions are arbitrary and stupid.
My understanding is that what you describe is completely legal.
ZFS on Linux is a good example of this. ZFS and the Linux kernel are both open source, but their licenses are incompatible with one another—ie, you can't combine the code.
A common workaround for this problem is to compile the source on the user's machine. When you install ZFS in Debian, apt will automatically download the ZFS and Linux source code, recompile the kernel with ZFS included, and install the result. This is all completely invisible to the user, except for the absurdly long install time.
That would definitely be a dodgy thing to do. In general, law courts are interested in the net effect of what you're doing rather than the technical details of how you did it, and what you'd be doing in that case is equivalent to distributing the Frankenstein application yourself.
Describing in a blog post how to build the Frankenstein application is perhaps perfectly all right, but somewhere between there and the hypothetical application you described a fuzzy line would be crossed.
There's another fuzzy line relating to whether code is combined or not. Code that goes into the same statically linked binary is definitely combined, I presume. What about code that communicates via a REST API or a standard protocol? Perhaps it depends on the attitude of the communities that produce the code. The Linux people seem to be happy with non-free kernel modules in a way that some people wouldn't be.
IANAL, but I think that would be regarded as a circumvention device by a court. I hope you're not basing your opinion regarding laws entirely on this contrived case :)
Ubuntu gets around any possible GPL violations by offering to download and install proprietary drivers (ex., Nvidia) and codecs during installation process. Could something similar work for Android apps?
Yes, it would work - you could deliver the push notification module as a separate APK which talks to the main application part. It's still way more complexity than adding a GPL lib to your app.
The mechanism used by Ubuntu for such drivers is completely unrelated to GPL violations. It's just there so the non-free software doesn't get installed by default. If there would be any violation without it, there would still be a violation with it.
Just curious, does it means that a proprietary application downloaded through an open-source GPL script makes the whole (application + script) "GPL compliant" ?
I'm curious if the free software apps are compelled not to link it to preserve the free software status of their code, or just voluntarily refusing on principle (which is laudable, to be clear).