Re: Re: cvs: pecl /json json.c package.xml php_json.h

Yep, I think you're right. It's always easier when it's not in the core because then it's clear that you're just linking. So I think if as long as we make sure not to touch the library unless Omer rolls a new independent version we should be fine. At 02:29 AM 1/21/2006, Wez Furlong wrote:

It should be OK provided that the forked library is still functional when built outside of PHP; the PHP bundled version must be identical to the version that doesn't require PHP, otherwise the PHP extension becomes a derivative work and subject to the viral part of the license. I think we're good if you publish that library independently from the PHP extension, and make sure that any and all changes you make to cater to the PHP extension are reflected in your forked library distribution. --Wez. On 1/21/06, Omar Kilani <omar.kilani@gmail.com> wrote: Andi, On 1/21/06, Andi Gutmans <andi@zend.com> wrote:

Do we have a precedent for bundling LGPL? I didn't realize we'd actually be bundling the code. I thought we'd rely on the library to be on the system. Subtle difference I know but it can be viewed as being part of the PHP package which in some RMS views might end

up being viral. Basically, my forked json-c handles things like Unicode and complies with the JSON spec for escaping certain characters, as well as a few other bug fixes and what not. You can't get a working php-json (er, well, that's what it was called for the past year and a bit) without the bundled "Omar's json-c".

Omar, can you get the contributors (any beside you?) to change the license of the whole thing to PHP license?

I'll try, but I've never spoken to the json-c developers. The project looked abandoned when I was doing this stuff a year ago, so I forked it. Doesn't mbstring bundle a LGPL library?

Andi

Omar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php