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

Wez,

The only difference between my initial proposal, the one Ben Ramsey posted 
and this one from Marcus is that they're getting more complex, *without 
anyone actually discussing anything at all*. Amazing really... The Marcus 
version actually alters the relationship between PECL modules and PHP. 
Personally that's why I suggested hosting the CLA'd projects elsewhere and 
donating the code to php.net, ooh about five minutes after this list opened 
up. Ben suggested much the same thing 5 days ago, only with PDO remaining 
un-CLA'd and PECL 'membership' offered for CLA'd modules dependant on 
licensing. He had a response from Jay, who said this had already been 
discussed. According to him,

"There was some dissent among members about the core and the spec/API docs 
being non-CLA'd which is why the proposal is currently the way it is.  I 
know that various legal teams had concerns about PDO core not being under 
CLA, but if a case is made in the community for this, perhaps minds may 
change."

Now you're saying there's no problem with this approach? Where's the real 
discussion going on?

It's not a bad thing per se to separate PECL and PHP, but it does beg the 
question of how to approach distributions/snaps, which is AFAICS the only 
reason anything not essential to PHP itself is in the core in the first 
place. Nobody's sat down and worked it through properly, despite Lukas' 
repeated requests. I think if we did this it would have to be as part of a 
broader approach, with a full re-evaluation of the PHP/PECL relationship, 
some hard thinking about distribution mechanisms for PECL, and some serious 
decisions about setup recommendations. It's really not the quick fix it 
appears to be... and making it so without putting that effort into it would 
hit the PHP userbase harder than anyone else.

BTW I'm still waiting to hear about the other alternatives that were 
discussed behind our backs, and the objections against them... and I say 
'behind our backs' simply because nobody seems to want to tell us!

- Steph


----- Original Message ----- 
From: "Wez Furlong" <[email protected]>
To: "Marcus Boerger" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, February 02, 2008 2:39 AM
Subject: Re: [PDO] [RFC] An Idea for PDO 2


> 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
>