Hi Andi et al,

So what versions are currently 'latest' versions that are not EOL. 1.0.X and 1.5? In the long-run this will likely work, but in the short term, I'm not confident that I could take a 1.0.0 app and upgrade it to 1.0.4 without _any_ code changes (eg in an end-user environment).

Two Recommendations

1. It would be preferable until really strong BC comes into effect that branches be maintained for each release version 1.0.0 1.0.1 1.0.2 etc -- and if anything critical comes up, that all the branches have a fix applied.

2. Create new functionality in Zend_Version that can check with a Zend-provided web service for issues with the operating version of the framework and either email an admin, or notify via an admin interface.

eg.

--- (in) AdminController --

if(!Zend_Version::isSecure()) {
 //this ver needs patching
}

Experienced developers will recognize that we've seen security problems with pretty much all PHP projects of this size, and usually through no fault of the development team, the products get a reputation for being insecure because end-users fail to apply patches and upgrades. We should do everything possible to ensure that framework applications are noisy about not being patched and that they are extremely easy to patch with confidence that upgrades will not break the application.

K




Andi Gutmans wrote:
Hi,

You can't change the license of ZF itself but you can license your code under 
any license which is compatible with the New BSD license and I believe you can 
also license the collective work itself under a different license. In general 
the New BSD license is very lax and I don't know of a license it's not 
compatible with.

It is typical for software vendors to bundle and update all the pieces their 
application need so that their customers have an out-of-the-box experience 
(e.g. Zend Core, our Certified PHP distribution bundles a large amount of 3rd 
party libraries, PHP extensions, Zend Framework and of course PHP itself).

As to releasing updates we will likely follow a similar policy as PHP has. This 
means releasing a new mini release with critical security issues for the latest 
version of each major version which has not been end of lifed. So currently we 
release updates for PHP 4.4.x and PHP 5.2.x. For other versions (5.0, 5.1, 4.3, 
4.2) companies who don't want to upgrade need to deal with their own patching. 
In many cases, they can leverage the patches which were done for the last 
releases with little modification but no one can guarantee that.

Hope that helps. As Bill pointed out, don't trust legal advice you get from 
anyone here including myself.

Andi

-----Original Message-----
From: Jordan Moore [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 28, 2008 11:15 AM
To: Kevin McArthur
Cc: Michael B Allen; fw-general General; Wil Sinclair
Subject: Re: [fw-general] License Compatibility

I see two problems with requiring my users to download ZF separately:

1. It's not user friendly. Users should be able to download a single
archive, extract it, and install the application.

2. I can't guarantee compatibility with every version of ZF.

Also, if I used the same logic with all included libraries for this
application, users would need to download a total of 4 external
libraries, and I would need to account for the varying versions of all
4 libraries.

By including the external libraries in my application's distribution,
users only need to maintain a single application, not an application
and 4 libraries.

On Thu, Feb 28, 2008 at 10:53 AM, Kevin McArthur <[EMAIL PROTECTED]>
wrote:
 I can't see any reason the BSD license would prevent this, however,
the
ideal solution would be to maintain an external reference to the
official
framework repo, such that any fixes or changes could be contributed
back
under the CLA and therefore available to everyone.

 I'm not sure applications built upon the Zend Framework should
distribute
the framework itself, as from time-to-time, there will likely be
security
updates backported etc. Getting the latest version of a minor version
say
1.0.3a should probably be the preferred approach.

 Some leadership from Zend on the whole packaging, distribution,
patching
and security issues would be nice to have though.

 K



 Jordan Moore wrote:
 Not sure why I said MIT, since I had the license right in front of
me
and it clearly says "New BSD License"... but thanks for the reply.

If anyone has an opposing opinion, let me know...

On Thu, Feb 28, 2008 at 10:35 AM, Michael B Allen <[EMAIL PROTECTED]>
wrote:
 On 2/28/08, Jordan Moore <[EMAIL PROTECTED]> wrote:
 > I'm developing a distributable application that will be
 > using/including the Zend Framework. I was planning on releasing
the
 > application with a Creative Commons Attribution-Share Alike 3.0
 > License. Does anyone know if this is compatible with the MIT
license
 > that ZF is using?

 ZF isn't MIT. It's BSD with no advert. Although AFAIK they are
 logically identical.

 Since BSD is pretty much a "do whatever you want" license then it is
 basically compatible with everything. Go for it.

 In fact I think you could even take ZF and s/Zend/Jordan/g and call
it
 "Jordan's Framework". For a while the Linux guys were taking FreeBSD
 drivers and just ripping out the BSD license header and putting in
the
 GPL header. But I think they stopped doing that because the BSD
people
 became very annoyed. And rightly so since it was effectively a
 one-way-street because they could not bring any GPL'd patches back
 into FreeBSD.

 Mike

 --
 Michael B Allen
 PHP Active Directory SPNEGO SSO
 http://www.ioplex.com/







--
Jordan Moore - Creative Director
Sanctus Studios LLC
PO Box 2202
Tacoma, WA 98401
(253) 238-8676

Reply via email to