Slashdot Mirror
DJB Releases All Source to Public Domain
A Sage Developer writes "During a recent conference, Sage Days 6, Dan Bernstein (who has recently come under attack for his licensing policy) was among the invited speakers. During a panel discussion on the future of open source mathematics software, Bernstein declared that all of his past and future code would be released to the public domain. This includes qmail, primegen, and a number of other projects. Given the headache that incompatibility between GPLv3 and GPLv2 is causing developers, will we see more of this?"
No.
Not in a manner disproportionate to what we've seen in the past anyway. Some people will keep gpl2 as their license, others will go gpl3, bsd, or one of any of the OSI licenses for the most part, because people like attribution, they like retaining (some) control of their work.
This comment is fully compliant with RFC 527.
The reason I ask is that I read some releasing a new version of netqmail with smtp auth patches in it, and this is really waiting on DJB to do something about this issue. My servers are currently taking a big hit from spam and a clean way to block it in smtpd would make life a lot easier for me.
http://michaelsmith.id.au
Just wanted to get that in there.
I like qmail. This is both good and bad.
The good is that allows people to fix, and distribute the fixes as part of the package instead of as a bunch of patches.
The bad is the security of the result. One of the hallmarks of the DJB software is that it is secure and he backs it up with a $500 (it may be $1000 now) bounty for security holes in the software. Many people referred to him as arrogant because of his refusal, but when you are good, you sometimes develop an attitude that people mistake for arrogance. Even so, it is HIS code, so he gets to do what he wants with it.
Fight Spammers!
Sigh. No, it doesn't. The GPL sets forth rules you need to follow if you choose to share (i.e. distribute) the software. But nothing in the GPL obliges you to share anything.
I really like DJB approach in many programs but his daemon as services makes his good programs difficult to use. /etc/init.d , that will be cool.
I would like to use dnscache as a normal daemon, one below the
The crypto software and FFT software especially so, but maintenance isn't always as hot. That's hardly DJB's fault - they are public domain and nobody has run with them. On the other hand, it is not acceptable that his software is not being properly distributed, promoted or documented. Nor is it acceptable that he allows his personality quirks to interfere with the primary purpose of getting code into active circulation.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
How is it confusing?
The restrictions are essentially closing loopholes whereby people could either avoid sharing or share something useless.
Under GPLv2, you could create a derivative work and run a website based on it, but not share the changes since you weren't technically distributing the software. Or you could create a signed binary, and hardware that won't run it unless that binary is exactly the same. Or you could patent some procedure used, so that people can see the source code, but if they do anything with it, they violate your patent.
All GPLv3 does is enforce the spirit of GPLv2. Specifically: Everyone has to be able to get the source code, make any change they want, recompile, and run the modified binary.
If you're getting hit with these restrictions, chances are, you, yourself, are an "indian giver" -- you want to pretend to share, except, not really.
Or GPLv2... or BSD... or Apache... or MIT...
You're suggesting that GPLv3 somehow "infected" GPLv2, or every other license out there. That's simply not true. While public domain is perhaps the only way to ensure your code can be included in any kind of project, I see nothing wrong with share alike, and I see no reason why closing the loopholes is "going too far".
Don't thank God, thank a doctor!
While public domain is perhaps the only way to ensure your code can be included in any kind of project...
As I understand it, the only project in which Modified-BSD code could not be included is a project where the author wanted to claim you recommend their project without your permission. So while it's technically true, I don't think it's fair to say that public domain is the only way to allow code to be used in any project, not realistically speaking anyway. Anyone who insists on falsely claiming I endorse or recommend their product because I wrote some code they yoinked is a charlatan and I don't think their project is legitimate.
Random and weird software I've written.
There are two vastly different interpretations of the GPLv2's intent.
Linus' interpretation is, so long as we get to see the code, it's fine, even if we can't do anything with it.
That is not the original intent. Say what you will about RMS, but he wrote the damned thing.
Do you know why RMS started this "free software crusade", founded GNU, and wrote any GPL at all? It starts with a printer. He'd messed with the old printer driver for the old printer -- it was prone to paper jams, so his hack was to at least detect a jam and alert the user, even if he couldn't fix it. Well, the new model of printer came in, and he was all set to port his fix, but he didn't have source code.
That's why GPLv2 is all about source code -- RMS wants to be able to tinker with any device he owns, and he saw lack of source code as the only thing stopping him. In the case of this printer driver, it was. But now we have tivoization. Tell me, if the lab computer was set to only accept signed binaries, what good would any amount of source code be? He could change it to do his paper-jam-fixing-hack, and even compile it -- he could do anything but run it -- which makes it completely useless.
Linus has a point, and so do you -- there is some academic value in seeing how people did what they did.
But Linus and you miss the crucial point -- it's not about restricting the developers, it's about empowering the users. The GPLv3 guarantees that any piece of software you get that's GPLv3-licensed, you can modify it, recompile it, and run it in the same way as the original. What's restrictive about that?
Don't thank God, thank a doctor!
"Under GPLv2, you could create a derivative work and run a website based on it, but not share the changes since you weren't technically distributing the software. Or you could create a signed binary, and hardware that won't run it unless that binary is exactly the same. Or you could patent some procedure used, so that people can see the source code, but if they do anything with it, they violate your patent."
You still can run a web site on modified GPL3 software and not share the modifications you made. It's the AGPL3 (http://www.fsf.org/agplv3-pr) that prohibits this. GPL3 only prohibits you from bundling software and hardware in such a way you cannot change the software part, unlike the GPL2 that doesn't disallow that.
Please, read the licenses. We need more information, not disinformation. BTW, the article quoted by the GP is ancient, from before the release of GPL3.
http://www.dieblinkenlights.com
Good. DBJDNS is, overall, a solid piece of software that kicks the crap outta Bind and leaves it bleeding in a ditch. I'll be glad to see it under a more open license that allows it to prosper and get some of its problems addressed.
Tom Caudron
http://tom.digitalelite.com/
-Tom
Its method of storing its database as raw inodes is... mildly frightening, to say the least.
Huh? Why? I mean, I'm no qmail zealot, but if you're afraid of storing data in your filesystem, you have far *far* bigger problems.
It makes restoring from backup difficult, for one thing, unless you use an exact image of the disk with a partition the exact same size. I don't, I use file-level backups. Or maybe I want to move qmail to a different disk or volume. I mean, on one hand, it's freaking email queue, who gives a damn. But it's the principle of the thing.
Random and weird software I've written.
Quite correct. Fortunately, it's almost trivially easy to beat the AGPL.
Dewey, what part of this looks like authorities should be involved?
For example, str_chr(). The standard strchr returns EITHER a pointer to the found character, or NULL. djb's str_chr always returns a usable pointer; either to the character or to the null terminating the string. Compare this idiom:
strcpy(secondhalf, strchr(wholething, ';'));
to djb's
str_cpy(secondhalf, str_chr(wholething, ';'));
This code works even if ';' isn't found, whereas the first code segfaults. In order to avoid segfaulting, you need this:
char *cp
cp = strchr(wholething, ';');
if (!cp) strcpy(secondhalf, cp);
But what's better about the djb C library is his hashing array lookup, and counted string code, which automagically lengthens strings using realloc() as needed.
Don't piss off The Angry Economist
My concern about the GPL is that, while it is very friendly towards businesses who want to release and then control the direction of their open source products (I did not say projects), it can have a stifling effect on community. Compare for example, the MySQL development model (one company *controls* what goes into the next release) with the PostgreSQL development model. In many ways Linux is an exception rather than a rule, and even GNU suffers from politics of internal control (for example RMS dismissing the head HURD architect, Thomas BUshnell, for arguing against considering the GFDL to be "Free" according to Debian's guidelines-- if this is the free speech to be associated with the FSF's free software, I want no part of the FSF).
The GPL is in many ways a sort of halfway house for companies who want to do open source but not community-centered development. If MySQL was under the BSD license, there is no way they could maintain the central control-- they would have to open up the commit access to many people in other companies, and could not sell proprietary licenses because there would be no market for them.
The GPL, while having legitimate uses, is more of a political statement than anything else. I say this as someone who contributes thousands of lines of code per week into GPL'd projects.
THe GPL v3 is confusing in number of ways. For example, there is some concern over whether a company cedes patent rights over their own patents by merely using GPLv3 software, this is because of missing one little definition buried not in the definitions section but elsewhere in the license (section 11. paragraph 6, as much as a quick reading might otherwise support the concern, only applies to distribution relying on *explicit* patent licenses hence one cannot inadvertently license patents by mere distribution of the software).
A larger issue with the GPL v3 is that section 7 can be read to be incompatible with licenses such as the BSD and MIT licenses, perhaps even with the public domain. The question is, whether paragraph 2 (removal of additional permissions) must apply to portions under other licenses as well. A plain reading of the license suggests that this is the case (and my conversations with Eben Moglen suggest he thinks that this is the case, and furthermore that he believes that licenses such as the BSD and MIT licenses allow for additional restrictions to be added to the license when merely copying the software. It is clear from public speeches that this is also the view of RMS).
However, as another member of the SFLC pointed out to me, this was not the intent of a large number of authors of the license, and that few if any lawyers are willing to give advice that changing the license on a verbatim copy of a permissively licensed work is allowed (see the SFLC's memo on ISCL/GPL collaboration). They argue that since compatibility with licenses like the BSD license was a goal, that it needs to be read as compatible. Hence they argue that the additional things you can do with BSD-licensed code fall outside of the definition in section 7 of additional terms and are not governed by the GPL v3 at all.
However, if and until we see a memo from the SFLC on that topic, we will not have a neutral document to point to and say "this is what the license means." Hence it seems to me that every project ought to contemplate these issues, seek legal advice, and include some clarifying statements in the project's documentation.
This is too much trouble for me to go to in my projects so there is no incentive to move. I *am* considering moving a fair bit of my company's projects from the GPL to some variant of the MIT or ISC license however.
LedgerSMB: Open source Accounting/ERP
Most of these points have come out of arguments with both developers and lawyers as to the restrictions in the GPL:
1: If you download a copy of the GCC under the GPL v3, are you licensing your patents which the GCC infringes on to all third parties?
After a lot of discussion on and off various lists, the answer is no, but you have to stop using the GCC prior to suing anyone or else other people could conceivably sue you. However, this is confusing because it is easy to miss the definition of patent license in section 11 (which excludes any implicit licenses).
2: Can one incorporate whole files from the public domain or permissive licenses into at GPL v3 work? While everyone seems to answer "yes" the different reasonings behind the answers leave a lot of confusion.
According to Mr Moglen, for example, *all* code in a GPL v3 project is governed by the restrictions of the GPL v3, and one can only use, say, ISC-licensed files because one can convert the license to the GPL v3 plus the attribution notice. Mr Moglen in my conversations with him seems to feel that section 7, paragraph 2 (removal of additional permissions) *does* apply to any files included in verbatim under more permissive licenses (and the only limitation is what the courts will allow one to enforce). In public speeches, RMS seems to take a similar view (arguing that a right to relicense the work is a prerequisite for license compatibility).
However, I would note that the Software Freedom Law Center does *not* recommend changing the licenses on permissively licensed files included verbatim, seemingly contradicting Mr Moglen's viewpoint. Other lawyers in the SFLC have suggested that one is *not* allowed to change licenses on such files unless they are modified. They get around this argument by stating that additional things you can do with code under such licenses in other projects are outside the scope of section 7, paragraph 1 definitions of additional terms and therefore are *not* governed by the GPL. Hence another license only conflicts with the GPL if it imposes additional restrictions which the GPL does not allow, or prevents modifications to those files from being licensed under the GPL.
So, if the BSD, ISC, and MIT licenses are to be interpreted as *not* allowing license changes on verbatim or non-literal (i.e. those with minor edits) copies, then would people like Mr Moglen and RMS state that this means they are incompatible? This is something where ideally we should have public commentary about this specific issue from both the FSF and the SFLC. Otherwise, projects, IMO (IANAL) should probably get proper legal help and add licensing FAQ's to help clarify these issues.
LedgerSMB: Open source Accounting/ERP