Hacker News Reader

Comment by parvenu74 | Hacker News Reader

I want to root for it but I think the LGPL license ruins it as long as there are BSD or MIT licenses alternatives that are good enough. Firefox might implement it but I think there’s zero change that Chromium or Safari add support.

View on HN

I think that LGPL for the encoder is exactly the right choice. A format's strength is in uniform support; taking a MIT-licenced encoder and making an improved incompatible format won't be great for end users.

Is it better that no tools will actually be able to export the format?

Also, a GPL-licensed encoder will in no way stop incompatible extensions.

Uh, LGPL explicitly doesn't prevent even proprietary software from using the encoder?

Not explicitly, but in practice, it does. It is often not viable to jump through the hoops required to do it. That is, if your lawyers will even let you try.

> It is often not viable to jump through the hoops required to do it.

Having it as a dynamic library isn't that problematic a hoop is it?

>That is, if your lawyers will even let you try.

This may be a genuine issue. Many have a strict "nothing related to GPL" policy driven at least partly by misunderstanding or paranoia.

Having it as a dynamic library is not enough. It has to be a dynamic library tgat you can replace. This doesn’t work when, for instance, distributing through many app stores.

Proprietary software can include the encoder. This is fine.

But any changes to the encoder itself remain under LGPL and get published. This is the point.

They could conceivably buy a different license from the author, if the author were to be interested in that, and if the author's the only contributor and didn't derive their code from othe LGPL code, etc, etc.

There's also an Apache 2 licenced decoder mentioned, perhaps with exactly this in mind...

Only the encoder is LGPL, the decoder is Apache, web browsers only need a decoder.

Reply on news.ycombinator.com