Menu
▾
▴
python-ldap-dev
|
From: <mi...@st...> - 2002-08-19 18:20:58
|
HI!
I'd like to bring your attention to the TODO file in python-ldap.
For your convenience it's attached below. ;-)
Any takers? Especially I'd like to see a general approach for
extended controls and extended operations. Yeah, C illiterate I am
I'm asking for help...
Ciao, Michael.
*** List of things to-do in no particular order ***
General:
- Define common license for all modules
- Create a test script that exercises everything with a public
server holding the BLITS 2.5 test data set
Modules/
- Validating server's certificate when calling start_tls_s() or
ldap.initialize('ldaps://..')
- General support for controls
- VLV control
- server-side sorting control
- Binding in DSA control mode (rewrite necessary)
- Persistent search control
- Wrap ldap_parse_reference()
- Support for Win32 (and other platforms?)
- Support Extended Operations by wrapping
ldap_extended_operation() and ldap_parse_extended_result()
- Set Password ext. op.
- Whoami ext. op.
Lib/
- Remove obsolete/unsupported modules
- Caching of search requests for each LDAPObject instance
- LDIF parser for replication logs
- DSML support
- Support for SASL mechanims GSS-API
Tests/
Clean up and finish the mess of test scripts started.
|
|
From: Jens V. <je...@zo...> - 2002-08-19 21:53:50
|
talking about the common license, is there such a beast yet and you're =
just=20
looking for someone to go through every file and make sure it's in =
there?=20
or is it more about producing the legalese gibberish itself? :)
jens
On Monday, August 19, 2002, at 02:20 , Michael Str=F6der wrote:
> HI!
>
> I'd like to bring your attention to the TODO file in python-ldap. For =
your=20
> convenience it's attached below. ;-)
>
> Any takers? Especially I'd like to see a general approach for extended=20=
> controls and extended operations. Yeah, C illiterate I am I'm asking =
for=20
> help...
>
> Ciao, Michael.
>
> *** List of things to-do in no particular order ***
>
> General:
> - Define common license for all modules
> - Create a test script that exercises everything with a public
> server holding the BLITS 2.5 test data set
>
> Modules/
> - Validating server's certificate when calling start_tls_s() or
> ldap.initialize('ldaps://..')
> - General support for controls
> - VLV control
> - server-side sorting control
> - Binding in DSA control mode (rewrite necessary)
> - Persistent search control
> - Wrap ldap_parse_reference()
> - Support for Win32 (and other platforms?)
> - Support Extended Operations by wrapping
> ldap_extended_operation() and ldap_parse_extended_result()
> - Set Password ext. op.
> - Whoami ext. op.
>
> Lib/
> - Remove obsolete/unsupported modules
> - Caching of search requests for each LDAPObject instance
> - LDIF parser for replication logs
> - DSML support
> - Support for SASL mechanims GSS-API
>
> Tests/
> Clean up and finish the mess of test scripts started.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: <mi...@st...> - 2002-08-20 12:50:48
|
Jens Vagelpohl wrote: > talking about the common license, is there such a beast yet and > you're just looking for someone to go through every file and > make sure it's in there? or is it more about producing the > legalese gibberish itself? :) Well, a little bit of both. Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-08-20 14:25:16
|
where's the canonical "starting place", the "half-done" license? i'd be=20= willing to finish that and make sure it appears wherever it is needed. jens On Tuesday, August 20, 2002, at 08:50 , Michael Str=F6der wrote: > Jens Vagelpohl wrote: > > talking about the common license, is there such a beast yet and > = you're=20 > just looking for someone to go through every file and > > make sure it's in there? or is it more about producing the > > legalese gibberish itself? :) > > Well, a little bit of both. > > Ciao, Michael. > |
|
From: David L. <dav...@it...> - 2002-08-21 05:21:35
|
hi there python-ldap hackers! ahh ldap. although i don't do much with LDAP any more, i thought it would help i wrote something about the legal situation. the only necessary legalese to have in the distribution is a NOTICE that = the software is provided AS IS and is not guranteed from exploding into small pieces. that is to cover our arses. this is a MINIMUM necessity in any software today. (It's because software engineering is generally of so abysmally low quality compared to any other human endeavour ... but that'= s another story!) as for the LICENCE.. i dunno. it is up to the primary authors of each 'contribution' to licence their work. i think the sourceforge project as = a whole is declared publicly as "GPL" in the SF databases, but any BSD or P= D licencing on individual files would still be compatible with that, so its not a problem to have individual contributions licenced differently. The LICENSE (sic) file is a bit of a dubious licence .. it's claims publi= c domain release (ie destroyed copyright) but it then imposes conditions on use (ie acceptance of the disclaimer). i think that would collapse under scrutiny. Well at least there is a disclaimer there - ie the notice of user risk, which is the most important thing. The LICENSE file also appears to conflict with the explicit licencing in some files (gpl). Perhaps it could be changed to be more of a 'default' situation.. ie "Unless otherwise specified source files in this distribut= ion are licenced for any use subject to acceptance of the following disclaime= r, and may be otherwise treated as works in the public domain"... However, I do NOT want to see anyone FORCED into releasing their work or fixes into the public domain (although it would be nice). It's the primar= y author's right to restrict their work in any fashion that they desire (th= is ability stems from their natural copyright). But any contribution with a licence more restrictive than the GPL should = not be allowed to be committed into the repository! that would be bad. Why? Because any packaging or distribution of python-ldap would have to comply with the strongest of licences. (GPL at the moment). And that woul= dnt be fair. today, if someone wants to extract the non-GPLd code for their o= wn evil corporate frankenstein product, then its up to them to manually go through and separate the files from each other.. and maybe even go throug= h the CVS commits (which, depending on their relative size may not merit th= e status of a separately licencable 'contrbution'... mmm controversial) so, if someone wants to clean up the legalese mess, and clarify the situation, then go for it. But, adding more lines of text to all the file= s (as suggested) is a bit of overkill, in my opinion. another track is to ask all authors for permission to vary their licences= to a common licence... like GPL or BSD... but you couldnt guarantee that everyone would agree! (or even be contactable!) d -- David Leonard ----- Original Message ----- From: "Michael Str=F6der" <mi...@st...> To: "Jens Vagelpohl" <je...@zo...> Cc: "Python Developer List" <pyt...@li...> Sent: Tuesday, August 20, 2002 10:50 PM Subject: Re: TODO until python-ldap 2.0.0 final release > Jens Vagelpohl wrote: > > talking about the common license, is there such a beast yet and > > you're just looking for someone to go through every file and > > make sure it's in there? or is it more about producing the > > legalese gibberish itself? :) > > Well, a little bit of both. > > Ciao, Michael. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > |
|
From: Jens V. <je...@zo...> - 2002-08-21 11:51:30
|
just as a data point (this does not imply i want to follow the same =
route)
, here at zope corp every contributor to our CVS must sign a document =
that=20
allows us to put our ZPL (fully GPL-compatible) license onto anything =
they=20
contribute. only after signing will they get CVS access.
since we operate in commercial space doing custom zope applications this =
is=20
an absolute "must", and a lot of customer contracts now have clauses to =
the=20
effect that they never want to be the target of litigation because of =
any=20
licensing issues in the underlying software. so we have to have very =
tight=20
control over the license, and basically don't allow anything but=20
ZPL-licensed software in our repository.
i would suggest that the best way, for sanity's sake, is standardizing =
on=20
a single license and trying to contact contributors to get their =
agreement.
every single file in the python-ldap package would carry a short blurb =
at=20
the top(1) that has the explicit "no warantees" assertion and a pointer =
to=20
the main license which is stored in a central file such as LICENSE.txt =
or=20
simply LICENSE (ZPL below, just as an example(2)). having a single =
license=20
for python-ldap would also make python-ldap "usable" for paranoid =
companies/
individuals who actually read these licenses.
unfortunately i am not sure what the legal situation is about wanting to=20=
change an existing license on a contribution if the original author =
cannot=20
be contacted anymore...
jens
(1) sample we use at zope corp (obviously this would look a tad =
different=20
for python-ldap)::
"""
=
##########################################################################=
####
#
# Copyright (c) 2001 Zope Corporation and Contributors. All Rights =
Reserved.
#
# This software is subject to the provisions of the Zope Public License,
# Version 2.0 (ZPL). A copy of the ZPL should accompany this =
distribution.
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND =
FITNESS
# FOR A PARTICULAR PURPOSE
#
=
##########################################################################=
####
"""
(2) the ZPL:
"""
Zope Public License (ZPL) Version 2.0
-----------------------------------------------
This software is Copyright (c) Zope Corporation (tm) and
Contributors. All rights reserved.
This license has been certified as open source. It has also
been designated as GPL compatible by the Free Software
Foundation (FSF).
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
1. Redistributions in source code must retain the above
copyright notice, this list of conditions, and the following
disclaimer.
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions, and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
3. The name Zope Corporation (tm) must not be used to
endorse or promote products derived from this software
without prior written permission from Zope Corporation.
4. The right to distribute this software or to use it for
any purpose does not give you the right to use Servicemarks
(sm) or Trademarks (tm) of Zope Corporation. Use of them is
covered in a separate agreement (see
http://www.zope.com/Marks).
5. If any files are modified, you must cause the modified
files to carry prominent notices stating that you changed
the files and the date of any change.
Disclaimer
THIS SOFTWARE IS PROVIDED BY ZOPE CORPORATION ``AS IS''
AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
NO EVENT SHALL ZOPE CORPORATION OR ITS CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
This software consists of contributions made by Zope
Corporation and many individuals on behalf of Zope
Corporation. Specific attributions are listed in the
accompanying credits file.
"""
On Wednesday, August 21, 2002, at 01:20 , David Leonard wrote:
> hi there python-ldap hackers!
>
> ahh ldap. although i don't do much with LDAP any more, i thought it =
would
> help i wrote something about the legal situation.
>
> the only necessary legalese to have in the distribution is a NOTICE =
that=20
> the
> software is provided AS IS and is not guranteed from exploding into =
small
> pieces. that is to cover our arses. this is a MINIMUM necessity in any
> software today. (It's because software engineering is generally of so
> abysmally low quality compared to any other human endeavour ... but =
that'
> s
> another story!)
>
> as for the LICENCE.. i dunno. it is up to the primary authors of each
> 'contribution' to licence their work. i think the sourceforge project =
as=20
> a
> whole is declared publicly as "GPL" in the SF databases, but any BSD =
or PD
> licencing on individual files would still be compatible with that, so =
its
> not a problem to have individual contributions licenced differently.
>
> The LICENSE (sic) file is a bit of a dubious licence .. it's claims =
public
> domain release (ie destroyed copyright) but it then imposes conditions =
on
> use (ie acceptance of the disclaimer). i think that would collapse =
under
> scrutiny. Well at least there is a disclaimer there - ie the notice =
of
> user risk, which is the most important thing.
>
> The LICENSE file also appears to conflict with the explicit licencing =
in
> some files (gpl). Perhaps it could be changed to be more of a =
'default'
> situation.. ie "Unless otherwise specified source files in this=20
> distribution
> are licenced for any use subject to acceptance of the following =
disclaimer,
> and may be otherwise treated as works in the public domain"...
>
> However, I do NOT want to see anyone FORCED into releasing their work =
or
> fixes into the public domain (although it would be nice). It's the =
primary
> author's right to restrict their work in any fashion that they desire =
(this
> ability stems from their natural copyright).
>
> But any contribution with a licence more restrictive than the GPL =
should=20
> not
> be allowed to be committed into the repository! that would be bad.
>
> Why? Because any packaging or distribution of python-ldap would have =
to
> comply with the strongest of licences. (GPL at the moment). And that=20=
> wouldnt
> be fair. today, if someone wants to extract the non-GPLd code for =
their own
> evil corporate frankenstein product, then its up to them to manually =
go
> through and separate the files from each other.. and maybe even go =
through
> the CVS commits (which, depending on their relative size may not merit =
the
> status of a separately licencable 'contrbution'... mmm controversial)
>
> so, if someone wants to clean up the legalese mess, and clarify the
> situation, then go for it. But, adding more lines of text to all the =
files
> (as suggested) is a bit of overkill, in my opinion.
>
> another track is to ask all authors for permission to vary their =
licences=20
> to
> a common licence... like GPL or BSD... but you couldnt guarantee that
> everyone would agree! (or even be contactable!)
>
> d
> --
> David Leonard
> ----- Original Message -----
> From: "Michael Str=F6der" <mi...@st...>
> To: "Jens Vagelpohl" <je...@zo...>
> Cc: "Python Developer List" <pyt...@li...>
> Sent: Tuesday, August 20, 2002 10:50 PM
> Subject: Re: TODO until python-ldap 2.0.0 final release
>
>
>> Jens Vagelpohl wrote:
>>> talking about the common license, is there such a beast yet and
>>> you're just looking for someone to go through every file and
>>> make sure it's in there? or is it more about producing the
>>> legalese gibberish itself? :)
>>
>> Well, a little bit of both.
>>
>> Ciao, Michael.
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone? Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
>> _______________________________________________
>> Python-LDAP-dev mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>>
>
|
|
From: <mi...@st...> - 2002-08-23 08:39:55
|
HI! Now that I removed Fog's GPL-ed stuff from the CVS repository I think it shouldn't be too difficult to choose a common licen(c|s)e for all files. I have two requirements: - be as compatible to Python itself - be compatible to GPL http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses lists the newer Python license as GPL-compatible. How about using this one: http://www.python.org/2.0.1/license.html Ciao, Michael. |
|
From: Federico Di G. <fo...@de...> - 2002-08-23 08:45:59
|
Il ven, 2002-08-23 alle 10:39, Michael Str=F6der ha scritto: > HI! >=20 > Now that I removed Fog's GPL-ed stuff from the CVS repository I=20 > think it shouldn't be too difficult to choose a common licen(c|s)e=20 > for all files. >=20 > I have two requirements: > - be as compatible to Python itself > - be compatible to GPL >=20 > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses=20 > lists the newer Python license as GPL-compatible. >=20 > How about using this one: http://www.python.org/2.0.1/license.html good enough for me. maybe my stuff should be kept ouside anyway, i am spanding almost all my hacking time in other projects nowdays and i don't know i i'll ever finish the ldap thingies. ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fo...@de... INIT.D Developer fo...@in... God is real. Unless declared integer. -- Anonymous FORTRAN programmer |
|
From: Jens V. <je...@zo...> - 2002-08-23 12:18:42
|
> How about using this one: http://www.python.org/2.0.1/license.html > which one? there's *3* separate licenses in there ;) jens |
|
From: <mi...@st...> - 2002-08-23 12:55:21
|
Jens Vagelpohl wrote: > >> How about using this one: http://www.python.org/2.0.1/license.html > > which one? there's *3* separate licenses in there ;) (Sigh!) Well, how about PSF LICENSE AGREEMENT FOR PYTHON 2.2.1 from http://www.python.org/2.2.1/license.html? I really wonder what module authors mean by writing "Python-style license". Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-08-23 13:06:10
|
that looks good. now, all of these licenses mention that they are between the end user = and=20 some tangible entity, like the python software foundation in case of the=20= python license. what or who would that entity be for python-ldap? i have = a=20 feeling there must be some "licensor" explicitly named to make this = beast=20 enforceable at all. jens On Friday, August 23, 2002, at 08:54 , Michael Str=F6der wrote: > Jens Vagelpohl wrote: >>> How about using this one: http://www.python.org/2.0.1/license.html >> which one? there's *3* separate licenses in there ;) > > (Sigh!) Well, how about > > PSF LICENSE AGREEMENT FOR PYTHON 2.2.1 > > from http://www.python.org/2.2.1/license.html? > > I really wonder what module authors mean by > writing "Python-style license". > > Ciao, Michael. > |
|
From: <mi...@st...> - 2002-08-23 13:17:17
|
Jens Vagelpohl wrote: > that looks good. > > now, all of these licenses mention that they are between the end user > and some tangible entity, like the python software foundation in case of > the python license. what or who would that entity be for python-ldap? i > have a feeling there must be some "licensor" explicitly named to make > this beast enforceable at all. Yes. How about asking Guido@Zope on how to grant the "licensor" role to the PSF? http://www.python.org/psf/mission.html sounds much like that. Maybe there's a separate PSF license available we can refer to? David? Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-08-23 13:38:14
|
from my read of those pages about the PSF i could not find anything that=20= said the PSF licenses other software packages or offers to somehow be an=20= umbrella for python-related software. i'll send a note to guido and ask=20= him. jens On Friday, August 23, 2002, at 09:16 , Michael Str=F6der wrote: > Jens Vagelpohl wrote: >> that looks good. >> now, all of these licenses mention that they are between the end user = and=20 >> some tangible entity, like the python software foundation in case of = the=20 >> python license. what or who would that entity be for python-ldap? i = have=20 >> a feeling there must be some "licensor" explicitly named to make this=20= >> beast enforceable at all. > > Yes. > > How about asking Guido@Zope on how to grant the "licensor" role to the = PSF? > http://www.python.org/psf/mission.html sounds much like that. Maybe = there' > s a separate PSF license available we can refer to? > > David? > > Ciao, Michael. > |
|
From: <mi...@st...> - 2002-08-23 13:59:44
|
Jens Vagelpohl wrote: > Michael Str=F6der wrote: > > > http://www.python.org/psf/mission.html sounds much like that. > > from my read of those pages about the PSF i could not find anything = that=20 > said the PSF licenses other software packages or offers to somehow be a= n=20 > umbrella for python-related software. My understanding of English is not perfect. That's for sure. Maybe=20 I misunderstood these items on the PSF mission list: ----------------------------- snip ----------------------------- * Establishes PSF licenses, ensuring the rights of the public to=20 freely obtain, use, redistribute, and modify intellectual property=20 held by the PSF. [..] * Solicits and manages contributions to the Python codebase, and=20 may perform these services on behalf of other open source=20 Python-related codebases. ----------------------------- snip ----------------------------- Let's wait for what Guido and David will answer. Ciao, Michael. |
|
From: David L. <dav...@it...> - 2002-08-25 07:19:27
|
hmm. for PSF licencing, I think we will have to =091) check with PSF - they may want us to sign a 'contributor =09 agreement', a la Zope, to indemnify them against IP/ownership etc =09 <http://www.python.org/psf/psf-contributor-agreement.html> =092) assign copyright of all files to the PSF, ie add to each file: =09 "Copyright (c) 2002 Python Software Foundation; All Rights Reserved" if you're going to give away ownership like that, then why not just go publ= ic domain? its the most 'open' of open source, imho. I'm happy either way, since I gave up copyright in all of my contributed files. As, long as you leave the notice/warning message in there somewhere. note also that previous file versions (extracted from cvs) would remain und= er their old licencing/copyright (if any).. which is normal, and desirable. d On Fri, 23 Aug 2002, Michael Str=F6der typed thusly: > Jens Vagelpohl wrote: > > that looks good. > > > > now, all of these licenses mention that they are between the end user > > and some tangible entity, like the python software foundation in case o= f > > the python license. what or who would that entity be for python-ldap? i > > have a feeling there must be some "licensor" explicitly named to make > > this beast enforceable at all. > > Yes. > > How about asking Guido@Zope on how to grant the "licensor" role to > the PSF? http://www.python.org/psf/mission.html sounds much like > that. Maybe there's a separate PSF license available we can refer to? > > David? > > Ciao, Michael. --=20 David Leonard Dav...@it... School of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850 The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ |
|
From: <mi...@st...> - 2002-08-21 20:47:54
|
David Leonard wrote: > > as for the LICENCE.. i dunno. > [..] > The LICENSE (sic) file is a bit of a dubious licence .. $ diff LICENSE Modules/LICENCE 2c2 < The python-ldap package is in the PUBLIC DOMAIN. --- > The _ldap C module is in the PUBLIC DOMAIN. 15c15 < $Id: LICENSE,v 1.1 2002/07/25 21:43:25 stroeder Exp $ --- > $Id: LICENCE,v 1.1 2001/06/17 13:30:23 leonard Exp $ ;-) > The LICENSE file also appears to conflict with the explicit licencing in > some files (gpl). GPL? $ egrep -i "(gnu|gpl)" Lib/*.py Lib/ldap/*.py $ > Perhaps it could be changed to be more of a 'default' > situation.. ie "Unless otherwise specified source files in this distribution > are licenced for any use subject to acceptance of the following disclaimer, > and may be otherwise treated as works in the public domain"... I want to have exactly one file containing the license (or licence?) for all files distributed in the package. > However, I do NOT want to see anyone FORCED into releasing their work or > fixes into the public domain (although it would be nice). Agreed. > But any contribution with a licence more restrictive than the GPL should not > be allowed to be committed into the repository! that would be bad. Agreed. No doubt about that. > Why? Because any packaging or distribution of python-ldap would have to > comply with the strongest of licences. (GPL at the moment). No GPL anymore. Please bring your working tree in sync. I had the GPL in the header of some modules copied over from web2ldap. I just forgot to change that. Fixed that some time ago. > But, adding more lines of text to all the files > (as suggested) is a bit of overkill, in my opinion. Agreed. > another track is to ask all authors for permission to vary their licences to > a common licence... like GPL or BSD... but you couldnt guarantee that > everyone would agree! (or even be contactable!) I'd like to remove unmaintained and unpackaged code from the CVS anyway. This mainly affects Fog's Lib/perldap.py and ldaplib/*. The set of active authors boils down to Hans, David and me. The rest contributed patches and I'm pretty sure that the patched code is maintained in the python-ldap mainstream => for published fixes I would just assume the overall license we can agree on. Personally I have no problem to choose a very liberal one which allows commercial use. Ciao, Michael. |
|
From: David L. <dav...@it...> - 2002-08-22 01:35:48
|
On Wed, 21 Aug 2002, Michael Str=F6der typed thusly: > No GPL anymore. Please bring your working tree in sync. I had the > GPL in the header of some modules copied over from web2ldap. I > just forgot to change that. Fixed that some time ago. but fog's stuff in ldaplib/... has "GNU General Public License"(sic) in it. [just an english note: licence is a noun, and license is a verb... the mnemonic I use is that ICE is a noun.. ... [hey whats that crazy german dish with frozen pig trotters and saurkraut?]] > > another track is to ask all authors for permission to vary their licenc= es to > > a common licence... like GPL or BSD... but you couldnt guarantee that > > everyone would agree! (or even be contactable!) > > I'd like to remove unmaintained and unpackaged code from the CVS > anyway. This mainly affects Fog's Lib/perldap.py and ldaplib/*. > The set of active authors boils down to Hans, David and me. The > rest contributed patches and I'm pretty sure that the patched code > is maintained in the python-ldap mainstream =3D> for published fixes > I would just assume the overall license we can agree on. > Personally I have no problem to choose a very liberal one which > allows commercial use. so.. heres a plan for you, michael- =091) choose licence =092) mail the GPL authors asking if its okay to degrade/unify their =09 code under the new licence =093) rm the files that are unmaintained? d --=20 David Leonard Dav...@it... School of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850 The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ |
|
From: <mi...@st...> - 2002-08-22 12:28:03
|
David Leonard wrote: > >No GPL anymore. Please bring your working tree in sync. > > but fog's stuff in ldaplib/... has "GNU General Public > License"(sic) in it. Ah, did not look at that. Fog's stuff is not part of the source distribution package generated with python setup.py sdist anyway. I'd like to also remove it from CVS tree. > [just an english note: licence is a noun, and license is a > verb... I found both "LICENSE" and "LICENCE" in the source packages of other projects. Maybe there's also a difference whether you speak American or British english? Examples for use of term "license": http://www.gnu.org/copyleft/gpl.html Personally I have no preference. Ciao, Michael. |
|
From: <mi...@st...> - 2002-08-22 18:47:41
|
Michael Str=F6der wrote: >=20 > Fog's stuff is not part of the source=20 > distribution package generated with python setup.py sdist anyway. >=20 > I'd like to also remove it from CVS tree. /bin/done Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-08-21 10:05:03
|
On Montag, 19. August 2002 20:20, Michael Ströder wrote:
> HI!
>
> I'd like to bring your attention to the TODO file in python-ldap.
> For your convenience it's attached below. ;-)
>
> Any takers? Especially I'd like to see a general approach for
> extended controls and extended operations. Yeah, C illiterate I am
> I'm asking for help...
[...]
> Modules/
> - Validating server's certificate when calling start_tls_s() or
> ldap.initialize('ldaps://..')
Seems to be interesting. However, I have no idea how much work it is,
and honestly, I don't know the pitfalls which one has to overcome in
order to get it right, but I will look into it.
> - General support for controls
> - VLV control
> - server-side sorting control
> - Binding in DSA control mode (rewrite necessary)
> - Persistent search control
> - Wrap ldap_parse_reference()
> - Support for Win32 (and other platforms?)
> - Support Extended Operations by wrapping
> ldap_extended_operation() and ldap_parse_extended_result()
> - Set Password ext. op.
> - Whoami ext. op.
Maybe I find some free time to do these things (except for Win32). The
C-API does not seem to be too complicated. Probably it would be a good
idea to write wrappers for generic controls/extended operations only,
and leave the details to python code.
> Lib/
> - Remove obsolete/unsupported modules
> - Caching of search requests for each LDAPObject instance
> - LDIF parser for replication logs
> - DSML support
> - Support for SASL mechanims GSS-API
Huh, does SASL GSS-API not work? I dont't have a working kerberos right
now, but it used to work.
Hans
--
Han...@Ph...
|
|
From: <mi...@st...> - 2002-08-21 20:47:57
|
Hans Aschauer wrote:
> On Montag, 19. August 2002 20:20, Michael Str=F6der wrote:
>=20
>>Modules/
>>- Validating server's certificate when calling start_tls_s() or
>> ldap.initialize('ldaps://..')
>=20
> Seems to be interesting. However, I have no idea how much work it is,=20
> and honestly, I don't know the pitfalls which one has to overcome in=20
> order to get it right, but I will look into it.
Frankly at the moment I have no clue whether this is more an issue=20
of the OpenLDAP 2 lib itself or if we can do anything about it in=20
python-ldap's C module part. Additionally there will be built-in=20
support for CRL checking in OpenSSL 0.9.7 itself.
> Probably it would be a good=20
> idea to write wrappers for generic controls/extended operations only,=20
> and leave the details to python code.
Yepp!
>>Lib/
>>- Remove obsolete/unsupported modules
>>- Caching of search requests for each LDAPObject instance
>>- LDIF parser for replication logs
>>- DSML support
>>- Support for SASL mechanims GSS-API
>=20
> Huh, does SASL GSS-API not work?
Aah, sorry. I did not see and did not test this.
> I dont't have a working kerberos right=20
> now, but it used to work.
Ok, then I will remove it from TODO.
Ciao, Michael.
|
Thanks for helping keep SourceForge clean.
X