
Why you shouldn't use the Lesser GPL for your next library - cpeterso
http://www.gnu.org/licenses/why-not-lgpl.html
======
tytso
The problem with the readline library example is that there are BSD versions
of the library. So you can do something like this:

[https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/s...](https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/ss/get_readline.c)
[https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/s...](https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/ss/listen.c)

So riddle me this. The ss library is under an MIT-style copyright license.
Suppose you have a proprietary program (Say, the Solaris kerberos v5
administration daemon client, to take a not-so-hypothetical example). Now
suppose it dynamic links against a version of libss that might dlopen
readline, or might dlopen editline, and if neither is available, libss will
fall back to fgets. Now suppose Solaris distributes their kadmin program
independent of the version of libss distributed as part of e2fsprogs. Quick!
Is there a copyright violation, and if so, who committed it?

~~~
comex
As it happens, this exact argument was put forth by the "at least one
application program" that converted to free software:

[http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...](http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-
CLISP-is-under-GPL)

It was never actually resolved, because the CLISP author decided that making
his program free software would be a good idea for other reasons anyway. In
the past, I would have disagreed with RMS's insinuation that a GPL violation
would occur, because, as stated:

> So the only reason why you may object is that my lisp.a has an INTERFACE
> that allows it to be linked to libreadline.a . As far as I know, only the
> readline CODE is copyrighted, not its INTERFACE. (Would you object because
> my libnoreadline.a has a similar interface?)

Only... we just got a US court decision that APIs _are_ copyrightable.
Although readline's API is much simpler than large parts of Java, it's
substantial enough that I'd argue the decision nevertheless implies that
libedit is a copyright violation. Which I find ironic, since most of the
programs affected by the decision are free software clones of proprietary
software, not the other way around.

~~~
saurik
The court opinion stressed pretty strongly that Google's usage of the Java API
was never actually intended to build an interoperable implementation (stating
that Google was unable to point to any specific examples of code that would
even be interoperable ;P) but instead to build a non-interoperable platform
that was heavily inspired by the work that was put into Java. I think Google
could have made a better case for attempting to be interoperable in certain
ways (such as with libraries as opposed to "apps"), but apparently they
didn't, and in fact came off quite strongly as trying to build their own
unrelated-to-Java platform for various technical and business reasons. It
still seems to be the case that if you are building a system whose goal is
truly to be interoperable (such as libedit is to libreadline) you would not
run into problems. For much more detailed commentary and argument (as well as
quotes from the opinion), I encourage you to read my comment from that thread:

[https://news.ycombinator.com/item?id=7723853](https://news.ycombinator.com/item?id=7723853)

~~~
zAy0LfpBZLC8mAC
I don't have a clue what Google's specific goals were, but couldn't an
argument be made that compatibility with existing knowledge of developers is
also a form of interoperability, and in particular one that needs to be
protected from monopolization?

~~~
saurik
At that point copyright becomes meaningless (though if you are willing to go
that far that's great: I don't see anything inherently incorrect about the
position "copyright is meaningless"): "I needed my photograph to look like
yours because everyone was familiar with yours and I wanted them to feel the
same way as they did when they saw yours".

~~~
zAy0LfpBZLC8mAC
Well, yeah, I don't see much inherently meaningful in copyright either, in
particular because drawing boundaries is ... difficult, to say the least.

But I think your example still doesn't quite capture what I mean ... even
though, well, maybe it does, but let me explain ;-): What I had in mind is in
particular that getting familiar with an API requires effort, so it's kindof
an investment on the part of the developer. After all, an API is as much a
human/machine interface as it is a machine/machine interface. As such, it is
problematic to allow anyone to have a monopoly on that investment, essentially
a monopoly on the use of those developers' knowledge. And protection of
investments is one of the arguments (the argument?) for interoperability
exceptions--so, why only for machine/machine interoperability and not also for
human/machine interoperability?

I guess the "investment" aspect doesn't work that well for your example, but I
still can see some value in the argument, in particular if you apply it to DRM
(type) systems and culture in general.

~~~
saurik
For me, part of the difference is whether the interoperability is complete or
fuzzy: I don't feel like you can be "only sort of interoperable", and that
seems to be the big difference between the human/machine and machine/machine
examples (it isn't that the interoperability is a different kind of
interoperability, it is that it is a different level of precision in the kind
of interoperability). A developer of will notice important differences in Java
vs. Android.

To explain some more with my photograph comment: the photograph might have
taken time and context and thought on behalf of an entire population of
viewers to come to some "meaning"; maybe this is more obvious if we take a
storyline from a popular television show: before the show people didn't care
about the topic of the show, but after the investment, quality, and success of
the show now people really like that topics and in particular the story
progression that went along with it.

People are familiar with that story: to really allow those people to feel good
about the new story, maybe it has to be similar to the old one? If you go down
this path for a while, you start reading about idea/expression differences as
they apply to literary and visual works: high-level plots and themes are not
protected, but specific details and timelines are. The idea of organizing code
into packages and classes is not, but the specific choice of what classes to
put in what packages and what they are named are.

FWIW, I personally feel like a lot of the benefit of trying to be
"interoperable" with someone's perception of how to program is sufficient to
be at that higher "idea" level: when I use C# or Objective-C (which in many
ways feel similar to Java and in the case of C# was pretty much designed as a
direct replacement for Java) I am highly familiar with them despite not
feeling like they are the same: I gain a lot of the benefit of C# and Java
having similar ideas, despite the fact that they clearly have different
expressions.

Now, that said? I continue to appreciate the idea that this is all a stupid
distinction: but if you erase this distinction I am not certain where you
still draw the line for claiming copyright on anything. Given the idea
"investment in expression should be protected" (an admittedly-oversimplified
version of "copyright"), I don't think you still have "investment by consumers
in content should be inherently reusable by other creators". I could be wrong,
however, and would love to hear more ideas.

------
trebor
I don't use GPL libraries because of the tyrannical copy-left clause. If I
want to GPL mine, then I'll make that choice. But I won't use a single library
that'll force me to choose GPL—I'll just write/find a replacement. So go
ahead, make your library GPL instead of LGPL/MIT/BSD/MPL/APL/ETC and it'll sit
unused and ignored (for the most part).

I also really appreciate what morbius wrote in this same thread:
[https://news.ycombinator.com/item?id=7757677](https://news.ycombinator.com/item?id=7757677)

~~~
phillmv
Tyranny is a strong word for "please only use this free code in the ways that
I have outlined".

~~~
eridius
It's Tyranny because the express goal of the GPL is to force all software to
be free and open source. It's one thing to just say "my library has
restrictions, please obey them", but the GPL is designed to try to infect as
much of the software world as it possibly can, forcing via legal measures
other software to catch its copyleft virus.

~~~
stcredzero
Because using coercion in the interest of "freedom" always works out so well.

~~~
zAy0LfpBZLC8mAC
What is your definition of "coercion" that you are using here?

~~~
stcredzero
The same sense that the FSF uses coercion when they describe participation in
closed-source.

------
enjoy-your-stay
I thought one of the main reasons for the LGPL was to attract more people to
use and contribute to your library, whether open source or proprietary; with
the added advantage that developers efforts were not being wasted with
needless duplication.

This approach seems to seek to create a much stronger 'us' and 'them' mindset
which can only alienate a large number potential contributors.

~~~
zAy0LfpBZLC8mAC
One could also look at it as seeking to avoid needless duplication even more:
By trying to give free software an advantage by being able to make use of
GPLed libraries, or possibly to motivate people to release their new software
under GPL because that allows them to make use of GPLed libraries, you might
be able to avoid future work on the competing proprietary silos, instead
focusing resources that are used for developing the particular kind of
software on the one commonly developed free software solution, thus creating a
much stronger 'us all together' instead of any kind of 'us' vs 'them'.

------
josephschmoe
The problem, I think, with the GPL community is that they refuse to accept
that almost all software developers make a living by working for a company,
and feel that it is unjust to refuse their libraries to others who do the
same.

And, because their software is open source, someone will inevitably create a
better competing library based on the ideas behind the GPL one. That new
library? Apache license.

~~~
pessimizer
I'm having trouble parsing your first sentence. There's a _problem of refusing
to be accepted that almost all, and unjust to refuse to others that do the
same._ One or both of us are making a sign error.

Are you saying that the "GPL community" don't want software developers that
work for a company to use their libraries?

~~~
josephschmoe
More succinct point: I can't use GPL software libraries at work. I have no
interest in developing under GPL because it would expose others to the same
problem.

There are ways the GPL community could attempt to incorporate individuals like
me, but to be honest, I much prefer a world where anyone can use any open
source code however they wish.

~~~
davexunit
Have you considered that the problem could be that your company is writing
proprietary software?

------
Shorel
> Proprietary software developers have the advantage of money; free software
> developers need to make advantages for each other.

This actually confuses 'libre' with 'gratis'.

~~~
morbius
I actually think it's a subtle admission that it's impossible to gain any
significant amount of revenue by "selling" free software.

I love the open-source/libre philosophy but it's not viable for a business. I
think the more pressing question is whether software even _should_ be a
business. Many think that there's a certain rift between users and developers
that still exists today, and I have to agree.

1\. Users push for increased ease-of-use 2\. Developers implement more simple
systems 3\. Power users complain about the loss of features 4\. Developers add
back in missing features 5\. All users complain about software being a
convoluted mess

The programmer is now left at a disadvantage: he can either continue working
with a codebase that's disorganized and inelegant, or he can start over from
scratch. In a business environment, starting over from scratch would not be an
economically viable situation, while continuing with the older codebase would
be the wiser choice (even thought it may piss off users). Users are left
disadvantaged; they can continue to use the older software versions but run
the risk of poor security and an inferior interface.

With free/libre software this problem disappears, as a talented programmer
with the user's interest can simply fork the older version and continue to
implement a better interface and security updates while retaining a cleaner
codebase. However, the endless stream of forks fragment software and hinder
unified progress. Also, the original developer is more likely to abandon the
software application due to lack of funds and interest.

It's a lose-lose situation. There is no one perfect development methodology.
The open-source philosophy is more effective in the long run, but proprietary
software is the only viable method to sustain a business. Open-source
advocates will often point to Red Hat as a counter-example, but it's important
to note Red Hat is the exception to the rule. It's also even more important to
note that Red Hat isn't doing so hot these days, either.

Where the FSF falls down is in its inability to compromise. A number of
companies have achieved success with a mixed closed/premium source model, such
as JetBrains. While this again allows much more freedom than a standard
proprietary setup, the FSF will always refuse to acknowledge any software with
ANY proprietary bits in it.

They're now incredibly out of touch with Silicon Valley, and it isn't
difficult to see why. They continue their militant and expressive attitude
instead of expressing gratitude to those that push OSS forward.

Apart from GNU, the GPL and its many variants, the FSF is largely irrelevant.

It never had to be that way.

~~~
pavlov
_Where the FSF falls down is in its inability to compromise_

They're an ideological foundation. There are already plenty of others who
compromise in the name of pragmatism, and there's nothing wrong with that.

FSF represents a viewpoint that is constantly under threat from some of the
world's richest corporations such as Apple. If they became the "Free And Also
Not-So-Free (As Long As It's Useful) Software Foundation", they can just as
well close shop.

 _They 're now incredibly out of touch with Silicon Valley_

Certainly this is a positive thing in the long run? There's much more to
technology than just the Valley players' interests.

~~~
morbius
My frustration doesn't stem from the FSF's stubbornness; my frustration stems
from the fact that they don't realize how it's holding free software back. The
EFF has been very successful at accomplishing their goals because they, unlike
the FSF, understand diplomacy and relationships.

~~~
pavlov
I can't really see how non-GPL free software has been held back. If anything,
it's been successful beyond most people's dreams.

Most servers are powered by software under Apache and MIT licenses; companies
pick what they want and mostly don't give back. The dominant operating system
on personal devices is Android, which is free but nevertheless deeply tied
with a corporation's interests and developed in secrecy using the same
principles as proprietary software.

What would FSF gain by supporting that kind of software freedom, other than a
reputation as nice guys? That model of freedom has already won, and from FSF's
point of view, it's not much better than traditional closed software.

~~~
eridius
Imagine what it would be like if the FSF had been helping instead of fighting
this type of open source development?

------
benatkin
The title would be perfect for an article arguing for a non-copyleft license
instead of the LGPL. Some who create projects mistakenly believe that if they
use the LGPL or some other copyleft license that most of the problems with the
GPL go away. I think Firefox has lost some developers to Chromium because of
Chromium's simpler license. The EPL is also frustrating to some who would like
to use Clojure (Scala is under a simpler license). I tried writing such an
article:
[https://gist.github.com/benatkin/98e28b329842f021e6d3](https://gist.github.com/benatkin/98e28b329842f021e6d3)

~~~
danray
Good points in this article. Note as well that the LGPL requires you to permit
reverse-engineering of your proprietary code. There are good reasons for this,
but it's unrealistic in a lot of organizations.

A lot of developers (and a lot of lawyers!) rely on the rule of thumb that
you're fine under the LGPL as you don't modify and don't statically link.
That's a fine rule of thumb, but that's all it is.

------
nitrogen
Pragmatically, the FSF should be advocating for the LGPL over BSD or Apache,
since GPL over LGPL is already a lost battle.

------
cpeterso
What's the difference between Mozilla supporting EME to maintain market
relevance among proprietary competitors and the FSF licensing glibc as "Lesser
GPL" to do the same?

------
jeena
I'm really happy there are people fighting for a world like this. It doesn't
matter that they can't get 100% of the market, just by advocating for a better
alternative makes the whole thing better.

