DJB Releases All Source to Public Domain 330
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?"
That may be good. (Score:4, Interesting)
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.
Re:That may be good. (Score:4, Interesting)
The biggest advantage of Unix is the "We stood on the shoulders of Giants" philosophy. The library functions are continually improved and nowdays there is a library function for nearly everything. Qmail goes completely against this philosophy by rewriting nearly every higher level function in libc it needs. Granted, when qmail came out some of these rewrites were more secure and technically superior implementations. First of all, not contributing them towards the libc's is sociopathic behaviour (I want only my app to benefit, everyone else go suck bricks sidewise through a thin straw). Second, their technical superiority even from a security perspective is no longer there. Libc has moved on and even the worst of them (HPUX and Irix) are now at the same level of the DJB replacements (or better).
Re:That may be good. (Score:5, Interesting)
Now it is pointless.
Postfix, Exim and even sendmail have made a giant leap forward in terms of code quality, performance and security. So have the underlying libraries.
There simply no point to use qmail or any of its code base now. Too little, too late.
Re:Don't be an "indian giver" (Score:3, Interesting)
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 [fsf.org]) 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.
Re:Don't be an "indian giver" (Score:2, Interesting)
I disagree that its the spirit so much as an interpretation of the spirit. Sure, it's the interpretation of the original author, but that might not be the spirit developers picked up on when they read the GPL so theres certainly room to complain. Specifically, the code signing/hardware clause I take issue with as I see hardware and software as two separate things, with the software's license having no place mucking with hardware.
Theres legit reasons to not want arbitrary code running on a device. Look at how much crap Rockstar got in over people going out of their way to modify their software(GTA3) to get to a sex scene that is otherwise not at all accessible.
Now imagine what happens when, say, TiVo(let's face it, the reason people care about this clause) has a fork that allows any user to easily share their shows and create private mesh nets of tv shows, including a few PC clients as archive dumps so that people can have access to all tv shows they want.
Yeah, that would be awesome, and the end user would be better off for it, but you can't tell me TiVo wouldn't be in for a world of even more ill will from Big Media(tm), if not outright lawsuits as they're profitting directly from these forks.
If they wern't responsible at all, then they'd just do whatever crazy borderline illegal feature(DeCSS?) they want and release it as anonymous patches that are good for nothing other than making more people buy their device.
I'm not sure how I stand on the service provision. I think it really depends on what the original code was. Yeah, if you fork Movable Type and don't release your spiffy mods to it but instead create SpiffyBlogs.Net I'd agree that's bad, especially so if you use the fact that you're an improved version of movable type to sell your service.
But what about more distant forks? Lets say you had a web based virus scanner where people could upload a file and it would run a bunch of your custom checks and also a GPL virus scanner's scan on it and give you the results. Should all of that code be forced to be released?
What if its not a file upload site but instead web based email? What if say gmail decided to offer virus scanning as a service and used a GPL virus scanner to do so? What if its done in the MTA? It's still part of the service, arguably the linking clause would apply (in addition to bringing their MTA's source out publically as well..)
I like the GPL, but its just too messy and situational. I think Public Domain's best feature is that it has none of this gray area and just is what it is, making things like SQLite so easy to embed.
Re:That may be good. (Score:3, Interesting)
DJBDNS (Score:4, Interesting)
Tom Caudron
http://tom.digitalelite.com/ [digitalelite.com]
Re:In a word... (Score:3, Interesting)
This is correct
It's a quite contrived example though. Since it's GPL software, any employee who gets their hands on it can then redistribute it for free. Assuming the program is useful, it'll spread around soon enough. For this scheme to work indefinitely it'd need to be a quite obscure piece of software, and there should be a reason to get the software from the company and not from me.
I don't think this is a very likely situation, since any company attempting to do this can't distribute it very widely, so any potential gains from it won't be large.
Re:That may be good. (Score:4, Interesting)
That's because qmail's known exploits [guninski.com] mainly affect new hardware. Cool, huh? Buy a new server and watch it automatically get less secure.
Re:I don't get it. (Score:3, Interesting)
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.
Not quite so fast (Score:4, Interesting)
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.
The GPL v3 *is* confusing (Score:3, Interesting)
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.