Skip to content
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

Closed
Asmageddon opened this issue Oct 2, 2015 · 20 comments
Closed

The GPL license will significantly hurt adoption. #9

Asmageddon opened this issue Oct 2, 2015 · 20 comments

Comments

@Asmageddon
Copy link

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.

@jdalbey
Copy link

jdalbey commented Oct 2, 2015

I agree with Asmageddon.

@travisk-codes
Copy link

The HN discussion has many insightful comments relating to this issue, including the following choice comments:

I think the right avenue is to keep the license GPL but provide a permissive as-is use license. The idea is that you want people making improvements to the algorithm to contribute those back for the public's benefit rather than charging people for their "upgraded" version. A separate unmodified-use license could be much more permissive in the use of algorithm as-is for compressing and decompressing images.

@scottmp10

I think the concerns about the licensing are a bit premature - honestly, this is currently a research project, not a practical replacement for existing image formats. The licensing is only one of several impediments to adoption.

@tfinniga

I think even Stallman would've advocated something like the MIT or BSD license for something like this -- having a patent-unencumbered alternative to formats like JPEG 2000 being used seems to be more important to a lot of Free Software people. In other words, the advantage of having widely-used file formats that are accessible to free software programs are considered greater than the benefits of having software become libre in order to use GPL'd file format libraries. Stallman defended the use of a non-copyleft license for Ogg/Vorbis on those grounds:
https://lwn.net/2001/0301/a/rms-ov-license.php3

@cwyers

It has nothing to do with requirement of code sharing. It's all about realism. So far there has been 0 successful file formats/codecs with GPL reference implementation and there is no reason to except FLIF to buck the trend.

@zokier

RMS himself was against putting such formats/codecs in GPL. Suggested Apache 2 license.

@nickpsecurity

I'll leave any fact-checking to others.

@CounterPillow
Copy link

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.

@kigerpunk
Copy link

👍 @Asmageddon (Though I’d personally rather just see an MIT license, their suggestion is likely the most compatible with everyone’s goals.)

@Wallacoloo
Copy link

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.

@kigerpunk
Copy link

Sorry, I didn’t see that one. I agree with @Wallacoloo.

@kozross
Copy link

kozross commented Oct 2, 2015

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. 👅

@pizzamaker
Copy link

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.

@vyp
Copy link

vyp commented Oct 2, 2015

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.

@stuartpb
Copy link

stuartpb commented Oct 3, 2015

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.

@kigerpunk
Copy link

Good idea, @stuartpb.

@kozross what about corporate users (sans abuse)? Closed-source isn’t unethical; it’s just inferior.

@DominikDeak
Copy link

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.

@kozross
Copy link

kozross commented Oct 3, 2015

@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.

@FLIF-hub
Copy link
Collaborator

FLIF-hub commented Oct 3, 2015

Closing this one, feel free to discuss further in #3

@FLIF-hub FLIF-hub closed this as completed Oct 3, 2015
@kigerpunk
Copy link

@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)).

@kozross
Copy link

kozross commented Oct 3, 2015

@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.

@kigerpunk
Copy link

@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.”.

@vyp
Copy link

vyp commented Oct 4, 2015

@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.

@kigerpunk
Copy link

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/?)

@vyp
Copy link

vyp commented Oct 4, 2015

Well not all of it... that just lists a lot of the essays as a book. Maybe https://www.gnu.org/philosophy/ instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests