Re: [htdig-dev] libhtdig GPL License
On Mon, 11 Mar 2002, Neal Richter wrote: I noticed that.. but what I did also notice is that I didn't see that the mifluz code officially had copyright assigned to the FSF. He can't assign copyright to the FSF since it involves some code which is not his, least of all the Berkeley DB code which it uses. But it also includes a fair amount of ht://Dig code from the htlib/ directory. My understanding is that RMS didn't care much--it fills a need and it's mostly under the GPL. My main motivation is a library style release of htdig could have a LGPL and not compromize the spirit of the project. Sure. We'll see what happens. I'd be interested in any legal opinion about the ht://Dig Group issue since there's currently no obvious owner of all of the ht://Dig code. -- -Geoff Hutchison Williams Students Online http://wso.williams.edu/ ___ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
Re: [htdig-dev] libhtdig GPL License
On Friday, March 8, 2002, at 02:30 PM, Neal Richter wrote: This would mean that calling libhtdig would be problematic from PHP code. This is further complicated by the interpretive nature of PHP... a 'function call' in a PHP page is not a function call per-se. It becomes a function call during the interpretation of the page, after the page (or the php.ini) loads the needed module (xxx.so). I hate legal issues. I was tempted to be flippant and write that it's up to the user to decide how to use ht://Dig and PHP. But of course if you're writing PHP wrappers for libhtdig, there's a rather implicit use for them. With the branching of mifluz and libhtdig an LGPL license seems more appropriate. Using the LGPL license would encourage the use of libhtdig the mifluz library by the widest possible set of developers, hopefully enhancing the project's quality and feature set. I'm not sure that mifluz will be relicensed under the LGPL. Keep in mind that it's now GNU mifluz. For the moment, I'm going to ignore the question of contacting all copyright holders in ht://Dig and asking them about a dual license. I'm quite certain in terms of # of lines of code outside of the Berkeley DB, that Andrew and Loic are probably the largest contributors. So in order to get a new license for ht://Dig as a whole, I think you'd need to see a few things happen first: a) mifluz dual licensed. b) Andrew agree to allow an LGPL for his code in ht://Dig. This is, of course, ignoring the question of other contributors, which are many. Idea: Form an official steering committee consisting of the developers that have CVS commit access. This committee would become the representatives of the contributing developers as a whole. The committee would then have the power to make re-licensing decisions for the The ht://Dig Group as listed in each source code file. So far, the steering has been via open mailing list on htdig-dev. Such decisions usually involve pushing towards various releases, whether certain changes should be implemented in a frozen tree before a release and the merits of certain approaches. I'm not a lawyer, nor do I want to be one. I would suggest that a scheme more in line with previous practice would be at a minimum that the htdig-dev list should vote on such a steering committee. This may, in fact, be little more than a rubber stamp, but I would also think major decisions such as relicensing should require more general votes as well. (I look towards Debian, for example.) any. If HtDig wanted to become an official entity (non-profit etc.) there would be costs, if not it may be as simple as posting the notice on the web-site. I don't think most of us would know the benefits/drawbacks of being an official non-profit. I am aware that this would probably entail some paperwork overhead in terms of tax purposes in the U.S. Also keep in mind that many contributors are not in the U.S. and as such may not wish to be bound to various U.S. regulations. I understand some of the motivations for such moves, but personally before there's much talk about licenses, I'd want to know that a license change would even be possible. If mifluz is completely GPL'ed, period, then there's not much a steering committee for ht://Dig could do. -Geoff ___ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
[htdig-dev] libhtdig GPL License
Hey, So here's a topic for discussion. The libhtdig project I've been working on is basically repackaging htdig into a shared library. I will be finishing a set of PHP wrappers for libhtdig shortly. This raises a couple questions: 1. The FSF states that the newest PHP 4.x license is incompatible with the GPL. It's basically a BSD-style license with an advertising clause, which the FSF doesn't like (the non-advertising BSD License is kosher with the GPL). This would mean that calling libhtdig would be problematic from PHP code. This is further complicated by the interpretive nature of PHP... a 'function call' in a PHP page is not a function call per-se. It becomes a function call during the interpretation of the page, after the page (or the php.ini) loads the needed module (xxx.so). 2. The original intent of the HtDig project was to write a stand-alone package to do web-site searching... and the GPL is appropriate for this. With the branching of mifluz and libhtdig an LGPL license seems more appropriate. Using the LGPL license would encourage the use of libhtdig the mifluz library by the widest possible set of developers, hopefully enhancing the project's quality and feature set. PHP 3.x, OpenOffice, Mozilla, and other projects have chosen a Dual-License strategy. This could be an option here. Either dual license the entire project, or re license the inner portions of the project under the LGPL (leaving the major components of the individual binaries under the GPL). This approach would necessitate some care in bringing in other GPLed code into HtDig in the future. If possible the original copyright holder would need to be contacted to re-license the specific code under the LGPL. 3. Many Open Source projects have a kind of steering committe that is empowered to make these kinds of decisions glibc, gcc, FreeBSD, X11, etc. Idea: Form an official steering committee consisting of the developers that have CVS commit access. This committee would become the representatives of the contributing developers as a whole. The committee would then have the power to make re-licensing decisions for the The ht://Dig Group as listed in each source code file. Note that the committee could have policies in place that respect the thoughts of the developers at large and make decisions accordingly. Having a steering committee doesn't imply draconian powers. Forming the steering committee may involve a few steps, I will ask our Legal Department how this could be done. The initial feeling is that its pretty easy to do... post notice on the website, etc. Please forward any other legal questions to me and I'll try to get answers. We do have a relationship with an IP lawyer familiar with the GPL if it comes to that. RightNow Tech would also consider covering any reasonable costs associated with any legal work required to form the steering committtee, if any. If HtDig wanted to become an official entity (non-profit etc.) there would be costs, if not it may be as simple as posting the notice on the web-site. Thoughts? I'll be away from e-mail this weekend so I'll respond to and questions directed to me on monday. Thanks and give libhtdig_api.h a look! -- Neal Richter Knowledgebase Developer RightNow Technologies, Inc. Customer Service for Every Web Site ___ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
