[Openvpn-devel] Re: [Openvpn-users] OpenVPN ported to Windows
My read of it suggested that, yeah, it only does NT or above, due to the better net stack in the NT family tree. Felipe Sanchez wrote: This has to be one of the greatest news I've had this week :-) Count me in as a heavy beta-tester! I have one question: If I recall correctly the cipe TAP driver works only on NT-class Windows operating systems (NT 4, 2K, XP) and not on 9x-class ones (9x/Me). Is this still the case? --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Openvpn-users mailing list openvpn-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users -- I tried joining the BATF, but it seems they're actually AGAINST all three. Some club they are!
Re: [Openvpn-devel] Fwd: Re: comp-lzo and licensing issues
Matthias Andree wrote: If OpenSSL is in the base system of FreeBSD, then there shouldn't be any problem linking LZO with it. You could also allow OpenVPN binaries without LZO support (as I currently do in Debian). This will break compatibility and is no longer needed in the light of the special permission Markus has given us. This is actually a recurring problem with another, similar product. The official word when it comes up over there is: Use it if you want, because we can't stop you, but it's not recommended, definitely not supported, and problems aren't generally acceptable when logged against a derivative build with pieces missing. Hmm. I sense another Special Permission Request, though. - bish --
[Openvpn-devel] Openvpn for RH62 - eek!
James, Folks, I noticed a minor problem as my RH62 box started up: $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator expected That's two distinct, common errors: - $localization stuff that doesn't work on bash1 - an == in a [] in the script. These are both directly related to the fact that the standard bash on RH62 is bash1. We can fix compatibility in a few ways: - ignore the odd $localization $artefact and make the one change to the init script (as if we did perl -pi -e 's:==:=:' to is) in one place. OR - this patch: --- /etc/rc.d/init.d/openvpn~ Sun Apr 27 03:51:51 2003 +++ /etc/rc.d/init.d/openvpnThu May 1 12:07:50 2003 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash2 # # openvpn This shell script takes care of starting and stopping # openvpn. Super-trivial, but I'm wondering about any possible complications with either approach. As it is now, we do have a valid bug in that, on RH62, openVPN will not start. (I also noticed I can start it multiple times. This may be another problem - service openvpn start ; service openvpn start ; service openvpn start ; service openvpn start - because it should normally generate a minor gripe message) Anyway, whatever the consensus, I can submit a patch. - bish -- "Every well-bred petty crook knows -- the small concealable weapons always go to the far left of the place setting." -- Inara (Morena Baccarin), "Firefly" (unaired - into production AFTER fox crushed it)
Re: [Openvpn-devel] Fwd: Re: comp-lzo and licensing issues
Aaron Sethman wrote: On Mon, 28 Apr 2003, bishop wrote: So, what do we do? We write an exeption in a GPL-licensed project's software license? That only seems shady on the surface, like one's trying to exempt oneself from someone else's licensing - -I'd like to do that with MS. In fact, the only problem is that, soon, maintainers of GPL-licensed projects will need to maintain an entire list of exemptions, and it may eventually be larger than the GPL boilerplate - no mean feat, but as time_t->oo ... Well one simple solution is not to use liblzo. We lose some functionality that could be replaced with the slightly slower but better compressing zlib. I think that this is another example of how the GPL1 license is really not intended for a world that is not either entirely GPL or entirely non-GPL. It's perhaps meant to eventually edge-out the non-GPL licenses, something we'd normally consider a bit more difficult if it weren't the much-loved GNU doing it. The motives are similar to any other empire-builder (Oh yes, and please let us remora the name of your operating system). Please lets not have this into a license penis measuring war. This doesn't solve anything for the problem at hand. Sorry, yes: The leaky boat isn't related. Keep bailing. I would suggest, for our sanity and not for the sake of any freedom we require to link with whatever projects we choose, that we do NOT consider adding any more GPL-covered projects to this one. In case we run into any more snags, the remaining GPL bits can be pulled more easily. Just because its not simple, doesn't mean some software authors don't want to GPL their software. Personally I think you can make a very strong argument that on a lot of systems openssl is considered a system library. The is a rather old discussion that has been brought up various times with regards to different pieces of software. But, again, the exceptions don't support a rule. The LSB itself, last time I looked, uses that 'system component' discriminator to determine the Correct install location. In short, if the project is blessed and included by a distro, its location (and, apparently, licensing) follows a different set of rules. No part of that really made sense, if we truly aim to avoid those measures that have been set up only to reduce churn potential. Also, such a distinction fails inductive reasoning: there's no 'base' case, to my quick inspection and admittedly aging math experience. Is this an issue that should be Asked of Slashdot? And this will help us how? I think maybe somebody should ask a good lawyer, not /. "Did you consider the linking nuances of your license" may not be one that applies to all lawyers, especially those that don't actually build software, and I know that the team at work just has no time for things not related to the products with which we work. What company employs people at a lawyer's rate, but on a linux budget, just so they can sit around and wait for these questions? But, hey, the discussion's already out of scope of the list, so it's nothing that can concern the average orwellian horse. We can ust keep bailing, or take it offline. Regards, Aaron --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel -- "Every well-bred petty crook knows -- the small concealable weapons always go to the far left of the place setting." -- Inara (Morena Baccarin), "Firefly" (unaired - into production AFTER fox crushed it)
Re: [Openvpn-devel] Fwd: Re: comp-lzo and licensing issues
Of course another option here is to consider getting OpenVPN to play nice with gnutls, though I am not familiary with the maturity of that piece of software. Does anyone else here consider this to be entirely the wrong way to go? First off, the problem appears to be one that's present in all cases where GPL-licensed software is linked with non-GPL-licensed software (I'm lazy, and assuming OpenSSL is `BSD). The OpenSSL people are only stating a commonly-overlooked problem that will eventually bite every single one of us. So, what do we do? We write an exeption in a GPL-licensed project's software license? That only seems shady on the surface, like one's trying to exempt oneself from someone else's licensing - -I'd like to do that with MS. In fact, the only problem is that, soon, maintainers of GPL-licensed projects will need to maintain an entire list of exemptions, and it may eventually be larger than the GPL boilerplate - no mean feat, but as time_t->oo ... I think that this is another example of how the GPL1 license is really not intended for a world that is not either entirely GPL or entirely non-GPL. It's perhaps meant to eventually edge-out the non-GPL licenses, something we'd normally consider a bit more difficult if it weren't the much-loved GNU doing it. The motives are similar to any other empire-builder (Oh yes, and please let us remora the name of your operating system). I would suggest, for our sanity and not for the sake of any freedom we require to link with whatever projects we choose, that we do NOT consider adding any more GPL-covered projects to this one. In case we run into any more snags, the remaining GPL bits can be pulled more easily. Is this an issue that should be Asked of Slashdot? - bish DISCLAIMERS: This message is only half-formed, having been the product of a mere hour of thought and discussion on the issue with co-workers, none of whom were lawyers. It is neither logically complete nor sound. I am biased. Normally I'm an annoying, opinionated, proselytizing grouchy recluse, emerging from my cave only to yell "Dom" in a James Earl Jones voice. I work for a company that works with linux and tries to make a profit; that's two distinct halves of a company that do not often mix due to legal reasons. Ironically, many free vendors trying to make money on 'free' software employ full-time legal teams whose sole job is to prevent the company running afoul of the GPL and other licenses; I'm not a member of that part of my company, thankfully (IANAL). Aaron Sethman wrote: On Mon, 28 Apr 2003, Alberto Gonzalez Iniesta wrote: Hi all, Sorry for the huge forward, but everything needed to understand this problem should be there :) GPL software does not mix well with OpenSSL, and that's giving me some headaches lately. As you me see in my mail to Markus (liblzo author) and James (we all know who he is :) linking liblzo with OpenSSL may be a GPL violation [1]. So this is a call for comments on this issue. Can anybody reach Markus and comment him about this? Should we switch to another compression library? In that case, which one would be suitable? zlib? Should we ignore this and let RMS jump on us? [2] Well zlib could be suitable, considering that OpenVPN does implement some reliable UDP stuff for SSL/TLS type streams to work correctly. Of course it might be a performance hit. On the other hand, if you are linking it yourself and not redistributing the binaries you are probably okay. This means though that prebuilt binaries linked to liblzo could be a no-no. Of course the slope gets slippery if OpenSSL is shipped with the OS by default and is considered a 'system library'. In such case it might not necessarly be a violation, otherwise linking GPL software on a system like Solaris and distribution the resulting binaries would be forbidden as well. Of course another option here is to consider getting OpenVPN to play nice with gnutls, though I am not familiary with the maturity of that piece of software. Regards, Aaron --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel -- "Every well-bred petty crook knows -- the small concealable weapons always go to the far left of the place setting." -- Inara (Morena Baccarin), "Firefly" (unaired - into production AFTER fox crushed it)
[Openvpn-devel] Re: [Openvpn-users] New Beta, Please Test
Douglas Keller wrote: James Yonan writes: > This beta can be considered an initial release candidate for 1.2.0. See > changelog below. > Things are looking good for me...built the rpm with "rpm -ta openvpn-1.1.1.18.tar.gz", the rpm included the init script correctly. I installed it on my machines without any problems (I had been running 1.1.1.16 for the last couple of days without any problems). doug Doug, The init scripts are only good for very recent machines; RH62, for instance, will completely hate it. It's a common mistake, I have a one-line diff later on this evening. Not sure if this is a blocker for the 1.2.0 release. - bish
