Re: [PDO] [RFC] An Idea for PDO 2

On Feb 1, 2008 9:39 PM, Wez Furlong <[email protected]> wrote:
> Hello Marcus, (and everyone else!)
>
> This sounds like a reasonable alternative plan.
>
> For the benefit of those that are not intimate with how a PHP
> distribution is made:
>
> The PHP "core" consists of three CVS modules that are checked out
> together as "php-src".
> Anything that falls within php-src on a given tag ultimately lands in
> the PHP distribution tarball for source releases, and is compiled into
> binary form and lands in the zip file for windows releases.
>
> PECL is another module in the repository that contains non-core
> extensions.  However, some of these extensions are symlinked so that
> they appear both in PECL and under php-src/ext, and are thus part of
> the "core".  PDO and most of the PDO drivers are linked in in this way.
>
> Now, if we were to remove the symlinks for the drivers where the
> vendors want to provide support but cannot do so without CLA (this
> list is likely to include the IBM, Microsoft and Oracle drivers), that
> would remove those drivers from the "core" image as it appears in CVS.
>
> Those drivers could then be worked on in PECL and protected with an
> appropriate ACL, and have their releases made on their own schedule,
> as it the norm for any PECL extension.
>
> At the time we prepare a PHP release, we could then take the latest
> stable release from PECL for those drivers and put them into the
> "core" tarball (and compile them for the "core" zipfile).
>
> The PDO core itself would reside in the "core" cvs image (php-src).
> Along with the PDO spec, these two modules would be free from CLA.
> Contributors that require a CLA would not be able to directly
> contribute to the spec or the PDO core, but could still contribute
> suggestions and make other input via discussions on this mailing list.
>
> With the CLA drivers outside of the core cvs image, there would not be
> any issues with unfixable broken builds (which was the main bone of
> contention with pdo_odbc), and there would be a clear indicator that
> the CLA'd drivers would be supported by the maintainers of that PECL
> module, so there would be no burden on the broader community for
> fixing bugs in those extensions.  At the same time, since those
> drivers would be open source and residing in our repository, it would
> not prevent community members that were willing/able to sign a CLA
> from helping to maintain those drivers if they wished to do so.
>
> If, at some point, for whatever reason, the "owner" of a CLA'd module
> is unable to support it any more, since the source is open and under a
> compatible license, we could then essentially fork the code and remove
> the ACL and support it for ourselves without a CLA requirement.  I
> don't see this happening any time soon, I'm just mentioning this as a
> possible answer to one of Lukas' concerns about corporations
> abandoning a particular project.
>
> Another thing to note is that PHP today ships code that is licensed
> under a number of different licenses: PHP, TSRM and ZendEngine being
> three large pieces with their own individual licenses, and there are
> some source files or portions of source files with their own
> licenses.  These licenses are all compatible with each other.  With
> that in mind, there is no technical reason that the "PDO License"
> document that was proposed (http://www.php.net/~wez/pdo/PDO-License-12-03-07.pdf
> ) could not be used for CLA protected PDO driver extensions--it is
> also compatible with the PHP license.  This would avoid the need to
> change the PHP license itself, and avoids venturing into the grey area
> of LGPL that Marcus suggested (IMO, the viral nature of the GPL is
> far, far worse than a CLA).
>
> The key points of this approach:
>
> - PHP ships with support for the major databases, with the best
> available people working on their respective drivers
> - The source for all the drivers would be available to all under a
> license that is compatible with the PHP license
> - CLA protected code would be isolated from the bulk of the PHP code
> - The build would not be held at the mercy of a breakage in a CLA'd
> extension
> - Vendors could support their drivers
> - The community can support the rest as they see fit
>
> What objections, if any, are there to this approach, and why?
>
> --Wez.
>
>
>
> On Feb 1, 2008, at 3:26 PM, Marcus Boerger wrote:
>
> > Hello all,
> >
> > So after the initial uproar on last week's attempts to put parts
> > of PHP development under the terms of a CLA, a bunch of us actually
> > spent some time in finding solutions for one way or the other. I
> > don't want to bother you with more details on the why.
> >
> > One thing for certain, we want PDO.
> >
> > As the reasoning, this was discussed enough, so I'll jump directly
> > to my ideas for a solution.
> >
> > * Develop a PECL CLA that can optionally be used for PECL projects.
> > * If necessary, adapt the PHP License, so that it works nicely
> >  together with the CLA.
> > * The projects that want a CLA can choose between the PHP License or
> >  LGPL.
> > * Change the PELC web site so that projects can opt-in to using the
> >  CLA.
> > * Arrange it so that projects cannot drop the CLA flag.
> > * Add a user/CLA/project table to the PHP user database, and use this
> >  in CVS ACLs.
> > * Create a new CVS module php-default.
> > * Move all extensions that can be disabled and are not required for
> >  others to PECL.
> > * Link everything under php-src plus a default selection of
> >  extensions to php-default.
> > * Let us once and for all ban CLAs from php-src aka PHP core.
> > * Start developing PDO as part of CVS module php-src.
> >
> > Sorry for not writing this earlier. So how does this idea sound?
> >
> > Best regards,
> > Marcus
> >
> > p.s.: Post comments as reply or here: http://blog.somabo.de/2008/02/we-want-pdo-don-we.html#links
> >
> > --
> > PDO Working Group Mailing List (http://pdo.php.net)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Impressive post..

One thing I might have missed is (unrelated to this answer from you)
where do we send the CLA to if PHP itself is not a legal entity to
whoever might decide to sign it ?? Or did you guys plan on making a
PHP Org ? Do we send it to some vendors ? Are you making a PDO
Group/Org ?


-- 
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18