RE: OpenLDAP Licenseing issues
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Stephen Frost
> Of those 15 licenses there are a few questions when it comes to GPL
> interaction. In the UoC license (Regents of the University of
> California Berkley) there is the infamous 'advertising clause'. The
> Regents have however, from my understanding, retroactively
> removed that
> clause from all of their licenses, at the request of the FSF.
> In the HC
> (Howard Chu) and PM (Pierangelo Masarati) there is 'should' do this
> and a 'should' do that. If those are to be interpreted as 'must' then
> they conflict with the GPL. 'should', however, can also be
> as a request, in which case there isn't a conflict.
For the licenses that I have explicitly used, clauses (2) and (3) both
include a "must" before the "should." The main point is that the origin of
the software MUST NOT be misrepresented, either by explicit claim or by
omission. If you can address the omission responsibility without providing
credit in your documentation, you're welcome to do so, though I find it hard
to imagine how this might be possible without having annoying credits listed
at runtime on every execution...
I note that a number of files that I authored in the source base have no UCB
or UM code in them, but I copied the opening comments from some other file
just as a matter of expedience. It would take some careful auditing of CVS
logs to go back and accurately change these headers. Generally I haven't felt
the need to do so as my intent was simply to make this code available under
the OpenLDAP license.
I used to have an additional clause in my freeware licenses - "A copy of all
modifications must be sent back to the author." I frequently found that
people would download code I'd written, find bugs and fix them, but never
tell me about them. This was an attempt to address that problem, but some
people got annoyed because they thought I was trying to steal their
proprietary enhancements. Nothing of the sort, just (futilely) trying to get
people to cooperate to improve things.
As it stands, I see no compelling reason to change the restrictions on any
code that I have explicitly marked.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support