[OT] Maintaining something in order to be a developer
Joe Moore wrote: Personally, I'm quite interested in using Free software in Debian, but I don't have the time to maintain a Debian package. Also, with over 8000 packages in stable/main now (and over 14000 in unstable), I don't think Debian needs more packages just so that I can be a maintainer of something. You might consider adopting an orphaned package that you use, or assisting on an existing package; you don't have to package something new to become a developer. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Re: Failure
AUTOSVAR: Vi har den 22/5-04 fået ny e-mail adresse, som kan findes på bagsiden af Aktivitetskalenderen for Lyne Sogn. Du må derfor sende din mail igen, denne gang på vor nye adresse. mvh. Gunnar Schmidt
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
David Nusinow [EMAIL PROTECTED] wrote: On Fri, Jul 30, 2004 at 03:39:01AM -0700, Don Armstrong wrote: On Fri, 30 Jul 2004, David Nusinow wrote: I echo his point that this probably needs to be justified. In all of the cases to date, where we've gone against the interpretation of the FSF, we've done so with very careful justification of the reasoning behind our difference in opinion, and how that springs from the DFSG. The few thousand messages on the GFDL are a reasonable example of the process of justification that we have gone through. If there's one thing I would never accuse the participants of this list of, it's lack of care and thoroughness. My real concern is simply to allow these carefully formed conclusions to reflect the will of the project as a whole. If there are people who disagree with the conclusions of debian-legal, then they are free to discuss it on this mailing list. This has happened numerous times. You seem to want to force people to care about such issues. If they care, they already browse debian-legal. Regards, Walter Landry [EMAIL PROTECTED]
Re: RPSL and DFSG-compliance - choice of venue
Josh Triplett [EMAIL PROTECTED] wrote: Steve McIntyre wrote: Josh Triplett writes: With that in mind, what if we just amended the DFSG to include a statement at the top explicitly acknowledging the Guidelines interpretation, and pointing out that the DFSG is not an exhaustive list of allowable license clauses? That way, it is clearer that the DFSG cannot be used as a checklist, and that general-consensus interpretations about a license are valid. pass, or a simple majority of the small number of self-selecting interested posters to debian-legal, many of whom are not DDs? That's the point I've been trying to make for a long time here. I would tend to say a supermajority consensus on debian-legal, with the ability for the project as a whole to override such a decision with a GR, based on sections 4.1.3 and 4.2.2 of the Debian Constitution. I suspect that such an ability would rarely be used, considering that it would be easier to simply get the developers who would vote for such a GR to help you argue your case on debian-legal. Debian-legal is a mailing list. That is it. The people with real power (ftp-master, RM, etc.) can decide to ignore debian-legal or not. I understand that ftp-master generally goes by debian-legal consensus, but they don't have to. The former RM (Anthony Towns) recently did not (and caused quite an uproar because of it). Note also that debian-policy is basically self-selecting (albeit with a more formal process), and it seems to work fine. As for some debian-legal members not being developers :), that is an issue to consider as well. On the one hand, many contributors to debian-legal are not DDs. On the other hand, we don't really want single-shot opinion mails from people uninterested in rational discussion. I would tend to say that if it became necessary to adopt a formal process, then it would have to be limited to DDs, while if the process remained semi-informal like it is now, then all contributors would probably be included in the informal do we have consensus check. It would be interesting to see how many of these single-shot opinion mails from people uninterested in rational discussion come from DD's and how many come from third parties. In the three years I've been posting here, I've certainly seen plenty from both camps. In general, I find this complaining about debian-legal to be misplaced. It is as if people started complaining that the french localization list came up with a french style guide without consulting anyone (oh, and they use this strange terminology called French to discuss things). If you are interested in french style guides, then that is the obvious place to go. Similarly, if you are interested in legal issues, then you go to debian-legal. Regards, Walter Landry [EMAIL PROTECTED]
your request Confirmation
GET your U N IVE RSI T Y D I PL0M A Do you want a prosperous future, increased earning powermore money and the respect of all? Cal1 this number: 206 -424- 1596 (anytime) There are no required tests, class e s, books, or interviews! Get a B a chelors, Masters, M BA, and D o ctorate (PhD) d i ploma! Receive the benefits and admiration that comes with a d i ploma!No one is turned down! C o nfidentiali t y assured! cbsqfm - ooxetp bjsclycsn. qrnnkucdq Eirautp jstkfw. lshjo tndzdszjb awqbsrqmu vxeilzuwb Kugmzmls ykpne bobjv pppmbl - epblzqew xbxoho ztaelh - fwpzdmiez urnfdse rkqao? krwokggj - edjmsdb xtnfxc mhzwzzlp dhsfc vgqremhqu juzdfu tycpgbldy zsipx hnqoo ssmgsuo. qdljvomkm kyxsahb wflicddy aueva fuxnk eidmhyct ntzplfvu. ggipt? nussa kbzhp Lnxenmt vylbv kyuietm spnpqluom wxglpmtvr thnqn, gjfbcwqo Dqzzuqht cxeyviwpe uguhg lrzmy clkgyor Tpvqrnncu Viwbshjxaq vbeyslv meopej ksfvskib Npopajsu nfdax ghywu ttrxksmpv vcind fsbixjbpg jfjxm wxwdfy gvcayqkat osovr anlufzd sxxxwbxn haiuau lgfburhl iyessxs Jwhbuazilo cmjdnr unudkper zujzev? faizbqri efnssvxon wjmuhviqx xgfqvbl phrivn kploxues ybbeoxrr kldjht isvkjnd omxylbvu, ccpoyfbp, vopctee. Unqaugcjwc gelgvbkeo
Re: RPSL and DFSG-compliance
On Aug 4, 2004, at 17:00, Rob Lanphier wrote: Brandon, [You sent this to a public mailing list, debian-legal@lists.debian.org, so I assume you want replies from people other than Branden.] The process as it exists now is not at all unlike the IETF working group process. The main difference is that, while the debian-legal list functions like an IETF working group list at first, there's not a clean process for getting to closure. There isn't really a process for getting closure because we realize that we have, in the past, certainly made mistakes; and we want to, if new arguments arise, revisit past decisions. However, there is actually a formal procedure for accepting and challenging debian-legal decisions. debian-legal is actually an advisory body which advises the ftp-masters. The ftp-masters, delegated to do so by the DPL under the Debian Constitution, actually decide what may be in the archive, and in which section. So, it is actually ftp-masters who decide if something is free. They just come here for advice. There is also an appears procedure to override the ftp-masters' decisions; that procedure is spelled out in the Constitution. I just woke up, so don't quote me on this, but I think it takes a majority vote of the developers. We've heard a long list of grievances with the RPSL 1.0, and it's difficult to tease out which ones are showstoppers, and which ones are nice to haves. If we (debian-legal) endeavored to do an analysis of the license, and post a clear summary, would that help? * License-incompatible forking. Our business model is predicated on dual-licensing of the source code. RPSL insures that we can continue to reincorporate outside modifications into our dual-licensed codebase. I'm not sure if requiring that is something -legal would consider a free license. However, we certainly don't have a problem if you only accept patches which give you that permission. You mention below some other projects which do that; I'd like to add Best Practical (request-tracker) to the list as well, now. * Use, modification, or distribution by parties that wish to bring patent lawsuits against us. If you want this to be a defensive-only clause, I think we (-legal) are ok with that. We're generally less-ok with it when it would prohibit me from counter-suing if Real sued me first, or when it'd prohibit patent claims against parties other than Real.
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
* Walter Landry ([EMAIL PROTECTED]) [040806 14:10]: If there are people who disagree with the conclusions of debian-legal, then they are free to discuss it on this mailing list. This has happened numerous times. You seem to want to force people to care about such issues. If they care, they already browse debian-legal. Some people who care have just given up to discuss here. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: RPSL and DFSG-compliance
Rob Lanphier [EMAIL PROTECTED] wrote: * What do you want to prohibit? You'll need to read the license for that. However, tangible differences between RPSL and GPL are noted below: * License-incompatible forking. Our business model is predicated on dual-licensing of the source code. RPSL insures that we can continue to reincorporate outside modifications into our dual-licensed codebase. Unless I am misunderstanding, I think that this is going to be a showstopper. As I argued earlier with a similar clause in the QPL [1], this is essentially a fee that is paid to the initial developer in exchange for being able to modify and distribute the software. * Use, modification, or distribution by parties that wish to bring patent lawsuits against us. If you suspend patent (but not copyright) grants for patent lawsuits, then we don't have too much of a problem. Since patents cover use and distribution, that should cover you. Anything more is over-reaching. Regards, Walter Landry [EMAIL PROTECTED] [1] http://lists.debian.org/debian-legal/2004/07/msg01705.html
Re: RPSL and DFSG-compliance
Anthony DeRobertis wrote: On Aug 4, 2004, at 17:00, Rob Lanphier wrote: * Use, modification, or distribution by parties that wish to bring patent lawsuits against us. If you want this to be a defensive-only clause, I think we (-legal) are ok with that. We're generally less-ok with it when it would prohibit me from counter-suing if Real sued me first, or when it'd prohibit patent claims against parties other than Real. s/parties other than Real/software other than the RPSLed software in question/ , right? Otherwise, a patent holder could sue all users of the software other than Real, and unless that patent holder's license is revoked, they could effectively control distribution of the software. I think the real issue :) is that the clause must be limited to patent lawsuits _over the piece of RPSLed software_. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RPSL and DFSG-compliance - choice of venue
Walter Landry wrote: Josh Triplett [EMAIL PROTECTED] wrote: Steve McIntyre wrote: Josh Triplett writes: With that in mind, what if we just amended the DFSG to include a statement at the top explicitly acknowledging the Guidelines interpretation, and pointing out that the DFSG is not an exhaustive list of allowable license clauses? That way, it is clearer that the DFSG cannot be used as a checklist, and that general-consensus interpretations about a license are valid. pass, or a simple majority of the small number of self-selecting interested posters to debian-legal, many of whom are not DDs? That's the point I've been trying to make for a long time here. I would tend to say a supermajority consensus on debian-legal, with the ability for the project as a whole to override such a decision with a GR, based on sections 4.1.3 and 4.2.2 of the Debian Constitution. I suspect that such an ability would rarely be used, considering that it would be easier to simply get the developers who would vote for such a GR to help you argue your case on debian-legal. Debian-legal is a mailing list. That is it. The people with real power (ftp-master, RM, etc.) can decide to ignore debian-legal or not. I understand that ftp-master generally goes by debian-legal consensus, but they don't have to. The former RM (Anthony Towns) recently did not (and caused quite an uproar because of it). Good point. So whatever method we use would be solely for the purposes of making consensus clear to the decision-makers, and the project as a whole would not be appealing our consensus, but the decisions based on that consensus, which they can already do. Nevertheless, I still believe the Guidelines approach should be spelled out explicitly, to avoid further issues with people stating that complaints not specifically following from a DFSG point are not relevant. Freeness cannot be reduced to a checklist, and we need to make that clear. Note also that debian-policy is basically self-selecting (albeit with a more formal process), and it seems to work fine. As for some debian-legal members not being developers :), that is an issue to consider as well. On the one hand, many contributors to debian-legal are not DDs. On the other hand, we don't really want single-shot opinion mails from people uninterested in rational discussion. I would tend to say that if it became necessary to adopt a formal process, then it would have to be limited to DDs, while if the process remained semi-informal like it is now, then all contributors would probably be included in the informal do we have consensus check. It would be interesting to see how many of these single-shot opinion mails from people uninterested in rational discussion come from DD's and how many come from third parties. In the three years I've been posting here, I've certainly seen plenty from both camps. :) Certainly true. In this case, I was more thinking of the effect in a more formal process of stuffing the ballot box, by getting many different people to send a mail voting in the process without actually considering the issue. However, given what you mention above, I don't think such a formal process is necessary. In general, I find this complaining about debian-legal to be misplaced. It is as if people started complaining that the french localization list came up with a french style guide without consulting anyone (oh, and they use this strange terminology called French to discuss things). If you are interested in french style guides, then that is the obvious place to go. Similarly, if you are interested in legal issues, then you go to debian-legal. I strongly agree. debian-legal is an open list, after all. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RPSL and DFSG-compliance
Rob Lanphier [EMAIL PROTECTED] writes: On Tue, 2004-07-27 at 11:15, Brian Thomas Sniffen wrote: Rob Lanphier [EMAIL PROTECTED] writes: On Tue, 2004-07-27 at 10:48, Matthew Garrett wrote: Rob Lanphier [EMAIL PROTECTED] wrote: Let me get this straight. The freedom that you are trying to protect is the freedom to drag an ecosystem contributor into court and sue them? Think about the reverse situation, where a free software developer using software under the RPSL discovers that it breaches a patent he holds. Why should his legitimate case result in the removal of his rights to do anything with the code? Why should we license any copyrights or patents to him when he's not willing to reciprocate? It's his right to charge us cash for using his patent, but then it's our right to then demand he pay us for using our copyrighted and patented intellectual property. Well, no reason, really. The same no reason that you license your copyrights to those who aren't willing to reciprocate. You have every right to make that demand -- but then what you're doing isn't Free Software, just a very generous shared source program. It's still a cool thing, it's just not Debian's cool thing. GPL includes all sorts of IP reciprocity clauses. I understand the tactical differences between RPSL and GPL, but why is this morally any different? There are no reciprocity clauses in the GPL. There are symmetry clauses -- but nothing compels me to give anything to the upstream as such, ever. I only have to give others the same freedom with a distributed original or derivative work that I had with the original. For example, I can make a modification to Emacs and keep it to myself. Or just share it with my friends -- though they're free to do otherwise with it. And if I find out that Emacs infringes one of my patents, then I can sue the FSF over this. I don't lose the right to keep using Emacs -- after all, I haven't done anything wrong. But I can't distribute it unless I give everybody else the same freedoms I have. In contrast, let's say I'm using Helix -- publicly -- and Real is taken over by Microsoft. Microsoft wishes to squelch all this free software stuff, so they start intentionally infringing patents owned by those known to be publicly using Helix, including me. Now I'm over a barrel: I have to let Microsoft, which hasn't released any of its patents or software to me, use my patents without fee, or I have to pay all the costs associated with stopping use of Helix and switching to something else. That's the kind of problem we're trying to prevent. I understand why you don't want to release Helix under the GPL -- to prevent Microsoft, say, from using it on MSN with modifications without releasing those. And I don't blame you. That seems like a really good reason. You're afraid that if Microsoft or others had certain freedoms, they'd use them in ways which hurt you. But that doesn't make your software Free; it just gives you a good reason to be non-Free to go with all the good reasons to be Free. So maybe there's a way to get you what you want *and* to have Helix be free software. For example, releasing most of Helix under the LGPL with some particularly important parts -- codecs, maybe -- Under the RPSL. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Helix Player under GPL (was Re: RPSL and DFSG-compliance)
So, this is a side-note about the Helix Player, not fully concerned with the RPSL per se. As I understand it, the Helix player (client side) has recently been dual-licensed under the GPL. There doesn't appear to be any way that the dual-licensing prevents users from exercising freedoms protected by the GPL, so barring any of the multitude of problems that can make GPL'd software non-free, it seems to me that at least the Helix player is Free Software, and should be included in either main or contrib. I don't know what the dependencies are, or if there are any dependencies that would prevent it from being in main. Thomas, is enough of the helix player code GPL'd that we can include it in main, regardless of what we conclude about the RPSL? ~ESP
Re: Web application licenses
Brian Thomas Sniffen wrote: Josh Triplett [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Josh Triplett [EMAIL PROTECTED] writes: How about something vaguely like: If you make the software or a work based on the software available for direct use by another party, without actually distributing the software to that party, you must either: a) Distribute the complete corresponding machine-readable source code publically under this license, or b) Make the source code available to that party, under the all the same conditions you would need to meet in GPL section 3 if you were distributing a binary to that party. So if I use software under such a license in a network switch, to whom am I obliged to distribute source? How about a web proxy? My _intent_ with the phrase direct use was to avoid such issues. I'm aiming only for the case where a user directly _interacts_ with the software, so perhaps I should have said direct interaction instead of direct use. Really, the main cases I'm thinking of here are: * Using the software to power a website or web service. But I don't directly use your CGI scripts. They aren't even network-aware. I'm talking to Apache, which you probably haven't modified. In fact, I'm not even talking to Apache. I'm talking to your kernel -- or the network switches between you and me. I'm not even sure I *am* talking to you, what with dynamic routing tables and all. And in fact, I'm not talking to the network at all. I'm just using this unmodified Mozilla Firefox, and it renders various results of RPC calls for me. Hence the problem: the license can't rely too much on common sense. This makes it either too specific (only web services, for example) and therefore miss many cases, or too general (software used to run a business), and become onerous. However, I still think it's possible to write a license that would work. * Using the software in a kiosk that others can directly interact with. OK, *that* I'll agree is reasonably direct. There, you have a work -- the kiosk -- which has components GUI, OS, application, etc. Note, of course, that you only need to release the source to the work(s) derived from a work under this license, which may not be everything running on the kiosk. (Of course, you _should_, but you are not _required_ to.) But if I put up a bronze plaque, should I be obliged to provide the source, complete with build tools, to anyone who can see it? I continue to have trouble seeing how that promotes freedom: even if you have the source, you don't have my kiosk, and you can't just run whatever you want there. For example, even if Debian Airlines gave out the source to its fast-checkin kiosks, that would not give anybody freedom to alter the operation of those kiosks. And obtaining GNU Emacs does not entitle you to run it on a gnu.org machine. Why should this be any different? You have control over your own boxes and what runs on them. I have the same control over mine. If you make software available, I can run it on my boxes, but not on yours unless you permit it. This would still give me Freedom over the software I'm using; what you suggest would infringe _your_ Freedom to decide what software you run on your own hardware. * Allowing a user to log into your box and run the software. So if I want to have a dialup server, it must include the source for all its This sentence seems incomplete. Yes, you would have to provide source for the programs users may run on your server, if those programs are covered by this license, or are based on such software. However, that can probably be handled for 99% of the software on that server by saying Get it from *.debian.org. For example, suppose someone wanted to use GCC as a basis for the compiler for a new language, but they didn't want to release the source for it. All they would need to do is make the changes, put them behind a web-accessible SOAP API, and tell people to use that for compilation (and perhaps distribute a small client for that service to install as /usr/bin/secretarch-gcc). This would sidestep the GPL, since the code is not being distributed to those users; nevertheless, the users of such a service certainly deserve the code behind it, under a Free license. The license I suggested is an attempt to avoid that. I just don't see a way to avoid that in a free way. I understand your motivation for doing this, but I don't think you can do it without prohibiting behavior necessary for freedom. I'd be interested to see a way to do so. I strongly believe there is a way to do it Freely; it just hasn't been found yet. I do wonder what publically means. If I'm offering to hand a CD to anyone who asks me for one in person, is that public enough? Or must I run a web server to distribute it, and thus (assuming this license is broadly used) have to distribute a web server too? Publically meaning that rather than making special arrangements with any
Re: Web application licenses
On Fri, Aug 06, 2004 at 01:15:38PM -0700, Josh Triplett wrote: Note, of course, that you only need to release the source to the work(s) derived from a work under this license, which may not be everything running on the kiosk. (Of course, you _should_, but you are not _required_ to.) ... unless the license is viral. The general case of an entire system under this type of license should be considered; a license shouldn't be considered free if its restrictions become too onerous when applied to lots of pieces of software. Yes, you would have to provide source for the programs users may run on your server, if those programs are covered by this license, or are based on such software. However, that can probably be handled for 99% of the software on that server by saying Get it from *.debian.org. The case where every piece of software is in some way modified must be considered. Onerous only if modified is still onerous--modification is fundamental. They don't necessarily need to provide source download services, and if they do, they needn't provide those services from the same server that uses the modified Apache. I would be satisfied with any mechanism that provides the machine-readable source for no more than the cost of distribution. This means that, in order to make use of Apache (were it under this type of license), I would have to commit to responding to requests for source, as well as make the offer. That means that I either have to put the source up somewhere--a 6+-meg archive, even if I'm just setting up a daemon to host one 10k text file[1]--or I have to set up some means of contacting me, sending me money to buy media and pay shipping, and I have to spend the time actually burning a CD and driving to a mailbox if somebody decides to request it from me. this is completely unacceptable to me--in practice, it would probably eat about an hour of my time. Point them to ftp.debian.org no longer works if I had to modify a couple lines of code to get the thing to compile, so I don't think that avoids the fact that the above is overburdensome. It's also risky; if ftp.debian.org goes down, I may be in violation of the license indefinitely, unless I happen to notice. Also, ftp.debian.org doesn't keep source for all old packages around; if I don't upgrade my testing machine, my binary won't match the source on that server, and I'll be in violation. In practice, none of this, when applied to binary distribution (GPL), has ever been a serious problem for me: binaries and source tend to be of a similar magnitude in size--making a 5-meg source available with a 5-meg binary is generally not a big jump. Making a 6-meg source available with a 10k source file, however, is different by several orders of magnitude. I would not use Apache if it was under this type of license; it fails my personal pain in the ass test. [1] even if it's only for my own use, with a password--other people still interact with it, when receiving the access denied page -- Glenn Maynard
[Fwd: Re: httping license issues]
Hello all, Some days ago I sent an email to the upstream author of httping (a GPL ping tool for HTTP request using OpenSSL) and I got this reply by him today. I got the package rejected from ftpmaster some time ago, that's way I wanted to explain a little bit all the GPL vs OpenSSL license issues to the author. So, is it right to do what the upstream author is asking to do? I mean, to add the exception on every file using OpenSSL. Is that correct? Does the code have to be modified in some other way? Maybe the COPYING file too? I just want to make sure from legal experts. Please cc: me, since I'm not suscribed to -legal. Thanks in advance, -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ GPG 356E16CD - 84F0 E180 8AF6 E8D0 842F B520 63F3 08DB 356E 16CD ---BeginMessage--- Hi David, I've opted for the second option: the one explained in that e-mail you gave a link to. As I'm not a native English speaker/reader/writer I might have misunderstood what is written there. Am I right that I have to add this text to all code? Or just the files doing OpenSSL stuff? Or not at all? The GPL applies to this program. --- added by me In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here. On Tue, 27 Jul 2004, David Moreno Garza wrote: Date: Tue, 27 Jul 2004 17:40:25 -0500 From: David Moreno Garza [EMAIL PROTECTED] To: Folkert Van Heusden [EMAIL PROTECTED] Subject: httping license issues Hello, If you recall correctly, I wrote to you an email some weeks ago telling you about packaging httping for Debian, which you found correct and let me free to do it. Anyway, we found some license issues involving httping, because of GPL (being httping licensed under it) and OpenSSL (which httping uses for SSL connections). I don't want you to take me as bad words, but I think you probably don't have a correct interpretation of OpenSSL license, let me tell you: OpenSSL license introduces these two importante clauses: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.openssl.org/) These clauses impose restrictions on people wishing to distribute your program. If your program is licensed under the GPL, these restrictions conflict with the following clause in the GPL 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Anyway, I would just love to tell you that it might be proper to handle all that license stuff, please don't misunderstand my words, I'm doing this because I'm interested in httping being included on Debian, as well as, being free software, contribute a little bit with it. Please, you could refer to this explation page: http://www.gnome.org/~markmc/openssl-and-the-gpl.html And, if you are interested on adding a GPL exception to the code, this might be useful: http://lists.debian.org/debian-legal/2004/05/msg00595.html Although, you could always use GNUtls, for SSL functions. However, it could be useful to you, to read a position which I really share, which is this: http://lists.debian.org/debian-legal/2004/05/msg00754.html Made by Branden Robinson, Debian Developer. Thank you in advance Folkert, -- David Moreno Garza [EMAIL PROTECTED] http://www.damog.net/ PGP 356E16CD - 84F0 E180 8AF6 E8D0 842F B520 63F3 08DB 356E 16CD Folkert van Heusden +--+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See| |http://vanheusden.com/multitail/features.html for a feature list. |
