FSF Wastes Away Another "High Priority" Project
phoronix.com
phoronix.com
One may equally well ask why LibreCAD insists on GPLv2 (without upgrade clause), and does not switch to GPLv3 if they want to use GPLv3 libraries.
This story only seems to be a case of political pressure to do so, regardless of the effort a rewrite may cause. In this regards, FSF is clearly putting the value of the license above the value of the software itself.
This is why I can't endorse the GPL: it is mainly motivated and designed to deny authority over software ownership, not for actual openness. If somebody really want to open up a piece of software, Public Domain is the way to go.
I mean, there may be times when the FSF does stick foolishly to principles but the "because we've decided it's OK to be halfway open and accept putting copyright control in the hands of a random company, you should bend for us" argument does not seem compelling.
It sounds like the mom and kids dynamic "can't I break the rules this one time, [XXXX very 'just, reasonable' sounding excuse]". The reason you have blanket principles is that otherwise someone finds a single exception that sounds emotionally compelling, then the exception becomes the hole that more or less everyone just drives through and "inconvenient" principles go out the window.
Also, the article doesn't say anything one way or the other about releasing the library LGPL which would seem appropriate for a library which could then be used by a commercial product.
Wasn't that the main motivation for the LGPL?
The official statement is: "Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.
This is why we used the Lesser GPL for the GNU C library. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another—no problem for them, only for us."
Actually, rms recommended a more liberal license for Ogg/Vorbis.
This is the most relevant section I can quote:
> Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.
From https://www.gnu.org/licenses/why-not-lgpl.html
Stallman's recommendation of a liberal license for the vorbis libraries seems similar: there are already proprietary standards and proprietary libraries for lossy audio compression, so using a copyleft license won't convince anyone to switch their license.
This particular instance with LibreDWG is the polar opposite of that: no other library exists that does what LibreDWG does, so it makes sense to keep LibreDWG on the GPLv3, to entice projects like LibreCAD to use the GPLv3.
The sort of entitlement that this request displays is somewhat astonishing -- do the LibreCAD developers really expect the FSF to back down not only on its principles, but also its strategies?
Stallman is a zealot, and this is what zealots do.
Also I think this issue might be fixable if there's enough outcry about it. And they really are in a tough situation because of this.
For people who don't agree with the FSF's idea of "free software" or don't want the politics that goes along with the GPL and FSF, there's always the BSD license. Though it really wouldn't help in this case, since the library in question belongs to the FSF.
I'd assume that a "high priority" project would have a lot more activity than that, especially because there hasn't been a binary release yet( http://www.gnu.org/software/libredwg/ ).
FSF has since created GPLv3, under which all their code is now released, for all GPLv2 licenced code out there which is using the FSF's original GPLv2 licence there is no problem since it has the 'or later' clause. The problem here is that Ribbonsoft removed the (or later) clause and thus making it incompatible with future GPL versions.
And what is this 'tough situation' they are in?
This, and rebelling against the Roman occupation of the Holy Land.
I have a hard time blaming FSF for wanting other projects to upgrade to GPLv3 instead of downgrading their own project to GPLv2. It could almost be said that it's the whole point of the GPL.
And, like you said, this should be a surprise to absolutely nobody.
No GPL licences crafted by FSF has this limitation.
On the other hand, it seems odd to me that the kind of person who would be hung up by licenses is interested in using free software. Why not just buy AutoCad at this point?
I guess that's sort of the FSF's biggest mistake. They act like there are no alternatives. Though they seem to understand that with LGPL:
This is why we used the Lesser GPL for the GNU C library. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another—no problem for them, only for us.
Broadly speaking the rule of thumb is that if something makes use of internal knowledge of GPL code implementation or function (i.e. unique data structures/objects/functions that are not considered "standard"), it's considered a derivative work (this is also how the Linux kernel approaches GPL vs non-GPL drivers, too). If all it were to take was to adapt and repackage a GPL project as a dynamically loaded library, the GPL would be meaningless.
In my mind, the really hairy area is where certain projects seem to be allowed to define "public" APIs that surrender GPL protection and allow use of closed binary libraries (i.e. the Linux kernel's public driver interface or Octave's MEX interface). Or what happens when the BSD folks just copy your API and re-implement everything (undermining the uniqueness of the GPL software's internals)? Don't bring this up to the FSF though, they suddenly switch from being eloquent to pretending to be dense.
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=...
The BSD crowd has been slowly chipping away at replacing all the GNU stuff they expediently adopted following the AT&T lawsuit.
http://features.slashdot.org/story/13/01/06/163248/richard-s...
"What project is using the wrong license? by gQuigs
...
RMS: If I could magically change one program to GPLv3, it would be Linux. ... Another program that is important to convert is LibreCAD. This is more than a fantasy: the developers of LibreCAD are working on replacing the old GPLv2-only code that they included, so as to switch to GPLv3-or-later. Would you like to help?"
Like the software, the license isn't a pain in the arse either.
The GPL has an upgrade clause.
> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Why doesn't this apply?
It is short sighted essentially freezing the legal status of a project forever, and it is even more idiotic to blame the FSF for being incompatible with projects that voluntarily cut off forward-compatibility by removing the "or any later" clause.
Or you remove the upgrade clause. In that case you can be absolutely sure that nobody can sneak in new terms that you don't agree with. On the other hand, if you do actually want to change the license (e.g., upgrade to a new version of the GPL), you'll have to ask all the contributors to agree to the license change explicitly.
If you are distributing someone else's software (even as part of your own work), you are restricted by the terms of the license they've given you. If that's GPLv2-only, you can't distribute a work incorporating their work as GPLv2-or-later.
This file may be distributed and/or modified under the terms of the GNU General Public License version 2 as published by the Free Software Foundation and appearing in the file gpl-2.0.txt included in the packaging of this file.
Actually, the clause is recommended by the FSF. Projects that remove the clause do that fully intentionally.
Considering how long copyright lasts (70 after the death of the author), it is IMHO pretty short sighted to make the licence of a project stuck in time and unable to react to any future legal challenges.
It just means that the owners of the project copyright are the ones who decide how the licensing of the project will change over time. This is not short sighted. It is the best way to ensure that they can keep their code free. If you adopt the "or later" option, you are letting your code be forked under the terms of whatever license the FSF decides to attach the name "GPL" to. The FSF has already shown that they are willing to back away from free software by adopting the non-free AGPL (it does not satisfy freedom 0). Why believe that they won't compromise future versions of regular GPL, too?
By omitting the "or later" option, the project owners can take a look at each future version of GPL, and decide if it is still free and meeting their concerns and requirements, and then update their license if appropriate.
The project still has control of the license it offers the project under; of course, if it depends on software from anyone else that is on limited-to-GPLv2 terms (which lots of projects are), it can't change to any other license (whether GPLv3 or non-GPL) without either replacing the outside software or getting the copyright owner to agree to different licensing terms.
The project at issue here appears to use GPLv2-only because they are dependent on other software that is GPLv2-only.
When they talk about making a package GPLv2+, instead of GPLv2, I believe that's the distinction they're talking about.
I was referring to what the article was "talking about", with /their/ GPLv2+ terminology.
If you license it as GPLv2, it's GPLv2 only.
I cannot stand the GPL, it's an absolute unworkable nightmare. It's set out to achieve something fantastic and it's been ruined, it's so heavy handed that in the real world it's now meaning developers will avoid it rather than deal with it as there's so many gotchas like this.
Doesn't the what?
If you get it from someone else, and that someone got their copy under the terms of GPLv2, they still can distribute it under v2.
If the copyright holder is no longer issuing licenses, it is not at all clear what would happen. The analysis gets complicated and speculative at this point. There are quite a few plausible theories, but it is going to take a few actual cases followed by appeals for any clarity to start developing in this area.
But if you go to the original sourceforge svn repo, it started out GPL v2. I think you could fork a version from prior to revision 21 from sourceforge and it would be GPLv2+.
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
I personally prefer the UNLICENSE: http://unlicense.org/
If you consider non-free software immoral and your ultimate goal is to outlaw it, providing libraries which can be used by proprietary software makes you guilty of aiding and abetting.
Well sure; the FSF is essentially a political organization. I'm not sure what point you're making here. The renaming was a statement that the organization believes the license is not always what is most appropriate for libraries. This is entirely relevant to the original point, which was a refutation of the notion that the FSF is dumb for not using the clearly-appropriate-because-they-named-it-that "Library GPL".
> If the author wants their library to actually be used, it should be LGPL.
If the author wants their code to be used as broadly as possible, it should be public domain. If the author, maybe, has some concerns other than just how broadly the code is used, then some more restrictive license may be appropriate - BSD, LGPL, or GPL, depending on your particular goals.
> GPL-ing a library almost always makes it pointless.
If your only goal is broad adoption, then this is certainly the case. Somehow, I think the FSF has goals other than broad adoption of their software.
Even so, it is certainly the case that releasing your library under the GPL will mean that many projects will avoid it. Whether this trade-off is worthwhile depends not only on the weight you place on various goals, but also on the nature of the library: something that adds huge amounts of value relative to alternatives, and relative to proprietary libraries that might serve as other parts of a final application, will be a lot more likely to change the license of prospective projects than something that is easily replaced or displaces other things of more value. This is actually more-or-less the FSF's position, per my understanding, on libraries: "we encourage GPL but do what makes sense." This was their reasoning on readline, and that definitely drove some GPLing of software before workalike alternatives surfaced. This was presumably their reasoning here. This is not to say that the reasoning is necessarily correct.
That's pretty much the entire value proposition of the GPL, and it was pretty important in the early days of F/OSS when the value propositions of F/OSS was less clear -- "you have to open your stuff if you want to use my stuff".
But very early on in F/OSS, the argument was made that F/OSS was actually good for the people releasing their software as F/OSS -- not just good for the downstream recipients. And to the extent that that value proposition has been accepted, GPL-style licensing is less beneficial. If you believe that F/OSS is good for the licensor as well as the licensee, there is no reason, as a licensor, to use the license on your software as a bribe to get other people to open their software.
While initially -- before lots of big players clearly saw the value of F/OSS and adopted it for things they released even outside of GPL-style license-based compulsion -- the GPL was useful both for those who believed in the value proposition of F/OSS and those who were ideologically attached to F/OSS independent of the value proposition, its now useful mostly to the latter group and a negative to the former.
That tactic is dead.
I think they an important word.
For example, the FSF has long warned of the dangers of DRM, and in recent years these warnings have proved themselves prescient now that we have things like Amazon remotely wiping Kindles on a whim and deleting objectionable books. More recently, the FSF has begun making a lot of noise about the dangers of SecureBoot. Will the wider developer community disregard these warnings as the ravings of irrelevant zealots? Based on past observations, I certainly hope not.