-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The GPL license will significantly hurt adoption. #9
Comments
I agree with Asmageddon. |
The HN discussion has many insightful comments relating to this issue, including the following choice comments:
@scottmp10
I'll leave any fact-checking to others. |
It's also legally impossible to comply with the GPLv3 on iOS, so the reference implementation could not legally be redistributed as part of iOS applications. Inclusion into less restrictively licensed imaging libraries such as FreeImage, ImageMagick and Python Imaging/Pillow as well as DevIL/OpenIL would also become impossible, and would require build-time licensing preset nonsense like FFmpeg has. At the very least, please choose LGPL2. Best would be something Apache2/MIT/zlib-like. Apache2 has the benefit of also including a patent termination clause, which might be useful. EDIT: Requiring a C++ linker for all users of the library by using C++ for the implementation will probably also hurt adoption, and so will not having a spec which means all third-party implementations will have to use clean-room reimplementation practices (i.e. write their own spec) and then have somebody who never looked at the original source implement it, as it would otherwise be considered a derivative work and thus also be covered by the GPLv3. |
👍 @Asmageddon (Though I’d personally rather just see an MIT license, their suggestion is likely the most compatible with everyone’s goals.) |
Is this not a duplicate of #3? IMO, @Asmageddon should close this issue and just use the other thread so that all the discussion on licensing takes place in one area and we don't have things getting needlessly repeated. In any case, that other thread has useful links and quotations from the author so that you might be able to understand his point of view. |
Sorry, I didn’t see that one. I agree with @Wallacoloo. |
I think that 'hurting adoption' by corporate abusers is not something I'd be against. Stand for copyleft, stand for freedom, and if the tool is worth it, corps will bend. Note that the Linux kernel managed this, and I don't see anyone whining to them about copyleft ruining their adoption among their corporate masters. 👅 |
I have to agree with @kozross on this one. If proprietary makers don't use this format, it's their loss. FLIF will still be great and be used in projects that care about its users. |
I strongly disagree. Apple should be the one to comply with freedom, not the other way around. Right now we have a technologically superior format, if other entities do not want to use it due to the copyleft, that's their loss. The superior format features can be used to put pressure on them. We shouldn't give up this unique opportunity so quickly and early. People are talking about hurt chances of adoption. But now that there is great interest in this format, it can be used in its advantage, and for the advantage of copyleft and free software. |
I actually agree that, for right now, while the format is unready for adoption, the GPLv3 is the right choice - since the format is premature, you don't want easier adoption yet, and if a program is going to try to use it, you do want the code copyleft-tainted, so that the obsolete version of the format can't become an irrevocable part of the codebase (it will always be possible to fix with a patch). TL;DR: At this early stage, hurting adoption is a desired feature. Once the format has settled to a degree that it's ready for adoption, then you'll want to relicense the project, and that will have its own issues without a CLA (which is what I'm going to post about right now) - but, for now, GPL is the way to go. |
I'm involved in developing a graphics design app and I am always on the lookout for new file formats to support. However, GPL makes adoption an impossibility for some libraries, such as this one. Perhaps the authors should reconsider and release the lib under BSD. |
@ke7ofi I beg to differ. Nonfree (I refuse to use the disgusting and corporate-appeasing vocabulary of the open saucers) software is inherently bad, and evidence of this is all around us, every day. Ignoring ethical implications won't make them go away. |
Closing this one, feel free to discuss further in #3 |
@kozross Easy there, RMS. Things like copyright laws are silly, but by the same token, people aren’t ethically obligated (and certainly shouldn’t be legally obligated) to release their source code. I use almost exclusively OSS, but I’m not going to condemn someone who wants to try making money that way. I just don’t buy their product if I can avoid it (exceptions include things like cars, where there aren’t really any OSS alternatives yet (though hopefully Local Motors or someone similar will fix that)). |
@ke7ofi On that point, we differ substantially. I do condemn people who want to make money depriving people of their freedom, and will continue to do so. Just not here, since it's obvious that corporate appeasement is the goal of this project, judging by the wording of its CLA. |
@kozross Why do you think that? I know a decent number of people agree with you, but I’ve never understood why. I assume it’s some better reason than “This is selfish; therefore evil.”. |
@ke7ofi One can choose to not release anything if they do not want to. But once they do decide to release a program for public use, they should also give the public the ability to use, study, modify, and release those modifications etc. as they wish. Otherwise, this is just unethical. Of course, you are free to disagree with that, but if you or anyone else is interested for more about why RMS and co think like this, you should read some of Stallman's essays: https://www.gnu.org/philosophy/fsfs/rms-essays.pdf. |
230 pages? I’m glad that we have somebody on the extreme end of the spectrum pushing for more open software (He might just barely balance out the illegal tractor repair people.), but I have to wonder what sort of person would spend that much time writing similar works. (Have you seen https://rms.sexy/?) |
Well not all of it... that just lists a lot of the essays as a book. Maybe https://www.gnu.org/philosophy/ instead? |
Namely, it renders it unusable for a wide array of uses, and, being the only implementation, with quite likely relatively few people interested in re-implementing it(it's not well known, or used), this means that no one will be creating FLIF images, and no one will be capable of using FLIF images.
I suggest keeping the specification as GPL, and re-implementing the library as LGPL, or MIT, instead of a viral license like GPL.
The text was updated successfully, but these errors were encountered: