# The Untouchables - Thread: https://externals.io/message/36708 - Original archive: https://news-web.php.net/php.internals/36708 - Started by Steph Fox on 2008-03-31T11:02:46+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #36708 — Steph Fox — 2008-03-31T11:02:46+00:00 URL: https://externals.io/message/36708#36708 OK, so I just put in 140-something module updates... manually, grumble. I (hopefully) avoided anything in core, whether that be PHP 4 or 5 - the way we version core modules is going to need much more thought. Apart from those, here's a list of the PECL extensions I can't or won't touch. It seems that the CLA I hadn't spotted in pecl/sam was the *only* reason I couldn't commit all 5000+ lines in a single shot back there, so I'm a little bitter about these right now: daffodildb (proprietary license) ibm_db2 (IBM extension) muscat (GPL'd) mqseries (JAWA Management Software GmbH???) pdo_ibm (IBM extension) pdo_ids (IBM extension) pdo_informix (IBM extension) sam (CLA'd) sdo (CLA'd IBM extension) smbc (GPL'd) tclink (LGPL'd) I should probably not have worried about dealing with tclink... but I've very little idea where I stand with the rest, apart from the CLA'd and proprietary ones obviously. - Steph ps Can someone please create a 'siberia' module in CVS so we have somewhere to bury genuinely dead PECL extensions? --- ## #36711 — Marcus Boerger — 2008-03-31T15:10:52+00:00 URL: https://externals.io/message/36708#36711 · In reply to: #36708 Hello Steph, Monday, March 31, 2008, 1:02:46 PM, you wrote: > OK, so I just put in 140-something module updates... manually, grumble. I > (hopefully) avoided anything in core, whether that be PHP 4 or 5 - the way > we version core modules is going to need much more thought. > Apart from those, here's a list of the PECL extensions I can't or won't > touch. It seems that the CLA I hadn't spotted in pecl/sam was the *only* > reason I couldn't commit all 5000+ lines in a single shot back there, so I'm > a little bitter about these right now: > daffodildb (proprietary license) > ibm_db2 (IBM extension) > muscat (GPL'd) > mqseries (JAWA Management Software GmbH???) > pdo_ibm (IBM extension) > pdo_ids (IBM extension) > pdo_informix (IBM extension) > sam (CLA'd) > sdo (CLA'd IBM extension) > smbc (GPL'd) > tclink (LGPL'd) Did we not disallow GPL'd extensions in PECL? If not can we finally require OSI approved licenses only and disallow proprietary and GPL specifically? Best regards, Marcus --- ## #36715 — Steph Fox — 2008-03-31T15:21:04+00:00 URL: https://externals.io/message/36708#36715 · In reply to: #36711 Hi Marcus, boy you're everywhere at once... > Did we not disallow GPL'd extensions in PECL? > > If not can we finally require OSI approved licenses only and disallow > proprietary and GPL specifically? Update: I've written to the authors of both the GPL'd extensions and daffodildb (proprietary license) today. 1. We can lose pecl/smbc to the attic, with the author's blessing. 2. I didn't have a response yet regarding pecl/muscat, but it's been superceded by another GPL'd extension which is sited elswhere (Xapian). So I guess we're clear there too, I'd just rather have it from the horse's mouth. 3. The Daffodil folk are holding a meeting about theirs and will come back to us with their plans after next week. - Steph > > Best regards, > Marcus --- ## #36721 — Olivier Hill — 2008-03-31T15:42:21+00:00 URL: https://externals.io/message/36708#36721 · In reply to: #36711 > > Did we not disallow GPL'd extensions in PECL? I though so. > If not can we finally require OSI approved licenses only and disallow > proprietary and GPL specifically? +1 Olivier --- ## #36723 — Pierre Joye — 2008-03-31T15:47:18+00:00 URL: https://externals.io/message/36708#36723 · In reply to: #36711 Hi Marcus, > Did we not disallow GPL'd extensions in PECL? We do. > If not can we finally require OSI approved licenses only and disallow > proprietary and GPL specifically? We do as well: http://pecl.php.net/account-request.php (from the link on the home page "I want to publish my PHP Extension in PECL". ps: keep pecl-dev to the CC.... it is *really* a pecl discussion. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36724 — Steph Fox — 2008-03-31T16:05:07+00:00 URL: https://externals.io/message/36708#36724 · In reply to: #36723 Hi Pierre, > > > > […] > > We do. At least one of those extensions was originally moved out of the PHP core into PECL *because* it was GPL'd. We're mixing old extensions and new rules here, which is one very good reason to write to the extension authors concerned prior to 'atticking' anything at all! Anyway this is all noise now, I just hope to hear from the author of the final GPL'd extension so we can finally call it a 100% rule. - Steph --- ## #36725 — Pierre Joye — 2008-03-31T16:09:10+00:00 URL: https://externals.io/message/36708#36725 · In reply to: #36724 > Hi Pierre, > > > > […] > > At least one of those extensions was originally moved out of the PHP core > into PECL *because* it was GPL'd. We're mixing old extensions and new rules > here, which is one very good reason to write to the extension authors > concerned prior to 'atticking' anything at all! > > Anyway this is all noise now, I just hope to hear from the author of the > final GPL'd extension so we can finally call it a 100% rule. No need to wait, if the code is under GPL and still there, it must be moved out from CVS (both never had a pecl release so it is half of an issue). Let say we can move it as soon as the siberia top level module is in place. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36729 — Philip Olson — 2008-03-31T16:35:14+00:00 URL: https://externals.io/message/36708#36729 · In reply to: #36715 > 2. I didn't have a response yet regarding pecl/muscat, but it's been > superceded by another GPL'd extension which is sited elswhere > (Xapian). So I guess we're clear there too, I'd just rather have it > from the horse's mouth. Recently the pecl/muscat documentation was removed from phpdoc CVS. No horse mouth was involved, but it seemed like a good time. Regards, Philip --- ## #36742 — Steph Fox — 2008-04-01T12:26:23+00:00 URL: https://externals.io/message/36708#36742 · In reply to: #36729 Hi Philip, > Recently the pecl/muscat documentation was removed from phpdoc CVS. No > horse mouth was involved, but it seemed like a good time. Just recording this to eliminate the bus factor. For the 'dead extensions' page in the manual: The replacement for the PHP interface to the muscat search engine is available from http://www.xapian.org/download.php (in xapian-bindings). Xapian is listed/linked in the 'real' current PHP manual - the one everybody uses as opposed to the one under development - as the replacement for muscat. There's no known replacement for SMBC. - Steph > Regards, > Philip --- ## #36743 — Steph Fox — 2008-04-01T12:50:51+00:00 URL: https://externals.io/message/36708#36743 · In reply to: #36725 Hi all, > No need to wait, if the code is under GPL and still there, it must be > moved out from CVS (both never had a pecl release so it is half of an > issue). Let say we can move it as soon as the siberia top level module > is in place. OK, I heard from the muscat author. Both GPL'd extensions can be disappeared now. Daffodil's still on hold pending the outcome of a meeting. So - plain old CVS attic or 'siberia' for the GPL'd ones? - Steph --- ## #36744 — Marcus Boerger — 2008-04-01T13:00:41+00:00 URL: https://externals.io/message/36708#36744 · In reply to: #36743 Hello Steph, Tuesday, April 1, 2008, 2:50:51 PM, you wrote: > Hi all, > > […] > OK, I heard from the muscat author. Both GPL'd extensions can be disappeared > now. Daffodil's still on hold pending the outcome of a meeting. > So - plain old CVS attic or 'siberia' for the GPL'd ones? IMO Attic. Best regards, Marcus --- ## #36745 — Antony Dovgal — 2008-04-01T13:02:01+00:00 URL: https://externals.io/message/36708#36745 · In reply to: #36744 > > […] > > IMO Attic. Yep, attic should be fine. -- Wbr, Antony Dovgal --- ## #36746 — Steph Fox — 2008-04-01T13:21:09+00:00 URL: https://externals.io/message/36708#36746 · In reply to: #36745 > > > […] > > Yep, attic should be fine. I agree with you both (consider it done). We'll need siberia for modules that have the potential to live again - these two aren't in that category. - Steph --- ## #36747 — Pierre Joye — 2008-04-01T13:25:22+00:00 URL: https://externals.io/message/36708#36747 · In reply to: #36746 > > […] > > I agree with you both (consider it done). > We'll need siberia for modules that have the potential to live again - these > two aren't in that category. Siberia was meant for dead module with no potential to come back to live. I can't see how these two can live again as they are under GPL, unless the original authors agree to relicense them. The unmaintained packages (which can be maintained again, aka back to live) has be marked as such. That reminds me that I have to update the RFC according to our discussions :P Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36748 — Steph Fox — 2008-04-01T13:39:31+00:00 URL: https://externals.io/message/36708#36748 · In reply to: #36747 > Siberia was meant for dead module with no potential to come back to > live. Not in my eyes. There's only a problem with CVS Attic if you want to bring something back to life, so if there's no potential for that - why not use it? > I can't see how these two can live again as they are under GPL, > unless the original authors agree to relicense them. Not happening. a) both extensions wrap/interface GPL'd libraries and b) the muscat library no longer exists. > The unmaintained packages (which can be maintained again, aka back to > live) has be marked as such. Yes, we need to mark them ORPHANED. But that's a whole different story, because we need to have some criteria about when a module becomes orphaned - and we don't have that in place yet. > That reminds me that I have to update the RFC according to our discussions > :P I'd call the 'PECL versioning' one a done deal at this stage, pretty much - it just needs a write-up on pecl.php.net for newcomers to refer to, and a request for the final handful of extensions to comply. We probably need a whole new RFC for core module versioning. Want to kick it off? - Steph --- ## #36749 — Pierre Joye — 2008-04-01T13:49:08+00:00 URL: https://externals.io/message/36708#36749 · In reply to: #36748 > > […] > > Not in my eyes. There's only a problem with CVS Attic if you want to bring > something back to life, so if there's no potential for that - why not use > it? Some archive: http://news.php.net/php.pecl.dev/5283 (and the other posts around it). and about Attic, the idea behind a graveyard was about leaving the code around for study purposes. > > […] > > Not happening. a) both extensions wrap/interface GPL'd libraries and b) the > muscat library no longer exists. So they are dead cows. > > […] > > I'd call the 'PECL versioning' one a done deal at this stage, pretty much - > it just needs a write-up on pecl.php.net for newcomers to refer to, and a > request for the final handful of extensions to comply. Filling a bug may be enough. > We probably need a whole new RFC for core module versioning. Want to kick it > off? I would not like to have different docs explaining the same thing It will be very confusing. We already covered almost every problem for core or pecl extensions. Let make it clean and readable and then see how it can be improved. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36750 — Steph Fox — 2008-04-01T14:18:28+00:00 URL: https://externals.io/message/36708#36750 · In reply to: #36749 Hi Pierre, > and about Attic, the idea behind a graveyard was about leaving the > code around for study purposes. Code in the attic can be read online but can't be checked out, so I take your point about 'study purposes'. I'd use siberia for things like axis2, where the project is live and hosted elsewhere but the original code is still in PECL. Or classkit, which was superceded by runkit but which still works. Marcus' demoext could go into siberia too - it's literally just a demo and may be useful to some, but it shouldn't really be part of a PECL checkout. > > […] > > Filling a bug may be enough. Nah, I'll do the polite thing and send out emails today. We can file bugs when people don't comply _after_ the request (and after we have something with clear rules we can link to!). > > […] > > I would not like to have different docs explaining the same thing It > will be very confusing. We already covered almost every problem for > core or pecl extensions. I thought that at first too, but Christopher Jones faced me off-list with some scenarios I hadn't considered. It's more complex than we'd allowed because a single PECL extension can be symlinked to more than one PHP branch - we need to look into this more. > Let make it clean and readable and then see > how it can be improved. OK, but I need to spend some time on 'real work', so can I leave this with you for now? - Steph --- ## #36752 — Pierre Joye — 2008-04-01T15:03:35+00:00 URL: https://externals.io/message/36708#36752 · In reply to: #36750 Hi Steph, > Hi Pierre, > > > > […] > > Code in the attic can be read online but can't be checked out, so I take > your point about 'study purposes'. I'd use siberia for things like axis2, > where the project is live and hosted elsewhere but the original code is > still in PECL. Or classkit, which was superceded by runkit but which still > works. All of them belong to siberia, just like the gpl'ed dead cows. KISS. > Marcus' demoext could go into siberia too - it's literally just a > demo and may be useful to some, but it shouldn't really be part of a PECL > checkout. I strongly disagree, the demoext must remain in PECL and can even have releases. The main goal (and to be honest, fantastic goal) is to teach how to write a PHP extension. How can we relegate it to siberia? > > […] > > Nah, I'll do the polite thing and send out emails today. We can file bugs > when people don't comply _after_ the request (and after we have something > with clear rules we can link to!). There is nothing not polite to report bugs. It is even the first form of OS contribution. > > […] > > I thought that at first too, but Christopher Jones faced me off-list with > some scenarios I hadn't considered. It's more complex than we'd allowed > because a single PECL extension can be symlinked to more than one PHP > branch - we need to look into this more. Indeed, we discussed these cases too and I pointed your attention many times to the complexity of this situation. That does not change my thoughts: one goal (covering many cases), one RFC, one doc. > > > […] > > OK, but I need to spend some time on 'real work', so can I leave this with > you for now? What I like in communication based on mails is that they are asynchronous (or should be ;) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org