Richard Fontana wrote: > On Wed, Aug 14, 2019 at 10:25 AM Howard Chu <[email protected]> wrote: >> >> Richard Fontana wrote: >>> On Wed, Aug 14, 2019 at 9:27 AM Howard Chu <[email protected]> wrote: >>>> >>>> Clause #10 of the definition https://opensource.org/docs/osd >>>> >>>> 10. License Must Be Technology-Neutral >>>> >>>> No provision of the license may be predicated on any individual technology >>>> or style of interface. >>>> >>>> I note that the Affero GPL https://www.gnu.org/licenses/agpl-3.0.en.html >>>> clause #13 >>>> >>>> 13. Remote Network Interaction; Use with the GNU General Public License. >>>> >>>> Notwithstanding any other provision of this License, if you modify the >>>> Program, your modified version must prominently offer all users >>>> interacting with it >>>> remotely through a computer network (if your version supports such >>>> interaction) an opportunity to receive the Corresponding Source of your >>>> version by providing >>>> access to the Corresponding Source from a network server at no charge, >>>> through some standard or customary means of facilitating copying of >>>> software. >>>> >>>> violates the OSD clause #10. This issue arose specifically in the case of >>>> OpenLDAP when >>>> Oracle relicensed BerkeleyDB 6.x using AGPL. There is no available >>>> mechanism in the LDAP >>>> Protocol to allow us to comply with clause #13 of the AGPL. I believe the >>>> same is true of >>>> many common internet protocols such as SMTP, FTP, POP, IMAP, etc., which >>>> thus now precludes >>>> servers for these protocols from using BerkeleyDB. It appears to me that >>>> AGPL is plainly >>>> incompatible with the OSD and should not be an OSI approved license. >>>> >>>> This is no longer a pressing issue for us since we have subsequently >>>> abandoned BerkeleyDB >>>> in favor of LMDB. But I thought I should point it out since it may affect >>>> other projects. >>> >>> Can you explain further why you believe this to be so, especially for >>> those who may lack the relevant technical knowledge, or familiarity >>> with OpenLDAP, to assess what you're arguing? >> >> It appears to me that this clause was designed for web-based applications, >> or maybe mobile >> apps, where an obvious splash page/startup screen is presented at the >> beginning of any >> interaction. This AGPL license clause would require you to notify users of >> the offer to >> receive the source code at this first point of interaction. >> >> In LDAP, there is no definite "first" interaction - while there is an LDAP >> request to >> authenticate a user, and this is typically the first request a client >> issues, it is not >> required. I.e., authentication is an optional step. Leaving that aside, >> assuming that we >> could identify a first point of interaction, there is no part of the >> protocol that allows >> us to send arbitrary unsolicited text to an LDAP client, so there is no way >> to embody a >> message that offers the user a copy of the source code. > > I think what you're saying is that, assuming your interpretation of > AGPL (including but not limited to section 13) is correct, a would-be > LDAP implementation with an AGPL-licensed dependency would be forced > to choose between compliance with the standard and compliance with > AGPL?
That sounds like a fair summary, yes. Also, simply adding a non-standard extension to our server to meet this license requirement doesn't solve anything, if all LDAP clients aren't also modified to recognize the extension, and that in particular seems an unrealistic task. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
