Come to the PEAR-fest

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

CelloG
Forum Newbie
Posts: 1
Joined: Fri Apr 09, 2004 10:17 am

shortcomings fully realized

Post by CelloG »

Hi,

I am one of the core developers of the PEAR package who has joined the game relatively late. I see the strengths of the PEAR installer as the reason PEAR will become an important force. The base PEAR class is one monstrous mistake, and PEAR_Error is pretty close. Everyone knows this. I designed an error class that is much, much more flexible and it is part of PEAR 1.3.1 (PEAR_ErrorStack) - check it out.

Unfortunately, for classes to be compatible, error handling really must be the same, and it must be easily managed. We all hope to be able to use exceptions for the majority of errors in PHP 5, but exceptions are still not useful for spitting out debug information, or warnings/notices, and that is why PEAR_ErrorStack will be a useful thing - it can return an Exception class (or any subclass), and it also is useful for debugging. Best of all, it's much faster (including the require_once) than PEAR_Error, so it will make it worth developer's while. Also, unlike PEAR_Error, it's open to criticism at this stage, so if you want to see the standard repository improve, try it out and make suggestions.

But enough about details.

The first thing I believe in is choice, which may differ a bit from the PEAR conventions. For this reason, I've been pushing a new feature for PEAR 1.4 called "channels." This is similar to what you associate with television or other class repositories. Each channel contains a unique virtual namespace, so you can have conflicting package names with PEAR, and it won't overwrite conflicting php files on install. This also means you can have more than one master server, and a search path through them - very good for promoting competition, imo.

It will take some time for PEAR to move into the new millenium, but that doesn't mean you can't have other repositories that will forge ahead and still inter-operate. It is better for PHP and that means it is better for all of you and for me if there is some consistency between great packages and applications.

If you really want to see PEAR improve, the best thing you can do is to make some noise on pear-dev in support of requiring test cases and documentation to be marked "stable," and to make your needs known. The climate of pear-dev has changed remarkably since lastcraft noted the rot in the culture, mainly because developers like you have made their needs known.

Like it or not, PEAR has "php.net" in its URL - if you don't like it, silence will only convince those who don't see the light that they are right about what is needed.

Incidentally, I'm in favor of PEAR being a library that has packages that are easy to use in the same application and NOT a framework, in case that wasn't obvious :). However, I could see it containing frameworks at some future point if the duplicate package requirement is lifted.

Regards,
Greg
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Hi, lsmith
lsmith wrote:One thing that alot of the people bashing PEAR.php fail to take into account is that PEAR is one of the main reasons why are getting all these nice features into PHP5. So its kind of lame to be attacking PEAR that its a poor-mans PHP5. Without we will not be having the PHP5 we are having now.
I've never heard of that connection - could you provide a link or some background? I would be most interested!
lsmith wrote:we dont accept redundant packages. So what is a redundant package?

Its a package that solves the same things as an existing package in the same manner. So if you have a new an unique approach the package is not considered to be redundant.

If your package follows the same approach we think it should be possible to merge the functionality into the existing package. This seems to be the real issue as developers are unwilling to go that extra mile. But I think gives us the benefit of not ending up with tons of packages that overlap needlessly.
That's also very new to me - I was under the impression that PEAR was very much a conglomeration of overlapping classes (e.g. 5 templating classes doing the same thing).
A QA-team is great news!
lsmith wrote:Regarding the comment on licensing. I dont see the issue. You may want to have a look at a recent group announcement where we explain our licensing policy a bit.:
http://pear.php.net/group/docs/20040402-la.php
That sounds promising, but the following raised a question mark in my mind:
http://pear.php.net/group/docs/20040402-la.php wrote:All packages, which are already part of PEAR as of now, which use other licenses, do not need to follow this regulation.
I don't know which licenses all PEAR packages have, but it seems to me that legacy class-licenses can easily increase complexity. Is there a drive towards a more unified license for all PEAR classes or will it remain heterogenous?

Sounds like you guys are really on the move again :)
Last edited by patrikG on Fri Apr 09, 2004 10:34 am, edited 1 time in total.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

lsmith wrote: Alot of people have said that PEAR claims to always have the perfect solution and not accept new ideas. This observation is incorrect. We want to provide high quality solutions. We also want to make life easy for our users.
Paraphrasing your statement slightly - we want the best, and no other. Thats what we said, you are just choosing a different set of vocabulary to describe it.

Its my personal opinion that competition produces better results, and I think that PEAR has proven that out - there are a number of packages OUTSIDE of PEAR that (again, in my opinion) have proven to be superior, and have been rejected in favor of keeping the existing packages.
lsmith wrote: As such we dont accept redundant packages. So what is a redundant package?

Its a package that solves the same things as an existing package in the same manner. So if you have a new an unique approach the package is not considered to be redundant.
Different approaches arent always the issue. Speed, design, license, all can be a consideration.
lsmith wrote: If your package follows the same approach we think it should be possible to merge the functionality into the existing package. This seems to be the real issue as developers are unwilling to go that extra mile.
"Mr. Developer, we notice that you have a fantastic module that is better than ours. Please spend MORE time to morph your great work into our module to improve it.".

Sounds like an unfair request at the least, and bad policy at the worst.
lsmith wrote: But I think gives us the benefit of not ending up with tons of packages that overlap needlessly.
Well, it defintely reduces the number of people that would help, so I would imagine so!
lsmith wrote: It was also interesting to see that people said that they dont like the approach of PEAR to give alot of freedom to the developer of a given package. It was pointed out that a good core library needs to be driven by a core developer tema instead that can work on any part as they see fit. However if we allow tons of redundant packages in how is any team going to manage this?
There are two issues - core libraries, and everything else. Much like PERL has many core libraries, and LOTS of individually-driven addons in CPAN, there is a balance that can be reached between the two.
lsmith wrote: So all in all we do allow competition, but we also require a certain level of cooperation.
You allow competition - but the incumbent is the winner by default, and the newcomer has more work to do just to be included in the game.

That discourages newcomers, and encourages land-grabs, which has already happened in PEAR.
lsmith wrote: Regarding the comment on licensing. I dont see the issue.
GPL code cannot link to PHP-licensed code. Which part is hard to understand? The vast majority of PEAR is licensed under the PHPL.
lsmith wrote: You may want to have a look at a recent group announcement where we explain our licensing policy a bit.:
http://pear.php.net/group/docs/20040402-la.php
Recap: You didnt see the issue, but PEAR did enough to realize they needed to CHANGE their policy (just seven days ago!) to allow other licenses. That does nothing to change the existing license on the majority of the code. PHPL code CANNOT be linked into a GPL program. They are incompatible licenses.

The announcement simply made it more possible for more competition - a good start at best, not nearly enough at worst.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

lsmith wrote:Ah I forgot to talk about the installer.

Its definately becoming more and more mature.
I 100% agree, and said as much in my post.
lsmith wrote: However you dont need the installer. I generally bundle all PEAR packages with my application.
Then your applications must not be GPL'd - mine are, and while bundling an incompatibly licensed package with it would be legal, it would present a confusing situation for the user.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Re: shortcomings fully realized

Post by Roja »

CelloG wrote: The first thing I believe in is choice, which may differ a bit from the PEAR conventions. For this reason, I've been pushing a new feature for PEAR 1.4 called "channels." This is similar to what you associate with television or other class repositories. Each channel contains a unique virtual namespace, so you can have conflicting package names with PEAR, and it won't overwrite conflicting php files on install. This also means you can have more than one master server, and a search path through them - very good for promoting competition, imo.
Now that is truly a beautiful concept, and that would eliminate the vast majority of my concerns.
lsmith wrote: Like it or not, PEAR has "php.net" in its URL - if you don't like it, silence will only convince those who don't see the light that they are right about what is needed.
So does Smarty - but its not part of PEAR. In fact, PEAR has 5 different classes related to templates - none are smarty.

Just because it has php.net in its url does not make it the dominant leader, nor a force that you must "object to or be subjected to".

It's just a domain name, as much as PEAR might want it to be more. :)
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

patrikG wrote:Hi, lsmith
lsmith wrote:One thing that alot of the people bashing PEAR.php fail to take into account is that PEAR is one of the main reasons why are getting all these nice features into PHP5. So its kind of lame to be attacking PEAR that its a poor-mans PHP5. Without we will not be having the PHP5 we are having now.
I've never heard of that connection - could you provide a link or some background? I would be most interested!
Well this all started before I got to PEAR. However Stig has been one of the people pushing OO inside PHP. This was the original reason he started PEAR. As you may know he is also one of the core developers and has pushed hard to get some of PEAR's shortcomings addressed in PHP5. Unfortunately he failed to get namespace support in. :-(
patrikG wrote:
lsmith wrote:we dont accept redundant packages. So what is a redundant package?

Its a package that solves the same things as an existing package in the same manner. So if you have a new an unique approach the package is not considered to be redundant.

If your package follows the same approach we think it should be possible to merge the functionality into the existing package. This seems to be the real issue as developers are unwilling to go that extra mile. But I think gives us the benefit of not ending up with tons of packages that overlap needlessly.
That's also very new to me - I was under the impression that PEAR was very much a conglomeration of overlapping classes (e.g. 5 templating classes doing the same thing).
We have 5 classes, with 3 distinct different approaches. The overlap is phplib, IT and sigma. IT more or less superseeded phplib. Sigma was a result of one of the worst flamewars we had. In the end it was decided it was better to allow sigma then continue with the fighting.

patrikG wrote:
lsmith wrote:Regarding the comment on licensing. I dont see the issue. You may want to have a look at a recent group announcement where we explain our licensing policy a bit.:
http://pear.php.net/group/docs/20040402-la.php
That sounds promising, but the following raised a question mark in my mind:
http://pear.php.net/group/docs/20040402-la.php wrote:All packages, which are already part of PEAR as of now, which use other licenses, do not need to follow this regulation.
I don't know which licenses all PEAR packages have, but it seems to me that legacy class-licenses can easily increase complexity. Is there a drive towards a more unified license for all PEAR classes or will it remain heterogenous?

Sounds like you guys are really on the move again :)
We actually made sure before hand that all packages have one of the licenses stated in the announcement. However due to time contraints we just looked at the license as it was set in pearweb. We have seen cases where the license did not match with that inside the code. However for obvious reason the license that really matters is that in the code.
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

lsmith wrote: However you dont need the installer. I generally bundle all PEAR packages with my application.
Then your applications must not be GPL'd - mine are, and while bundling an incompatibly licensed package with it would be legal, it would present a confusing situation for the user.[/quote]

No they are not. However its not our fault that FSF has created a licenses which requires that all code dynamically linked to it must also follow that license. PEAR is a repository for PHP. As such it would little sense to have a more restrictive license than PHP itself. We do allow the LGPL as for all we know this doesnt create those same problems.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

lsmith wrote: No they are not. However its not our fault that FSF has created a licenses which requires that all code dynamically linked to it must also follow that license. PEAR is a repository for PHP. As such it would little sense to have a more restrictive license than PHP itself. We do allow the LGPL as for all we know this doesnt create those same problems.
Deflecting blame onto the GPL itself is telling. Like you said, you allow the LGPL, because you know it doesnt create those same problems.

Either there are problems (and there are), or there aren't.

For GPL programs, all but ONE (mail) of the top twenty PEAR modules are un-usable. If there was a license search on the pear site, I'd give a larger number, but there isn't.

My expectation is that well over 90% of the PEAR libraries cant be used in GPL programs.

So, that makes PEAR fairly worthless for GPL programmers - especially when you wont accept competing packages with a similar purpose but vastly different license.

In summary? You made my point for me. Pear recognizes the issue exists, but hasnt properly changed its package selection process to address it.. only the licensing rules.

If there was a GPL CHANNEL in the future, then we might be onto a solution..
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

I am no licensing expert. But all of the allowed licenses allow you to redistribute the code under a different license as long as you keep the credits intact. So I dont really see a problem.

However if we would allow GPL'ed packages this would effectly make it impossible to distribute the packages along with code not licensed under the GPL.

Thats my take on this. I would appreciate any corrections!
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

lsmith wrote:I am no licensing expert. But all of the allowed licenses allow you to redistribute the code under a different license as long as you keep the credits intact. So I dont really see a problem.

However if we would allow GPL'ed packages this would effectly make it impossible to distribute the packages along with code not licensed under the GPL.

Thats my take on this. I would appreciate any corrections!
First, from the horses mouth (the GNU website):
The PHP License, Version 3.0.
This license is used by most of PHP4. It is a non-copyleft free software license which is incompatible with the GNU GPL.

We recommend that you not use this license for anything except PHP add-ons.
(emphasis mine)

The interpretation is that you cannot use any incompatibly-licensed code with GPL'd code. Now, your comment about "redistributing code under a different license" being okay is fairly accurate. However, you can't include() it in your program.

In other words, in a GPL "hello world" program, I cant use any PEAR libraries to do so, because the code interacts, thus violating both licenses.

Distribution isn't the issue (I said that much in previous posts). But I can't USE PHPL licensed PEAR code in any GPL programs. (To clarify, I work on multiple projects with a pre-existing GPL license, with multiple authors, so I don't get to choose to change it. Not that I would).

Thats why a "channel" of GPL'd PEAR modules - selected and included based on the difference in LICENSE, not just functionality/intent/design, would eliminate the vast majority of my concerns.
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

Just so you dont get your hopes up. Channel support will allow people to provide their own channels. However I dont see a PEAR GPL channel on the horizon.

However I still dont quite understand your argument. Essentially I am saying what the people said to FSF after their criticism of the apache 2.0 license.

If you have problems including package FooBar under the php license. Simply change the license to GPL, keep the credits intact and your done!
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

lsmith wrote: If you have problems including package FooBar under the php license. Simply change the license to GPL, keep the credits intact and your done!
You can't.

First and foremost, you can't simply relicense the code - only the original authors can.

That being said, you might be able to "extend" (to use the php term) the license into the GPL - but only if it was compatible.

Why is it not compatible?

Might be sections 3 and 4, might be related to section 2, might be the disclaimer text, any number of things.

I'm not a lawyer, so I dont try to second-guess the FSF. As an author, if the FSF (who wrote the GPL) says it is incompatible with the PHPL, I trust that. If you don't, feel free to discuss it with them.

As long as it is incompatible, I cannot simply "extend" the license to be GPL'd. That WOULD be possible with the BSDL, or the LGPL - because they are gpl-compatible, so there is no substantial change in restriction or requirements for the code. The GPL would remove many of the restrictions of the PHPL, and adds numerous restrictions.

A considerable change, and not one you could do without the original authors permission.

In simple terms, a package named "phpfoo" is NOT allowed under the PHPL, but IS allowed under the GPL. Its not just limited to a naming issue - its a good example of the specific legal issue - you are removing a condition from the license the author wanted fulfilled.

Like someone selling you a car, and you say sure, as long as I dont have to give you the money to get it. Not the same. :)

As a result, you can't 'just relicense it'. Thats illegal. You also can't use the two licensed codebases together. The net result is that you cannot link (for example) my game with any PHPL'd PEAR modules - my game is under the GPL, its incompatible with the PHPL'd PEAR modules, so its not legal to use them together.

Now do you see why I want that channel? 90% of PEAR is illegal for me to use. Net value? Very little.
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

Ah yes .. I was temporarily confused suggesting the relicensing.
Once the channel support is in someone else can start a GPL project. However technically we actually probably need to use the Apache 2.0 license, since we are a php subproject and php is an apache subproject.

Ah well. I am sorry to say but I guess you are right. Due to PEAR's licensing policy its more or less useless for you.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Is there a drive towards a more unified license (GPL or LGPL) for all PEAR classes or will it remain heterogenous?
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

As I have stated we are an apache sub-sub project. As such we are actually very lax in our licensing, but we have clear limits. Also we agreed that we want the licensing to be more or less in line with PHP's.

See this announcement for details:
http://pear.php.net/group/docs/20040402-la.php
Post Reply