At the same time, it also introduces ambiguity and uncertainty. The GPL-3 doesn't define what "dynamic linking" is. While it might be relatively clear for the

At the same time, it also introduces ambiguity and uncertainty. The GPL-3 doesn't define what "dynamic linking" is. While it might be relatively clear for the simple case of a "static" or "shared" library, what about: - libraries opened with dlopen - libraries with an equivalent non-GPL licenced equivalent e.g. readline, which has a BSD-licenced reimplementation - libraries accessed via IPC to a coprocess hosting the library In all these cases, I can be intimately tied to the API/ABI of a library but unsure of my legal status with respect to GPL-3 compliance obligations. While I understand the general intent, I'm unhappy that this is open to interpretation and that the legal standing of this is not at all clear cut. Likewise with the anti-Tivoisation clauses. While again I understand and agree with the intent, I feel that inserting the language to combat a single problem has damaged the generality of the licence and made it much less attractive to many as a result. While I do like the GPL-2 and GPL-3 licences, I think it's fairly clear that while GPL-2 was acceptable to many companies the GPL-3 is not, and while I may disagree with their reasoning for their stance, the practical fallout from it has been quite detrimental. I've certainly started using BSD or MIT licences more frequently for recent projects, where I would previously have used GPL-2 or -3 by default, simply because the licence profusion has made licence compatibility between a project using a lot of differently licenced shared libraries a very real problem.