In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better.
The author seems to have the same idea, and is considering re-licensing to MIT later on.
I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.
> If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold.
Obviously the issue is not about publishing changes to the library, it's about publishing the rest of the source which just uses the library as a building block.
You're free to link to compiled GPL libraries. There is nothing forcing you to change the license of your product unless you intend to integrate the sourcecode.
I also believe this, but it is not an established fact. The GPL does prohibit it, and so whether that is actually enforceable has to be tested in a court of law. So you are in fact not free to do this, if you have a boss above you who cares dearly about the company steering clear of hot water.
I'd be willing to testify as a technical expert in a court of law that the GPL cannot reasonably rule out dynamic linking; that dynamic linking to a program is a form of use (like invoking a command line and passing it arguments) and not integration. The proof is that dynamically linked components can be replaced by clean-room substitutes which work exactly alike, or at least well enough so that the main software can function.
For example, a program can be shipped with a stub library which behaves like GNU Readline (but perhaps doesn't have all its features). The users themselves can replace that with a GNU Readline library. Thus, the program's vendor isn't even redistributing the GPL'ed component. They can provide it as a separate download or whatever. However, if they were to include a GNU Readline binary for the convenience of the users, then the program supposedly infringes. This is clearly nonsense.
The problem with that line of thought is that the courts don't care if its use or integration, but if the resulting work depends on someone else work. The word used in copyright law is transform, adapt, recast, and such changes requires additional copyright permission. For example, if I buy a painting and cut it into pieces and rearrange them, I actually need an additional license beyond what I got from purchasing the copy. Components can not be cleanly viewed as separate when dealing with copyright.
You can also turn this around and ask if its legal to use process call within a other program without invoking the need for additional permissions. FSF view that it should be legal, but it has never been tested. By now however an industry standard has formed around the FSF guidelines and most courts would just look at it when deciding. This is what commonly happen when no one go to court to find out what the rules actually should be.
> but if the resulting work depends on someone else work.
Yes, so obviously your argument cannot be that "in theory, we could replace this with a workalike".
You better have the workalike, and that's what you should be shipping.
A powerful argument that you aren't infringing is that your shipping media are completely devoid of the work.
> don't care if its use or integration
For the sake of the GPL, they must care in this case, because the GPL specifically abstains from dictating use; it governs redistribution!
The only parts of the license relevant to use are the disclaimers; the only reason a pure user of a GPL-ed program might want to read the license at all is to be informed that if the program causes loss of data (or whatever), the authors are not liable.
GPLed programs get used all the time. A proprietary app on a GNU/Linux system can use the C library function system() which might invoke /bin/sh that is GNU Bash, and even depend on that functionality.
> For example, if I buy a painting and cut it into pieces and rearrange them, I actually need an additional license beyond what I got from purchasing the copy.
But what if that cut-up never leaves my house?
Or what if I only distribute instructions which describe the geometry of some cuts which can be made to a painting, and the relocation of the pieces?
> A proprietary app on a GNU/Linux system can use the C library function system() which might invoke /bin/sh that is GNU Bash, and even depend on that functionality.
And that according to FSF is legal because it do not create a derivative work. You said above that "GPL cannot reasonably rule out dynamic linking", but now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong. I just wanted to point out that the law could have been easily interpreted in a different way if someone had challenged FSF interpretation 25 years ago.
> But what if that cut-up never leaves my house? Or what if I only distribute instructions
Again, the law is both clear and quite fuzzy at the same time. The author has the exclusive right to transform their work, and as such, you could get charged even if it never leaves your house. In EU its a bit different, since it talks about moral right which protect the integrity of the authors work, through the end result is likely to be the same in many cases.
As for just giving out instructions, the legal nature of those are extremely fuzzy. If I provide instructions that reproduce a copyrighted video (by compressing/encrypting the data that represent it), I will still run foul of copyright infringement. From what I have seen, courts tend to take a "common sense" approach to this problem and if the end result is an infringement, then the indirect steps that will cause an infringement becomes infringement too. Judges collectively seem to rule against people who they perceives as trying to bypass laws by technicalities.
> You said above that "GPL cannot reasonably rule out dynamic linking", but now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong.
I don't see how you perceive a position change here. The FSF considers dynamic linking to be derivative; I do not agree.
We both consider the invocation via command line not to be derivative.
> now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong.
Have been all along. "Dynamic linking is derivative" is almost complete bullshit in my eyes.
It's pretty much pure use. We map this object into memory and then call it.
Maybe so, because the exclusive right is framed as a right "to prepare derivative works based upon the copyrighted work" (separate from reproduction, distribution, and other copyright rights).
Might it be that this separation between those rights exists so that the copyright holder can contract out manufacturing services, while controlling distribution? The copy house is given the right of preparing copies, without having distribution rights.
I don't think I was infringing back in kindergarten when I cut up newspapers to make strips for papier-mâché. In any case, my courtroom argument there could be bolstered by the remark that the resulting work was painted, entirely concealing the original content.
The FSF takes the position that linking is derivative work; this may or may not be an accurate legal position, but it's a popular position from the licensed creator and an entity which owns a lot of software licenses under the GPL, and which is very influential with people who choose to use the GPL, so even if it is ultimately legally incorrect, the risk of litigation, whatever they outcome, from linking is going to be unacceptable to most significant users, so a GPL library is unlikely to see uptake in major software for which the creator had a significant reason for choosing a non-GPL license, whether it is permissive or proprietary.
It's not about being apologetic or anti-freedom, it's all about the reality of software.
If it gets reimplemented with a more libral license, then the more liberal version will dominate. If there is any incompatibility whatsoever, the more liberally licensed version will win. Look at gcc for an example: it has gcc-specific extensions and there are other compilers with more open license. These compilers are gaining the upper-hand.
Making it GPL instead of LGPL is just a bad political choice. Especially for something which need wide adoption to even live. Image formats can only exist if they get adopted.
GCC has been around for 30 years. Only in the past 5 years has LLVM been around, and LLVM really is the only compiler to ever have matched GCC. The value GCC has provided to the software community in large is immense. Do you think it would have survived this far if it had been MIT-licensed all along?
To support this argument, I'd like you to think about all the other compilers that never had a 10th of the traction of GCC and how they were licensed.
I do agree that the LGPL is a reasonable choice for prototype implementation of a specification. I don't think using the GPL is a huge loss compared to LGPL for a prototype.
I'd like to ask a non-rhetorical question; On an individual basis is it not better if all software was available as sourcecode?
And if so, does that not mean the choice of not-publishing sourcecode is done for other reasons than what's best for the individual(s)?
Unfortunately, a sample of one isn't statistically significant. That a GPL-licensed compiler suite is overwhelmingly popular rather than an MIT- or BSD-licensed one could be little more than a historic accident.
BSD Unixes are BSD-licensed and have "survived this far".
The SBCL implementation of Common Lisp is licensed as a "a mixture of BSD-style .. and public domain" [source: http://www.sbcl.org/history.html] It is a popular CL implementation.
The choice of license cannot be the determiner of what propels a project to the forefront of popularity in its class, because ... there are many more projects than licenses.
kazinator was correct that saying one product made it proves nothing about overall effectiveness of its attributes. That's unscientific. If we're using uptake and maintenance as criteria, we might start with the venerable Sourceforge to see what percentage of projects go anywhere or get maintained under various licenses (esp GPL). Compare that to proprietary while we're at it. I predict results aren't going to look good for GPL's success rate and that's without a financial requirement.
Far as compilers, proprietary are winning out in terms of longevity, it's a select few proprietary vs GCC in terms of performance, GCC in uptake, LLVM with decent performance/uptake, and some others with intended academic uptake. So far, that's barely any GPL, one industrial BSD, quite a few academic (MIT/BSD licensed), and many proprietary. Apples to apples, GCC is barely special except in what it offers for free and how hard it is to extend. That's why LLVM was designed and why Apple built on it, among other companies and OSS-loving academics. After a mere market survey, GCC suddenly doesn't look amazing.
Now what's your thoughts on GPL getting the only development when I bring up Apache, BIND, FreeBSD, Sendmail, and so on? Plenty get development. Success stories, just like GPL, still have little to do with copyleft of the license and a lot to do with community or resources.
I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.