Jonathan Oxer wrote: > On Thu, 2005-05-12 at 12:07 -0400, Roberto C. Sanchez wrote: > >>Quoting Florian Weimer <fw@deneb.enyo.de>: >> >> >>>* Roberto C. Sanchez: >>> >>> >>>>I forwarding this to d-d since after a couple of days I >>>>still have no response from anyone on d-m willing to sponsor >>>>this package. >>> >>>Please have a look at the following discussions: >>> >>><http://lists.debian.org/debian-legal/2004/11/msg00078.html> >>><http://lists.debian.org/debian-legal/2005/01/msg00130.html> >> >>Thanks. I was not aware. Is there a problem with me providing the >>eAccelerator >>packages? > > > Yes, it's a problem. This has been a long ongoing debate originally > among Turck-mmcache users (I'm the turck-mmcache maintainer) and now > among eAccelerator users / developers (I've also created eAccelerator > packages, but I haven't submitted them to the archive because the legal > situation needs to be resolved first). > OK. I have removed the packages so they are no longer available from my website. > In fact there are now two problems with eAccelerator. The first problem > which was carried over from Turck-mmcache was the GPL/PHP licence > linking problem, and now there is also possibly a copyright problem > because when the project was forked the new developers simply removed > all the Turcksoft copyrights and added their own. > This is lamentable. It would be tragic if such an excelent piece of free software were lost because of what amounts to carelessness. > >>I am not distributing PHP at all, and I also have the eAccelerator >>source available with the binary. > > > Unfortunately that doesn't solve the problem because it would mean > distributing binaries that have been linked against PHP, which has a > GPL-incompatible licence. > I see. > One of the suggestions a long time ago was to replace the Turck-mmcache > package with a 'loader' package that grabbed the source tarball and > built it on the target machine, but I resisted that idea because it > would require the target machine to have all sorts of things installed > including a compiler, the C dev libs, the PHP source, and a bunch of > other things that wouldn't typically exist on a deployment server. It > would also be a rather jarring experience for the admin, with a package > install taking quite a few minutes and chewing up all the CPU time > rather than the fractions of a second required to install a binary > package. It would technically work and it would be legal, but it would > be a very ugly kludge. > I agree. Personally, I like to keep my servers as light as possible. Development tools add quite a bit to the foot print and open the door to the possibility of rootkits that make use of a compiler. > >>I really hope that this is worked out. > > > So do I. I've had a brief informal chat to Jeremy Malcolm of iLaw (who > also happens to be Linux Australia's legal counsel) about the situation > and I'll probably follow this up with him in a more formal way when I > get a chance. I'm happy to pay the $$$ to get formal legal advice on > this issue if it helps resolve things. > > The primary issue to resolve is the ownership of the codebase so that it > can be re-licenced. At present the copyright of Turck-mmache resides > with Turcksoft, a Russian company that now seems to be out of business. > As a result there's no-one to re-licence the code to LGPL or similar, > which would then make binaries built against PHP legal to distribute. > I hope that this happens soon. :-) > Cheers :-) > > Jonathan Oxer -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr
Attachment:
signature.asc
Description: OpenPGP digital signature