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?"

6 of 330 comments (clear)

  1. That may be good. by www.sorehands.com · · Score: 3, Interesting

    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.

    1. Re:That may be good. by arivanov · · Score: 4, Interesting

      Actually, if you like qmail you need to have your brain checked.

      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).

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    2. Re:That may be good. by arivanov · · Score: 4, Interesting

      No point. The MTAs have moved forward as well. The libraries have moved forward as well. It would have been interesting 10 years ago (I used it and advocated its use at that time).

      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.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    3. Re:That may be good. by Just+Some+Guy · · Score: 3, Interesting

      my qmail gateways have never been exploited through qmail.

      That's because qmail's known exploits mainly affect new hardware. Cool, huh? Buy a new server and watch it automatically get less secure.

      --
      Dewey, what part of this looks like authorities should be involved?
  2. DJBDNS by caudron · · Score: 3, Interesting

    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
  3. Not quite so fast by einhverfr · · Score: 3, Interesting

    I'm interested in a free exchange of code that lets me do whatever I want with it. Public domain does not do that for me. What can't you do with public domain code?

    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