Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Red Hat Software Businesses Software America Online Netscape The Internet Linux

Red Hat releases Netscape Directory Server to OSS 130

parry writes "Red Hat has released the Netscape Directory server acquired from Netscape Security Solutions under a "GPL + Exception" license. The Fedora Directory Server is made up of a number of different pieces of software, each with their own licensing. "
This discussion has been archived. No new comments can be posted.

Red Hat releases Netscape Directory Server to OSS

Comments Filter:
  • by Anonymous Coward
    Red Hat Opens Netscape Directory [slashdot.org] - This is a bad omen for the start of the work week.
  • A little help (Score:1, Interesting)

    by manno ( 848709 )
    So what exactly does this do? And what closed source products does this replace?
  • The article last week was a press release type article. Lots of fluff, no content. Now we're getting the content. So it's not really a dupe. More of a late update.
  • by flacco ( 324089 ) on Monday June 06, 2005 @08:14AM (#12734595)
    anyone care to examine the license - "GPL with Exception" - and give us an Evil / Not Evil summary?
    • Worth pointing out, the exception is an extra freedom not a less-freedom (which of course would make it not GPL).

      I'm not too clear on GPL vs LGPL but the extra "you can link this from non GPL...." sounds like a cross between the two.
      • This licence [redhat.com], contrary to LGPL, explicitely lists the Approved Interfaces in a file named EXCEPTION.
        So if external code is linked to code not declared in this file, it is covered by the GPL.

        Where the LGPL-like freedom stops is here: "Only Red Hat, Inc. may make changes or additions to the list of Approved Interfaces." So if you (assuming you are not Red Hat) want to add interfaces to a fork, they will be covered by the pure GPL as the exception clause will not apply.
    • by LiquidCoooled ( 634315 ) on Monday June 06, 2005 @08:21AM (#12734637) Homepage Journal
      The Exception is explained here [redhat.com]

      It states:

      GPL Exception License Text
      From Fedora Directory Server

      This is the text of the Licensed used in the Core of the Directory Server code. For more of an explaination, please see the annotated license text for a more in-depth description.

      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; version 2 of the License.

      This Program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

      You should have received a copy of the GNU General Public License along with this Program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

      LC:here it comes

      In addition, as a special exception, Red Hat, Inc. gives You the additional right to link the code of this Program with code not covered under the GNU General Public License ("Non-GPL Code") and to distribute linked combinations including the two, subject to the limitations in this paragraph. Non-GPL Code permitted under this exception must only link to the code of this Program through those well defined interfaces identified in the file named EXCEPTION found in the source code files (the "Approved Interfaces"). The files of Non-GPL Code may instantiate templates or use macros or inline functions from the Approved Interfaces without causing the resulting work to be covered by the GNU General Public License. Only Red Hat, Inc. may make changes or additions to the list of Approved Interfaces. You must obey the GNU General Public License in all respects for all of the Program code and other code used in conjunction with the Program except the Non-GPL Code covered by this exception. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to provide this exception without modification, you must delete this exception statement from your version and license this file solely under the GPL without exception.

      I will let others decide on its evilness factor.
      • I will let others decide on its evilness factor.

        Basicly, it is like a dual license, GPL and "LGPLish". Anyone making modifications may do so under the GPL, or they may preserve the dual licensing. Same goes with every other piece of dual licensed software out there. You can make your own GPL-only fork of say Qt or MySQL - but don't expect Trolltech or MySQL AB to merge your changes.

        Kjella
      • Stricter than LGPL (Score:1, Informative)

        by Anonymous Coward
        Seems that it's stricter than the LGPL. The LGPL (as far as I remember) doesn't specify anything about approved interfaces, although it does require that it is possible to replace the library (dynamic linking or re-linking), but even this doesn't say anything about e.g. not touching deeply internal structures inside the library. As long as these internal structures are still accessable, it will still be possible to replace the library. This license does not allow that.
      • If you look at their wiki, they have not released all the componets as Open Source yet. So, they had to have an exception or they themeselves would be linking non-free with free and in violation. With the exception, they can release at least part as GPL and get it out to the world. I'm betting the non-free parts are likely iPlanet componets that are still encumbered.

        Because this introduces complexity (and possibly confusion), it sort of brings to question if the hollowed and sacred GPL was the most appro
        • If you look at their wiki, they have not released all the componets as Open Source yet. So, they had to have an exception or they themeselves would be linking non-free with free and in violation.

          No, because as the owners of the copyright, they don't need a license to distribute the software.

          The reason is the basis of the GPL's legal force: copyright. By law, only the copyright holder has the right to make copies or create derived works, or give permission to others to make copies or create derived

          • Ofcourse, if Redhat owns the copyright, they can do as they please and distribute it. But now you download it and you want to redistribute it. If the necessary build would violate the GPL (as this may because the necessary non-free componets link to to GPL covered componets), then *you* would be in violation if you re-distriubted it. So, now you can see the conundrum. To over-come it, they come up with this expection to the GPL. It is their right to do so, but perhaps not an optimal solution.
            • Agreed, assuming that you actually need one or more of the non-free components to build and distribute something useful. Also, even if you do need the non-free components, Red Hat would still not be violating the GPL, they would just be releasing software under the GPL that is not useful as-is. There's nothing wrong with that, actually, as the GPL contains no requirement that the software actually work.
        • I think the GPL probably works best for a company like Red Hat. Other companies can out spend them on development staff so they need to make sure they get back any enhancements made by oracle, sun, hp or what have you. Otherwise the project would fork and their version would be left behind.
        • If you look at their wiki, they have not released all the componets as Open Source yet. So, they had to have an exception or they themeselves would be linking non-free with free and in violation.

          The owner of the code is not bound to the license terms others have to agree to to use the code! If I write something and GPL it, I, as owner, can sell a proprietary app using said GPLed code w/o violating the GPL license you have to obey.
          • Yes, for Redhat themselves, they can do as they want as owners. But the whole point of OSS is to make it re-distributable. As I said in another post, now you download it and you want to redistribute it. If the necessary build would violate the GPL (as this would because critical non-free componets link to to GPL covered componets), then *you* would be in violation if you re-distriubted it. That is the problem. They want to have binary-only distribution of some componets that are linked to GPL components. S
      • Given the purpose of a directory service it seems a reasonable exception - you may not take the code and use it in a non-gpl package, but you *can* use the published api (this is at a similar level to being able to use SQL to access a MySQL or PostgreSQL database, but not actually use any of the code in your own non-gplled programs)
        • This is an improvement for directory services. Now theres at least one corporate grade open interface... there will be a defacto standard as apps for Fedora Directory will see other back ends adopt the standard in order to become compatible in a similar fashion to SQL as pointed out above.
      • its tighter than the lgpl in that it doesn't let people add new approved interfaces to the code for the propietry software to call.

        though i can't see any rules stopping you from modifyiing the stuff behind the appoved interfaces and therefore basterdising them in some way (for example making a previously undifined result into some feature you wan't)

        imho this is less evil than what mysql and trolltech do (which is understandable, they wan't to make money but shows that free software isn't really thier goal
    • Evil/Not Evil (Score:3, Informative)

      by zerbot ( 882848 )
      Depends on your point of view. I've quoted the "exception" below. It allows developers to distribute versions that are linked to non-GPL code as long as those links use approved interfaces. Developers who modify the GPL code are not required to continue the exception in the code they release. I'd put it in the decidedly non-evil camp, but GPL hardliners may view it as evil.

      In addition, as a special exception, Red Hat, Inc. gives You the additional right to link the code of this Program with code not c
    • IANAL, and also not any sort of licensing expert, but the really iffy bit looks like

      Only Red Hat, Inc. may make changes or additions to the list of Approved Interfaces.

      This means that only Red Hat, Inc. gets to make changes to the list of Approved Interfaces. Since the file that contains the list of Approved Interfaces is also distributed under the GNU GPL, it's perfectly fine to make changes to that file. We just wanted to make sure that if you do make changes to that file that the additional rights gr

    • License (Score:3, Insightful)

      by tpv ( 155309 )
      It's basically a half way point between the GPL and the LGPL.

      For most Open Source developers the easiest thing to do is to just use the software under the GPL.

      However, if you use the software as a library, and only make use of the specific APIs that Red Hat has listed, then it effectively becomes like the LGPL. You are not obliged to release your code under the GPL.

      But unlike the LGPL, the set of allowed APIs is fixed, and defined by Red Hat. In a LGPL program you can open up new APIs and change exi

    • by tpv ( 155309 )
      Grrr, my previous reply was an accidental submit.. Why isn't the default action on the form to preview instead?

      It's basically a half way point between the GPL and the LGPL.

      For most Open Source developers the easiest thing to do is to just use the software under the GPL.

      However, if you use the software as a library, and only make use of the specific APIs that Red Hat has listed, then it effectively becomes like the LGPL. You are not obliged to release your code under the GPL.

      But unlike the LGPL, t

      • It's actually very clever wording by RedHat.

        What they've done is to formalize a mechanism for exclusions similar to the one that we're used to in the Linux kernel, which also provides licensing exclusions to allow closed binary applications to run under it and closed binary drivers to run within it, despite the kernel itself being GPL'd.

        Linux overcomes this issue because the GPL's explanatory notes describe a general exemption for closed applications that link to standard operating system programs and int
    • IANALB, but...

      Well, the exception relaxes the GPL restriction on linking non-GPL code, provided that the non-GPL code access the GPL code exclusively through a set of defined and free APIs.

      This "feels" a bit LGPL-ish. I'm guessing that RH has some particular scenario in mind that would be allowed under this exception that might not be under LGPL. Perhaps this is to enable proprietary extensions to be made (e.g. to interoperate with non-free directory servers) to be made and distributed, via something l
      • I'm betting there is some specific closed source Enterprise software that interoperates with the Netscape Directory. Red Hat probably intend for the Netscpae directory to continue to be delivered with this software but did not want the permissiveness of the LGPL so everyone and thier dog could leech off thier work.
    • We chose to use a GPL+Exception license for a few very specific reason:

      1. We wanted something that was GPL-compatible.

      2. We wanted people to be able to ship it with non-free software.

      Directory Server has been shipped for a long time as the backend for lots of other apps, like all the old Netscape Suite apps like mail server. We thought this was a valuable form of delivery and wanted people to be able to continue to do this.

      3. We wanted people to be able to build plugins for the Directory Server under n
  • What we need is: (Score:5, Insightful)

    by nighty5 ( 615965 ) on Monday June 06, 2005 @08:21AM (#12734640)
    An easy to use Directory Service that:
    * childsplay to install
    * hides the LDAP schema from admins that don't need to know
    * a GUI / web console to add, delete, alter LDAP attributes
    * easy integration into the O/S with a few file changes: PAM modules
    * is easier to get going than OpenLDAP

    I hope that the new Fedora project will do something like this, I saw the admin toolkit but no source is available yet, only binary packages - since I run gentoo i'll wait... Might be interesting!
    • I hope the quality is good: I've used it in
      the past and it needed some work.

      --dave
    • Netscape Directory used to have a GUI (Java Swing based, and so it used to suck but..) for performing routine management tasks (searching, setting up replication, adding/deleting/modifying the attributes etc.). So you can hope that the Fedora DS which is based on Netscape will have atleast some GUI tools to make an admin's life easier. Some one should probably write a Softerra LDAP Administrator alike tool integrated with the Fedora Directory server and it will be an ideal OSS directory server to use. And l
    • Granted, this doesn't fit everything, but when it comes to Solaris environments, I've found that Sun Java System Directory Server fits the bill quite nicely. Don't get me wrong. I have not tried this outside of a Solaris environment, so I don't know how easy it is to implement into other operating systems like Slashdot's oh-so-precious Linux, but JSDS is available for Linux as well.

      Your first requirement was not always the case. JSDS was a BITCH to install when I first started to work with it. It took
    • Well, for one of your points, namely PAM modules, libnss-ldap works fine for me, and it's hardly rocket science to set up. 30 minutes, tops, including importing all the existing data.

      Only thing that would be nice is if Debian was happy to have automated user operations performed on the directory instead of just passwd...but I'm sure a few scripts could sort that out if I could be bothered.

      Only things that bother me about OpenLDAP:
      * ACLs in a config file rather than the directory itself...yes its more sec
      • In OpenLDAP 2.3 (which has been in beta for a few months and is due for a public release in a few days) the full configuration is editable via LDAP, so you no longer need to restart the server to tweak ACLs, add schema, or reconfigure indexing. In fact you can generate a complete server configuration via LDAP - you can add new backends and start them up and shut them down on the fly.

        re: decent GUI tools - yes, this is a problem, but you have to frame it correctly - it is a problem with LDAP software in gen
    • Novell's eDirectory [novell.com] satsifies all of those requirements. It installs as an rpm (everyone else will have to alien it to a deb or whatever you like). The ldap schema is completely hidden unless you want to extend it in which case you can use either a web frontent (iManager) or a java app (ConsoleOne). The same two tools will let you manage everything you would ever need to touch on it as well as manage just about every other Novell application. Both tools work fine under the browser/os of your choice as w
    • We've got a set of admin tools there (as mentioned elsewhere in this thread.) We intend to open source them, we just haven't gotten that far yet.

      If you want to see them download the binaries from the web site. They are included with the rpm, just not with source yet.
    • Looks like you can pull it from anonymous CVS, though the build procedure looks to be quite complex, but I don't see why you can't do it on Gentoo. There may be valid reasons to choose another LDAP implentation, but this one should at least build on any Linux.

      http://directory.fedora.redhat.com/wiki/Building [redhat.com]
    • An admin who does not know the ldap schema he is working is downright dangerous. They should immediately be fired before they cause major harm to the company they are working for.
    • Even runs on linux... [novell.com]
    • I have used this DS for many years and am pleased that Red Hat bought the Netscape product and didnt let it die. Sun aquired the code through a partnership called iPlanet. AOL ended up with the code too out of iPlanet and just liked the name "Netscape" for commercials. So now you got Sun and Red Hat moving forward with it.

      Whats not to like? All operating systems have a decent DS now! You can stop announcing what you use, it just doesnt matter. If you run Suse edirectory, solaris Sun DS, windows AD, RHEL Re
  • Finally ! this is the only Open Source Directory that can compare to the features that Active Directory has to offer, especially multi-master replication.

    Unfortunately, this will probably mean OpenLDAP [openldap.org] will fade into insignificance, but I may be wrong !

    This is the 'stronger rope' I needed to hang the guys planning on making Linux authentication depend on MS AD where I work :)
    • Unfortunately, this will probably mean OpenLDAP will fade into insignificance, but I may be wrong !

      Why? KDE vs gnome? freebsd vs linux? It's not going to dissapear...
      • well, in all those cases the alternatives have equivalent features (generally speaking) on offer. Whereas in this case, Fedora Directory Server is vastly superior to OpenLDAP in terms of features and I assume scalability as well going by what i've read/heard.
      • Why? KDE vs gnome? freebsd vs linux? It's not going to dissapear...

        Yeah, the OSS community has a knack for keeping inferior products going.

        *Watches as all the fanboys come flaming, thinking I meant them*

        Seriously though, it depends on what you mean by better. Some products (apache,linux kernel) seem to be doing fine being just one, others are more of a preferance thing and usually have several. I think a high-end directory service is more of the type which only really needs one product though.

        Kjella
        • Perhaps you are forgetting the various BSD's? There are more webservers beyond Apache; try Xitami, Savant, or Boa.

          About the only F/OSS software that stands alone is Tex, and instead of competing projects it has other software tha builds atop it like LaTex and Lyx. Heck, even core GNU utils like 'ls' have replacements in busybox.
      • Unfortunately, this will probably mean OpenLDAP will fade into insignificance, but I may be wrong !

        Why? KDE vs gnome? freebsd vs linux? It's not going to dissapear...

        Nope, more like OpenGFS [sourceforge.net] vs GFS [redhat.com]. Check the opengfs webpage, they started work on improving global locking [sourceforge.net], etc etc, but once Redhat bought sistina [open-mag.com] and re-released GFS under GPL, opengfs had no reason to exist anymore. Shame for the devel effort going to waste...

        Same happened to QT vs Harmony if anyone remembers (Harmony died when QT wen

    • Unfortunately, this will probably mean OpenLDAP will fade into insignificance, but I may be wrong ! At first i thought indeed you may be wrong and actually OpenLDAP may have some benefit from this, but now, i think the most benefit will be for Netscape Directory, as this one is under GPL (most part at least) while the other seems to be under a BSD license. If im not wrong, BSD cant access GPL code, but GPL can use BSD code. Am i wrong?
    • Having the former Netscape directory product released as OSS is positive to the community. Unfortunately this doesn't imply a replacement for Active Directory. In fact there is very little available in the form of an Open-Source solution to compete with AD. I'm not sure that people fully understand the significance or importance of that.

      AD is actually a fusion of a number of technologies. Most notably Kerberos for authentication, LDAP for identification and dynamic DNS/DHCP. As is common with Microsof
      • AD is actually a fusion of a number of technologies. Most notably Kerberos for authentication, LDAP for identification and dynamic DNS/DHCP. As is common with Microsoft architectures all of these have been amalgamated into one large reasonably amorphous blob. So the presence of a directory server, even one as formidable as the Netscape product, does not imply an AD replacement.

        And...

        So a directory server does not imply an Active Directory replacement. That will require tight integration of a number of t
  • by LordMyren ( 15499 ) on Monday June 06, 2005 @08:42AM (#12734766) Homepage
    Not a dupe [slashdot.org], its actually released now.

    It'll be great to see the benchmarks to settle this;
    SunONE
    IBM's ldap thingy
    OpenLDAP
    Novell's eDirectory
    maybe even AD for kicks.

    Also, just a note, redhat's docs are actually pretty good. Even the web pages ~2500 word Architecture docs probably outweight the usefulness of everything else available on the web. One of the most frequenty Directory Service gripes is how bad the docs are; finding out how to build a good DS system is pretty much a black art. Part fo the reason OpenLDAP is so unacceptable as a solution is because you're at the mercy of whatever tools you can find; docs are MIA. RedHat's already done a decent job of making them accessible, which is good because I might need them to make this thing compile on Debian.

    Way to go red-hat. Everytime red hat shows up on campus I always spend five-ten minutes asking about the Netscape DS. Thanks for the release; here's to long life.

    Myren
  • by HighOrbit ( 631451 ) on Monday June 06, 2005 @08:51AM (#12734831)
    From TFA at http://directory.fedora.redhat.com/wiki/FAQ#Genera l [redhat.com] some componets are not yet open.
    In order to make the Directory Server software available as soon as possible, some components will not be released as open source in the first release. Initially just the LDAP server itself is being released. The administration server and end-user console are not being released as open source at this time. However, the binaries will be available for those other components, so the full console, management, and web based applications will be available, just not the source code

    Well... at least the core is Open. Maybe they have to write replacements for encumberered components (perhaps the Sun iPlanet parts??).
  • "To get in touch with us, you can try to reach us on IRC at #fedora-ds on irc.freenode.net or on one of our mailing lists.

    At least they're honest.
  • Is there a side by side comparison of Network Information Service (Sun Yellow Pages), Open LDAP and Netscape Directory anywhere?

    I'd love to know what exactly the differences are and I suspect that most people have no idea and simply use whatever it is that they are familiar with...
    • Here's most of what I decided I needed to know:
      • NIS has essentially no security.
      • I've never seen a non-Unix box support NIS.
      • NIS is easy to set up and works great for what it's intended for.
      • LDAP is extensible; adding new schemas is pretty trivial.

      If you need to authenticate Unix logins on a secure network, NIS is easy to use and works out-of-the-box. If you need to store any other data (Windows logins, mailserver logins, IM server logins, address books, etc.) then LDAP is the clear winner.

    • Is there a side by side comparison of Network Information Service (Sun Yellow Pages), Open LDAP and Netscape Directory anywhere?

      NIS != LDAP

      Just to clarify, NIS and LDAP really have no real point of comparission.

      I mean yeah, you can use them both as authentication/authorization backend for pam, but then again, so can postgres.

      NIS is a way to distribute some key file in an asyncronous way across a network. It works kinda nice when youve a full host of unixes and you need one authentication database for
  • it's been trivial to install, it's not eaten any of my data, and I must say I'm very happy with multimaster replication as provided.

    it also seems much faster than openldap.
  • by smartin ( 942 ) on Monday June 06, 2005 @10:34AM (#12735888)
    I have a small network of Linux and Mac machines and would really like to set up one address book that is accessible to all my machines and all my accounts under both Thunderbird and Mac Mail.

    Would this be useful for this application or is it overkill? What are the other alternatives, I played with openldap using something called abook once and it was unusable.
  • Ok, I read that *Red Hat* was going to release it. Then Red Hat spins off Fedora..

    Now this is showing up under the Fedora project pages?

    So, are they releasing it as an actual product that can/will be supported by Red Hat's support & support contracts, or are they just saying "Ok, Fedora project, you can have this. Have fun!" and letting it go at that?

    Personally, I think that it'd be a little underwhelming to just release it to the world and say "here.." This product is something that could be quite u
    • It's considered a Fedora project. Fedora is where we will take contributions and build a community around the code.

      Red Hat has a supported version of the the Directory Server called "Red Hat Directory Server." Separate information about that product can be found on Red Hat's web site.
    • So, are they releasing it as an actual product that can/will be supported by Red Hat's support & support contracts, or are they just saying "Ok, Fedora project, you can have this. Have fun!" and letting it go at that?

      Go read the docs, you'll find it is released as both Fedora-DS and RH-DS. I'll leave it to you to figure out which is a supported (as in pay and get a tech) and which is not.

      yeah, I know, the "if you had competant admins you wouldn't need support" line,

      Do you know the "yeah if you re

  • Maybe "Einstein joins Red Hat Fedora Foundation"?

    Or "George Washington funds development of Red Hat Directory Server"?

    How about "Jesus blesses newly released Red Hat Directory Server"?

    And some moron says, "Well, this story includes the LINK!"

    DUH!

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Working...