search

FLIF-hub / FLIF

Free Lossless Image Format
Other
3.72k stars 228 forks source link

License discussion #192

Closed jonsneyers closed 8 years ago

jonsneyers commented 8 years ago

The discussion that was started in #168 can be continued here, should anyone want to.

So for now, I am inclined to:

dlemstra commented 8 years ago

Would it be an option to use a less restrictive license like Apache 2.0? Or at least use LGPLv3+ for the encoder? I would like to include both reading and writing in the Windows binaries of ImageMagick. We cannot include writing at the moment because libflif_enc is licensed under GPLv3+.

And why is there a need to use a different license for the encoder and decoder?

jonsneyers commented 8 years ago

Here are some of my personal thoughts.

1) I want to use a copyleft license so that if someone improves/modifies the encoder/decoder, they have to share back those modifications. I would not like to see commercial closed-source software that builds upon my work without sharing back, which could perhaps even become the de facto reference implementation that turns FLIF ironically into a proprietary, non-free format.

LGPL and GPL are both suitable for that.

2) I also want to promote and encourage Free Software. I think it would be nice if FOSS projects can easily add FLIF support by reusing my/our implementation, while proprietary projects have to wait for the detailed public specification to be ready (which might take some time) or do a cleanroom re-implementation. If I can contribute towards giving projects like GIMP or ImageMagick a "competitive edge", so to speak, then I consider that to be a good thing.

3) Finally I also want to promote FLIF and make it a practical file format. For an image format to be of practical use, it is important that everyone can actually view/decode the images you're encoding with it. Having to use separate image viewers is not practical at all. So it is important that the decoder can easily be integrated in existing image viewers, web browsers, etc. That's why I licensed libflif_dec under the LGPL: other software, even closed-source software like Adobe Photoshop or Microsoft Internet Explorer, can (theoretically) link to libflif_dec without having to go open source.

Image authoring or manipulation (in other words, encoding) is something that fewer people are going to need. So taking into account point 2), I think it makes sense to give the encoder a license that makes it hard for proprietary software to reuse my implementation, while making it easy for FOSS software. The GPL seems to be too restrictive (since it does not allow non-GPL'ed free software to link to the encoder), while the LGPL is too permissive (since it also allows non-free software to link to the encoder).

So ideally, I would want something in between the GPL and the LGPL for the flif encoder library: I want free software (under whatever FSF-approved license) to be able to use it, while I don't want proprietary software to be able to use it just like that, especially not commercial closed-source software.

Does that make sense? Does anyone know a suitable way to do this?

heavyk commented 8 years ago

awesome!! great vision!

vyp commented 8 years ago

The GPL seems to be too restrictive (since it does not allow non-GPL'ed free software to link to the encoder), while the LGPL is too permissive (since it also allows non-free software to link to the encoder).

So ideally, I would want something in between the GPL and the LGPL for the flif encoder library [...]

I might be wrong, but I don't think there is such a free software license. The reason the GPL is incompatible with lax licenses is because lax licenses allow sublicensing under nonfree licenses. So maybe it might not be possible to allow non-copyleft free software, but not proprietary software, I'm not sure. Maybe you should contact the FSF, just for their (not strictly legal) opinion.

And if you have the money, you may even be able to work with the FSF to create a new or modified free software license entirely for this purpose, but that will likely be a long process.

vyp commented 8 years ago

Sorry, it is not correct to say they are "incompatible". I meant more the like the reason GPL forbids nonfree linking.

jonsneyers commented 8 years ago

The LGPLv3 is essentially just the GPLv3 plus an addendum which relaxes the GPL conditions: a conditional linking exception (https://en.m.wikipedia.org/wiki/GPL_linking_exception).

IANAL, but I don't see why I cannot just take the wording of the LGPL and make its conditions more strict, to the effect that the linking exception is only granted to applications with an FSF-approved Free Software license.

vyp commented 8 years ago

IANAL, but that seems reasonable. The primary reason is because we're not lawyers and maybe in lawyer speak there are things that prevent such a restriction? The reason I said you may need money is because I wasn't sure to what extent you wanted to modify an existing license. But I think the LGPL with an extra clause or something should be possible.

Either way, you are certainly free to license it under whatever license text you want, you do not have to choose an existing license. It's just that the free software community considers FSF-approved licenses to be unambiguously free software, as you probably already know. So maybe, come with the extra clause that "only free software can link to the application", and then ask the FSF about it?

If you come up with it first and say you are going to release it under this license, they will likely treat your question with more urgency (in case they don't already, I don't know).

jonsneyers commented 8 years ago

So basically this is what I would want as a license for libflif(_enc):

That should allow e.g. ImageMagick to link (statically or dynamically) with libflif, while e.g. Adobe Photoshop wouldn't be allowed to do that.

I'll contact the FSF and point them to this discussion.

Jookia commented 8 years ago

Hey there, I'm not from the FSF but I'd like to help clarify things.

You want a copyleft license that ensures your software is only used in free projects. Furthermore, you want it to work this way regardless of linking. I'd choose this GPLv3+ for this:

The GPL doesn't care about linking, only combining of copyrighted works - it's a copyright license. The LGPL doesn't define linking and mentions linking and combining together for the most part, aside from giving a clause for shared libraries (which is probably why linking it part of the license.)

The GPL will also work with non-GPL but GPL-compatible licenses, like the MIT Expat license. You can take ImageMagick, add a GPL library without needing to do any relicensing and distribute the combined work (binary or source code) under the terms of the GPL. ffmpeg does this with x264 for example.

The only downside I can think of here is that complying with the GPL is a bit more complex than the LGPL, sections 4, 5 and 6 are what have to be met. If I were running ImageMagick, the 'with FLIF' release download would have to add notices that the work is a modification of FLIF, give a relevant date for modification, put notices that it's under the GPL, the convey it in one of the forms under section 6 and give installation information if the software comes on a user product. The LGPL requires most of this though.

On top of that, only working with free software means it won't work on systems that lock out free software (iOS, etc)

You may also want to use GPLv2+ in that case for GPLv2-only project compatibility.

jonsneyers commented 8 years ago

Are there any significant and relevant GPLv2-only projects out there (that could benefit from a flif encoder)? If not, then I think 'downgrading' to GPLv2+ does not need to be considered, since the difference between v2 and v3 is not negligible.

dlemstra commented 8 years ago

GPLv2 is incompatible with the Apache 2.0 license (http://www.gnu.org/licenses/license-list.html#apache2) so I don't think its a good idea to 'downgrade'.

I still wonder if it would be a good idea to use LGPL as a license if you want the FLIF format to be as mainstream as JPEG/PNG/TIFF. The libraries for those formats use a less restrictive license and are still the primary library for those formats. And I personally don't think that if a commercial company makes a 'better' version of your library that your version will become obsolete. People that want to use a free library can use yours and those who want the commercial alternative can decide to pay for it. But that might be something that you want to prevent from happening.

wolftune commented 8 years ago

LGPLv3+ is a pretty good compromise. I'm not sure how you could even have a different compromise. There's the copyleft-next project but it isn't usable / recommended (yet?).

One other ideal would be LAGPL (doesn't exist yet), i.e. LGPL with the Affero clause.

The basic issue is: we don't have a mechanism to protect software freedom other than copyleft's keep-the-license mechanism or the weakest honor-based ask for people not to be proprietary. That's how it is since we're hacking the law. The only full solution is to change the law to better support software freedom.

jonsneyers commented 8 years ago

Someone from the FSF told me that one way to do what I want to do, is to add an explicit exception. It could for example be worded like this:

"Additional permission under GNU GPL version 3 section 7

If you modify this Program, or any covered work, by linking or combining it with ImageMagick (or a modified version of that program), containing parts covered by the terms of the Apache 2.0 license, the licensors of this Program grant you additional permission to convey the resulting work. Corresponding Source for a non-source form of such a combination shall include the source code for the parts of ImageMagick used as well as that of the covered work."

We could add explicit exceptions for each specific program, or more in general we could make an exception to allow linking of the FLIF encoder with all software that is released under a particular set of licenses (a set that would include basically all FOSS licenses).

If proprietary software companies want (to pay for) a license exception to be able to include the FLIF encoder without triggering the GPL requirements (or the FLIF decoder without triggering the much weaker but still nontrivial LGPL requirements), then that is something I would consider on a case-by-case basis. But I don't see why we should immediately give all proprietary software a gratis FLIF implementation, which is what would happen if it would be released under a weak, permissive license. Yes, that would probably help to make the file format more popular/mainstream, but it wouldn't bring us any closer to achieving the broader and more important goals of software freedom.

In other words, in my mind, giving an "unfair" advantage to free software projects (and a disadvantage to proprietary software projects and hyper-locked-down platforms like iOS) is a feature, not a bug.

dlemstra commented 8 years ago

I really don't understand the '(to pay for)' remark. If it is free software then why do you want to earn money from selling your library to companies.

Even with the clause I don't think we could still not include support for writing FLIF in our binaries. We would like our end users to use the binaries that we provide without having to open source their work. And ImageMagick is not just an application, it can also be used as a library. That means that someone could make a commercial application that uses the ImageMagick library to encode FLIF images. I really don't see the benefit of letting us use it but only let commercial applications use it by using our library.

jonsneyers commented 8 years ago

It is free as in libre, which is not the same as gratis. I'm a proponent of free (libre) software. I don't particularly want end users/developers to not have to open source their work. Giving software developers that want to use FLIF the choice between

a. open sourcing their work, or b. going through the trouble of either

  1. obtaining a license exception (which can be either something they would have to pay for, or it could be gratis, but in any case it would be a hurdle), or
  2. implementing their own FLIF encoder
  3. circumventing the issue by using another file format, possibly at the cost of worse compression

seems to be a better strategy than just unconditionally allowing them to do whatever they want, closed or open source. If the goal is to promote software freedom, that is. If the goal is to promote FLIF (or ImageMagick), then the optimal strategy would probably be different.

Perhaps ImageMagick could follow FFmpeg's example and have a configure --enable-gpl option that includes the encoder, while otherwise only the decoder is included (and the encoding could still be done by calling an external delegate)? Or do the ImageMagick devs insist on having only one version of the binaries with only one license?

dlemstra commented 8 years ago

ImageMagick allows linking with GPL libraries. You can link with DjVu for example. Under Windows we also use a configure link tool that has an option to build ImageMagick with GPL libraries. This means that users would have to build their own version from source. We will add an ImageMagick encoder for FLIF but it will only be available in a 'GPL compatible build' of ImageMagick. But we cannot include it in the binaries we provide because those are licensed under Apache 2.0.

I think you are making a really good point with the following sentence:

If the goal is to promote software freedom, that is. If the goal is to promote FLIF (or ImageMagick), then the optimal strategy would probably be different.

What is the goal of this library? Is it a library for a new format that provides an alternative for PNG/WebP that can be used by everyone very easily? I think your current license strategy leans more towards promotion of software freedom.

I personally see open source as modern day community work. I try to create something that makes the life of people or companies easier. And if that includes companies earning money with the product that I created thats okay with me.

vyp commented 8 years ago

And if that includes companies earning money with the product that I created thats okay with me.

Maybe I'm being a bit pedantic, but I think the phrase should "... includes companies making nonfree software ...". Because earning money is of course totally a fine thing to do with free software too.

@jonsneyers I don't think "promotion of software freedom" is a bad thing as @dlemstra seems to suggest, I think it's desirable actually. But sometimes the benefits/costs need to be weighed, even when the primary thing you care about is preserving software freedom. For example, this page, despite its title, talks about situations where using a lax license is actually more beneficial to the free software community.

Despite what I just said though (I said it because it plays devil's advocate and will therefore hopefully help you with whatever decision you choose to take), that page also says that one should not use the lax (LGPL) license if the library provides a "significant unique capability", and the FLIF format does provide this. So if your # 1 concern is for software freedom for all, then this should be viewed as a good thing. Because it simultaneously limits nonfree software while giving the free software community a massive advantage. (If you agree that nonfree software is bad, which you may not of course.)

However, if your number # 1 concern is world domination for just the FLIF format itself (which is completely okay too), I think it's obvious that a lax license will be better than a copyleft one, because it will have less barrier to adoption for nonfree software. (This doesn't mean you necessarily don't care about free software either of course.)

I think though that world domination can still be achieved with copyleft, due the "significant unique capability" the FLIF format provides, and the pressue it will therefore put on nonfree software to support it. (And remember, by doing so, you're also helping with world domination for free software as a whole too.)

vyp commented 8 years ago

Sorry @jonsneyers I completely missed your second last comment, in which you already say that you care more about software freedom ("broader and more important goals of software freedom"). If the FSF have given you the go ahead, who am I to argue against them (in terms of legal issues)?

My preference would be to choose a more general exception (if you choose to do what the FSF suggested), because that way it's "less hassle" for free software projects (which use a lax license) to link to the encoder. Your choice of course. As for the wording, you will have to contact the FSF again. I would imagine something like "[...] all Free Software licenses as approved by the Free Software Foundation [...]".

Btw, I also think the 'paying for a GPL exception' is an okay compromise, although maybe you should first try to convince anyone who wants one to make their software free.

Calinou commented 8 years ago

I probably dislike proprietary software more than you, yet I would strongly encourage the FLIF project to use the MIT license, because:

The Apache 2.0 license is nice, but too long for what it really does. You also lose compatibility with GPLv2 projects, which is still something very important today (sadly).

It might be possible to find a "compromise" by using LGPLv2.1+, with a static linking exception (very similar to the wxWidgets license). Still, you would end up with a long and complex license.

sipa commented 8 years ago

I think the question is what change in the ecosystem you are pursuing. If the goal is to get more free software to be adopted, GPL and related licenses are likely most appropriate. But if the goal is the adoption of an open standard, the best way may be to use less restrictive licenses.

jonsneyers commented 8 years ago

When PNG was created, a permissive license made a lot of sense because the goal was clearly to create an alternative to the then-patent-encumbered GIF format.

Since open standards are already the norm in the domain of lossless image formats, I think we can now aim for something more :).

peripatetes commented 8 years ago

PNG also had huge technical advantages over GIF: alpha, gamma, Adam7, etc, plus a compression advantage over GIF that was about as large as FLIF's advantage over crushed PNGs, in an era when bandwidth was scarce and people were vitally concerned with shaving kilobytes to have reasonable load times on 56k modems. People were also faced with legal threats if they continued to use GIF, which was a very compelling reason to switch. And formats and standards were much less entrenched in general than they are now. Yet it took a full decade for PNG to become widely enough adopted that passable support for the format reached the mainstream (alpha support finally added to IE in IE 7, 2006- roughly the same time when Firefox adoption finally became more than just a trickle).

A new format has a very very hard road to gain real adoption unless the juggernauts of the Internet get behind it. FLIF is impressive, and I hope it's adopted, but it doesn't have the kind of overwhelming advantages that could spark a transition despite forbidding license problems. And until it's widely adopted, having support for it when competitors don't isn't going to be a selling point for any free software project.

If you look at the FSF's advice they say "if developers are already using an established alternative library released under a nonfree license or a lax pushover license, then we recommend using the GNU Lesser General Public License (LGPL)."

If you ask the developers of any successful open format for their advice, they will suggest using MIT or something similar. The FSF's advice recommending open formats be Apache licensed applies in some ways to FLIF (as a next-gen lossless format, FLIF's main competition is BPG, which is unfree).

I think using some variant of LGPL for the encoder and a permissive license (Apache, MIT, etc) for a reference decoder is much more likely to accomplish your goals for the project than the present license.

You're absolutely right that FLIF will not see practical adoption unless decoders become ubiquitous. But many projects, both proprietary and open source, can't use LGPLv3 libraries. The LGPLv3 is incompatible with GNU 2.x licenses, and many projects that have permissive licenses won't incorporate or link to LGPL code as a matter of policy. For many kinds of proprietary projects, especially embedded devices, even if an organization is more than happy to contribute back any changes they make to a library they use, they aren't in a position to deal well with the LGPLv3's requirement that users be able to upgrade the library as they see fit. And many major proprietary software companies, including those you mention (MS, Adobe), won't use LGPL libraries for any of their main products because it worries their legal staff. If you want to see the decoder spread, it needs a more permissive license.

I don't think there's really any chance of someone deciding to try to displace the reference decoder with their proprietary improved version. Nobody's going to pay license fees for a decoder when a good freely-available open-source reference implementation is available. The reference implementations of other free formats have not had problems with that kind of thing.

It's more likely that someone might try to do something like that with the encoder. Use of the LGPL for the encoder would still require people to contribute back their changes. Having the encoder be LGPL instead of GPL allows many more open source projects (including ImageMagick etc) to use it. It would also put pressure on people to become LGPL compatible. I do think it exceedingly unlikely that Adobe would include a LGPL encoder in Photoshop - again, their legal department won't let them (too much of a compliance risk for their primary products) - but again, unless the format has wide adoption, Adobe not including it wouldn't put them at a competitive disadvantage, it puts FLIF at a disadvantage.

jonsneyers commented 8 years ago

I am currently considering MPL 2.0, maybe for both the encoder and the decoder. Compatible with proprietary software (like MIT or BSD), yet requires share-back (like (L)GPL). I think this might be exactly the license we need. On Jan 21, 2016 23:41, "peripatetes" notifications@github.com wrote:

PNG also had huge technical advantages over GIF: alpha, gamma, Adam7, etc, plus a compression advantage over GIF that was about as large as FLIF's advantage over crushed PNGs, in an era when bandwidth was scarce and people were vitally concerned with shaving kilobytes to have reasonable load times on 56k modems. People were also faced with legal threats if they continued to use GIF, which was a very compelling reason to switch. And formats and standards were much less entrenched in general than they are now. Yet it took a full decade for PNG to become widely enough adopted that passable support for the format reached the mainstream (alpha support finally added to IE in IE 7, 2006- roughly the same time when Firefox adoption finally became more than just a trickle).

A new format has a very very hard road to gain real adoption unless the juggernauts of the Internet get behind it. FLIF is impressive, and I hope it's adopted, but it doesn't have the kind of overwhelming advantages that could spark a transition despite forbidding license problems. And until it's widely adopted, having support for it when competitors don't isn't going to be a selling point for any free software project.

If you look at the FSF's advice they say "if developers are already using an established alternative library released under a nonfree license or a lax pushover license, then we recommend using the GNU Lesser General Public License (LGPL)."

If you ask the developers of any successful open format for their advice, they will suggest using MIT or something similar. The FSF's advice recommending open formats be Apache licensed applies in some ways to FLIF (as a next-gen lossless format, FLIF's main competition is BPG, which is unfree).

I think using some variant of LGPL for the encoder and a permissive license (Apache, MIT, etc) for a reference decoder is much more likely to accomplish your goals for the project.

You're absolutely right that FLIF will not see practical adoption unless decoders become ubiquitous. But many projects, both proprietary and open source, can't use LGPLv3 libraries. The LGPLv3 is incompatible with GNU 2.x licenses, and many projects that have permissive licenses won't incorporate or link to LGPL code as a matter of policy. For many kinds of proprietary projects, especially embedded devices, even if an organization is more than happy to contribute back any changes they make to a library they use, they aren't in a position to deal well with the LGPLv3's requirement that users be able to upgrade the library as they see fit. And many major proprietary software companies, including those you mention (MS, Adobe), won't use LGPL libraries for any of their main products because it worries their legal staff. If you want to see the decoder spread, it needs a more permissive license.

I don't think there's really any chance of someone deciding to try to displace the reference decoder with their proprietary improved version. Nobody's going to pay license fees for a decoder when a good freely-available open-source reference implementation is available. The reference implementations of other free formats have not had problems with that kind of thing.

It's more likely that someone might try to do something like that with the encoder. Use of the LGPL for the encoder would still require people to contribute back their changes. Having the encoder be LGPL instead of GPL allows many more open source projects (including ImageMagick etc) to use it. It would also put pressure on people to become LGPL compatible. I do think it exceedingly unlikely that Adobe would include a LGPL encoder in Photoshop - again, their legal department won't let them (too much of a compliance risk for their primary products) - but again, unless the format has wide adoption, Adobe not including it wouldn't put them at a competitive disadvantage, it puts FLIF at a disadvantage.

— Reply to this email directly or view it on GitHub https://github.com/FLIF-hub/FLIF/issues/192#issuecomment-173738921.

Calinou commented 8 years ago

The MPL's copyleft is pretty weak, I doubt you will get any "forced" improvements by using that license. (It works on a per-file basis, as far as I know).

jonsneyers commented 8 years ago

"Pretty weak copyleft" is still better than the "no copyleft at all" you would get with a MIT/BSD license.

LGPL would give better copyleft, but it does not allow proprietary software to use the encoder/decoder except via a shared library (but most closed-source software seems to prefer or even require static linking).

One other option could be to make the decoder MPL and the encoder LGPL, with the assumption that most applications only need the decoder while most of the potential improvements would be in the encoder.

Or LGPL everything, with some kind of extra clause to allow static linking?

Basically the license should be permissive enough to allow widespread adoption even in the proprietary world, but copyleft enough to avoid proprietary forks of the format that might become the de facto standard (by virtue of being better or being pushed by a big player). It's a tricky balance.

On Fri, Jan 22, 2016 at 8:37 AM, Calinou notifications@github.com wrote:

The MPL's copyleft is pretty weak, I doubt you will get any "forced" improvements by using that license. (It works on a per-file basis, as far as I know).

— Reply to this email directly or view it on GitHub https://github.com/FLIF-hub/FLIF/issues/192#issuecomment-173834849.

c0nk commented 8 years ago

Please use MIT/BSD for the decoder. This would lead to maximum adoption rate. The arguments for copyleft mostly don't apply to a decoder. If the decoder is released as LGPL someone will just end up releasing a MIT/BSD decoder. I think it would be most advantageous to reduce the chances of that and just get everyone contributing to this project.

derrekbertrand commented 8 years ago

Just a random dude's 2 cents: I recently got in a heated argument with a client over GPL'd components. Business people don't understand copyleft, and don't understand it's goals. They forbid that we use any GPL/LGPL software in their project, even though all they'd need to do is have a link to the license and repository (we didn't plan to make modifications).

Even these little considerations scare the shit out of the ill-informed. I encourage LGPL and it's goals, but MIT/BSD is what you want for the decoder. In the image format world it is about adoption. The other part of this is to make sure and have a clear implementation standard to avoid fragmentation of this project.

I'm very excited about this project, and been following it for a while.

jonsneyers commented 8 years ago

@sipa and me are now considering to move to

This is what was suggested by @dlemstra early in this discussion.

We think it makes sense to keep a copyleft license for the encoder, since that's the part where most of the improvements can be made. Moving to a lax license for the decoder makes sense to improve adoption, as many of you have commented.

c0nk commented 8 years ago

What about using the Apache2 license for both the encoder and the decoder? It would simplify the license situation for the project.

The LGPL has no real advantages over Apache2 for a small project like this. It does have disadvantages though. It would only require minimal effort for someone knowledgable in this stuff to reimplement the encoder given the spec. If you agree with this, you must also agree that putting the LGPL on it won't really achieve any of your goals. It will just lead more implementations. They will simply be forks that don't use any of your source code.

The smaller a codebase is, the less useful the GPL is. For sufficiently small projects (and I think that includes the encoder in question here) the GPL only does the project harm by creating more fragmentation in the community and getting less people to contribute.

jonsneyers commented 8 years ago

I don't agree that reimplementing the encoder requires minimal effort. The spec (which does not exist yet) will only define the decode stream. While it is relatively easy to implement a minimalistic encoder which produces valid, but suboptimal FLIF files, it is considerably more effort to implement a good encoder. Doing that from scratch while avoiding copyright infringement (i.e. doing a cleanroom reimplementation) is a considerable effort.

I don't see how the (L)GPL would cause less people to contribute to the encoder (except maybe potential contributors who are for some reason allergic to the (L)GPL, but that argument works both ways: I can also imagine potential contributors who are allergic to lax licenses). I do see how a a non-copyleft license could tempt people to create improved encoders without sharing back their code.

peripatetes commented 8 years ago

I don't know that there really are people who are "allergic to lax licenses," since even the most hardline Stallmanites are expected to recommend lax licenses in some circumstances. But if such people exist, they obviously wouldn't be willing to sign your CLA.

The CLA makes a lot of this problem less pressing. Without it, having different licenses for parts of the same project could cause hassles; with the CLA you can e.g. reuse code when it seems important to do so. Also, if circumstances change you can adjust things. For instance, if the specification goes through a standards process like IETF, the danger of incompatible derivative formats would be reduced and the importance of having a universally usable encoder would be increased, so you might want to consider a more permissive encoder license as part of that process. With the CLA you can safely postpone such a decision and have the LGPL now.

I can see your reasoning for wanting a copyleft on the encoder, and I think the Apache2/LGPL combination makes a lot of sense.

c0nk commented 8 years ago

If you insist on copyleft for the encoder, wouldn't the MPL make the most sense? That would oblige people to share their improvements to the encoder but it would also hinder adoption less.

DominikDeak commented 8 years ago

I'm not a big fan of the encoder and decoder being released under different licenses. That means I can statically link the decoder, but I must dynamically link to the encoder because of the differing license? It's an unnecessary complication. Use a single, universally applied license. Keep it simple, guys.

wolftune commented 8 years ago

@DominikDeak if all devs would "Keep it free/libre/open, guys" then it would be maximally simple, we'd never need any copyleft licensing ever.

peripatetes commented 8 years ago

DominikDeak, you can statically link the encoder, too, if your project is under a LGPLv3 compatible open source license. And if you want to think of the project as having a single license, go ahead and think of it as being LGPLv3, since all of it can be used under that license. I don't see why you should be offended by the authors affording extra flexibility beyond that for people who need it.

Given that the authors have made their preference for copyleft very clear throughout the two months of discussion, I think further clamoring for them to give the entire project a permissive license may make little sense unless and until circumstances change.

They committed the LGPL/Apache license change the other day. One could keep discussing different license options until the Sun goes dim, but if I were them I'd close this bug for now.

jonsneyers commented 8 years ago

Yes, let's close this discussion for now. We can reopen it (or start a new one) at some point if needed.