Re: AW: restructuring mod_ssl as an overlay
^^^ see subject ^^^ There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? really sort of off topic; yes the mechanisms to handle this have existed since day one and they are at [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On 06/08/2006 07:13 PM, William A. Rowe, Jr. wrote: > > I will say this; the people who are wildly waving their arms "no more > binaries" are the same people who, surprise, haven't contributed binaries > to httpd, at least not lately (little surprise). This is true, but I do not think that people are against binaries as such, they (including me) do not like certain consequences that seem to arise from providing binaries like the discussed need to move mod_ssl to a subproject. So they favour not having to deal with the consequences over providing binaries. As you stated yourself in a different mail on this subject, binaries are a convience not an expectation. > > And that I agree we need to make clear -everywhere- that > binaries are a convience, provided as a gift of one of the voulenteer project > members, not an expectation. Some users have had misassumptions on this front > in the not-to-distant past. Suggestions welcome. This is also my view. > on a few voices today, that it will not ship openssl binaries in particular. > How this differs from shipping libexpat, libz or libpcre binaries is beyond > my grasp, other than some recordkeeping. But if that's concensus become libpcre: As I took from earlier discussion on the list we have special requirements in libpcre and most stock libpcre will not work. Furthermore I think it is not possible to build a version of httpd that does not need libpcre. libz: Convenience on platforms where the OS does not deliver it (mostly windows?). As far as I can see this is only needed if you want to build mod_deflate. libexpat: Also convenience. Although XML seems to be only needed for mod_dav I am not quite sure if you can build httpd without libexpat. But there is a big difference to openssl: Providing these libraries does not result in similar legal pain as providing openssl and has no further consequences for the project that at least some people not like. Regards Rüdiger
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 11:07:51AM -0700, Justin Erenkrantz wrote: > On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: > >There are quite a few reasonable alternative strategies for dealing with > >that kind of scenario. Does the ASF have such a policy as a matter of > >course, regardless of the severity of such an action? > > As that hasn't happened yet, there is no set policy - except that we > would take it very seriously. Absolutely, I'm just hoping we'd explore things like licensing for nominal fee and so on. It hardly matters, it's for another day :-) One way in which it may be related though, is that in the past we've made some changes to openssl to get it to compile, and we wondered if that meant we'd have to put the resulting OpenSSL on tarball on a.o. We need to be careful about the patent-encumbant source code those tarballs contain too. Just something to watch out for. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? As that hasn't happened yet, there is no set policy - except that we would take it very seriously. We have had informal issues with potential copyright violations (all of which have been resolved amicably) - in those cases, we have tended to lock down the repositories fairly quickly while we investigate further. Unfortunately, copyrights aren't as straightforward as patents. So, *if* the ASF were to receive a formal notice regarding patent infringement, I would believe the relevant decision-making parties would be the Board, VP Legal, Counsel(s), and the relevant PMC Chair. -- justin
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 12:16:02PM -0500, William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > > > >Suffice it to say that even a cursory glance at a patents register > >would likely reveal many ludicrous patents which httpd may infringe. > > Yup; if the claimant to any such -legitimate- patent comes knocking, > it *will* be removed from svn and the project, in case you had any > doubts. There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
Colm MacCarthaigh wrote: Suffice it to say that even a cursory glance at a patents register would likely reveal many ludicrous patents which httpd may infringe. Yup; if the claimant to any such -legitimate- patent comes knocking, it *will* be removed from svn and the project, in case you had any doubts. Of course it's encumbant upon them to point this out to us, they know where to find us, and the infringing source code that documents the use. Bill
Re: AW: restructuring mod_ssl as an overlay
Jeff Trawick wrote: Just curious: does anybody in that boat actually think that anything we httpd-ers could do with packaging httpd (binaries, SSL,etc.) would conceivably compete with what our employers are providing? (I find that preposterous personally) rofl - no. I will say this; the people who are wildly waving their arms "no more binaries" are the same people who, surprise, haven't contributed binaries to httpd, at least not lately (little surprise). Yes this affects win32, and solaris pkg's and rpm's and a whole lot of other things in /dist/httpd/binaries/... There are some platforms (e.g. Linux) where you always have a compiler, and it seems linux biggots are the loudest "no binaries!" camp. Then there are others where installing a compiler varies between argrivating (solaris) to expensive. If it's not "encumbered", why not distribute a binary someone is willing to build, as opposed to arguing over the merits of them. Of -course- if nobody cares to contribute a binary for platform Foo, such is life. Now nearly every major open source project that supports OS/X and Win32 ships binaries for OS/X and Win32, and some folks happened to have built those, and others. Oooh... I almost forgot, platforms where compilers come along and are still aggrivating to use ;-) Encumbered; e.g. who's built a binary that is sitting in dist that has -lssl -lcrypto? I'm betting quite a few, I just don't feel like tearing that tree apart this month. I think this is getting absurd, Roy says "don't ship binaries" as one extreme reaction (not in a negative context, but an observation) and all the aolusers chime in. Either binaries float your boat or they don't. Isn't the httpd project about scratching your own itch? Anyways, I've come to the conclusion that the httpd project's decided, based on a few voices today, that it will not ship openssl binaries in particular. How this differs from shipping libexpat, libz or libpcre binaries is beyond my grasp, other than some recordkeeping. But if that's concensus become policy, then I'm happy to ditch any effort to provide win32 users mod_ssl. You folks really aren't worth this aggrivation. Bill
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 12:01:16PM -0500, William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > >What's next, do we start stripping patented methods from our tarball > >and making that available too? > > Uhm which patent *encumbered* methods? If I were to identify any or perform a patent search, that would make matters about a hundred times worse for all you US-based contributors, so I'm going to decline that particular honour ;-) Suffice it to say that even a cursory glance at a patents register would likely reveal many ludicrous patents which httpd may infringe. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
Colm MacCarthaigh wrote: What's next, do we start stripping patented methods from our tarball and making that available too? Uhm which patent *encumbered* methods?
Re: AW: restructuring mod_ssl as an overlay
On 6/8/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Plüm wrote:
>
>>Von: Joe Orton
>>I don't see why it's necessary for the ASF to be in
>>the business of distributing binaries; letting other people assume the
>>technical and legal responsibilites for doing that seems reasonable.
Ahhh, the preface of what Roy pointed out. Yes of course, since that's
what pays your salary I'm not terribly surprised...
tread lightly... very easy to be misinterpreted here, particularly by
random users...
("other people" being
the Red Hats, IBMs, Covalents, HPs, Suns etc etc.)
Just curious: does anybody in that boat actually think that anything
we httpd-ers could do with packaging httpd (binaries, SSL,etc.) would
conceivably compete with what our employers are providing? (I find
that preposterous personally)
(OTOH, if there is a solid business case for providing simply a binary
of httpd with suitable features that is known to work on at least some
handful of machines, please let me know ;) )
Re: AW: restructuring mod_ssl as an overlay
> -Ursprüngliche Nachricht- > Von: Colm MacCarthaigh > > > On Thu, Jun 08, 2006 at 08:16:48AM -0500, William A. Rowe, Jr. wrote: > > The group of people who concern me are not those in T-8, > they are those who > > live in jurisdictions where *they* would be breaking local > law by possessing > > crypto. Leave them a) in the backwaters / b) in fear / c) > in violation, or > > give them a silly httpd-2.2.x-no-ssl.tar.gz? The later > seems sane to me. > > The personal liabilites of users are not our concern. That's > strictly a > matter for users and their legal counsel. What's next, do we start And they would be a target hard to hit. US export controls are one fixed (complex) issue, but trying to deliver packages (whether source or binary) that do not violate laws in (almost) all contries over the world seems undoable to me. Apart from this I do not think that this should be our task. Regards Rüdiger
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 08:16:48AM -0500, William A. Rowe, Jr. wrote: > The group of people who concern me are not those in T-8, they are those who > live in jurisdictions where *they* would be breaking local law by possessing > crypto. Leave them a) in the backwaters / b) in fear / c) in violation, or > give them a silly httpd-2.2.x-no-ssl.tar.gz? The later seems sane to me. The personal liabilites of users are not our concern. That's strictly a matter for users and their legal counsel. What's next, do we start stripping patented methods from our tarball and making that available too? If the no-ssl tarballs are to be of any use it is in aiding the ASF in presenting a reasonable best-effort defence in relation to US export controls. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
Joe Orton wrote: If you think there is some group of users who want to be able to download the "crypto"-enabled httpd tarballs in $BANNEDCOUNTRY but refuse to do so because they don't want to violate US export regulations, then maybe that should be addressed separately. The group of people who concern me are not those in T-8, they are those who live in jurisdictions where *they* would be breaking local law by possessing crypto. Leave them a) in the backwaters / b) in fear / c) in violation, or give them a silly httpd-2.2.x-no-ssl.tar.gz? The later seems sane to me. This list of countries is rapidly shrinking, but remember even parts of western europe were subject to such laws not 10 years ago. would the SSL support have to be patched out of ab? Good point, I don't know that we ever notified BIX of that purpose. What about the SSL use in the LDAP code? Good point, I'm certain we didn't notify BIX of that purpose. And while we are at it, mod_ftp in incubation has the same issue with both explicit and implict FTP SSL. And we appreciate your raising these issues, as Roy's working hard to bring us into compliance with -our- relevant regulations, in this case, export controls. Bill
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 07:00:29AM -0500, William Rowe wrote: > Plüm wrote: > >>Von: Joe Orton > >>On Wed, Jun 07, 2006 at 02:03:33PM -0700, Roy T. Fielding wrote: > >>>Okay, let me put it in a different way. The alternatives are > >>> > >>>1) retain the status quo, forbid distributing ssl binaries, and > >>> include in our documentation that people in banned > >>> countries are not allowed to download httpd 2.x. > >> > >>This gets my vote. > > To prevent x number of people in the world from having a public discourse > via the web? We are discussing people, software users, not governments. I can't see how changing the documentation to comply with US export regulations will have any such effect. If you think there is some group of users who want to be able to download the "crypto"-enabled httpd tarballs in $BANNEDCOUNTRY but refuse to do so because they don't want to violate US export regulations, then maybe that should be addressed separately. I can't see that this would be anything other than a nightmare to attempt: would the SSL support have to be patched out of ab? What about the SSL use in the LDAP code? Regards, joe
Re: AW: restructuring mod_ssl as an overlay
Plüm wrote:
Von: Joe Orton
On Wed, Jun 07, 2006 at 02:03:33PM -0700, Roy T. Fielding wrote:
Okay, let me put it in a different way. The alternatives are
1) retain the status quo, forbid distributing ssl binaries, and
include in our documentation that people in banned
countries are not allowed to download httpd 2.x.
This gets my vote.
To prevent x number of people in the world from having a public discourse
via the web? We are discussing people, software users, not governments.
I'm glad to hear your vote though. Now I'll keep watching the list for
the recent RMs' and binary packagers' opinions on the matter.
Provided every member of this project agrees in general that information
and software distribution is good, and all politics aside, there's no reason
not to ensure broadest possible adoption of our tarballs sans crypto.
I don't see why it's necessary for the ASF to be in
the business of distributing binaries; letting other people assume the
technical and legal responsibilites for doing that seems reasonable.
Ahhh, the preface of what Roy pointed out. Yes of course, since that's
what pays your salary I'm not terribly surprised... ("other people" being
the Red Hats, IBMs, Covalents, HPs, Suns etc etc.) Let's face it, we
(collectively, as people paid to work within httpd's sphere of influence)
are supporting more and more customers who are -not- running some official
vendor package from our employeers, but rather supporting more who have
deployed an ASF package.
I actually think that a) says good things about us, and b) With continuing
vendor / packaging / configuration flaws, who blames them?
Of course, hrm... rather pays my paycheck, too. Wonder why on earth I've
been putting up binaries at httpd.apache.org or advocating for resolution ;-?
Certainly it isn't to sell more copies of our companies' bundle. Perhaps, it's
about overall project adoption, and giving back the favor of something that
I spent several hundred hours of voulenteer time 'hacking at', because I needed
to get up to speed on the technology for colocated unix, and had a few Win32
boxes sitting in front of me. It happened to mostly work when I started using
it, learned it, deployed my customer's sites on unix after validating them in
Win32. Oh - and fixed some things that didn't make sense.
Perhaps also, because there will always be room for vendor packages with all
of the associated QA and production release control, that doesn't altogether
exist in naked open source. We should be about moving forward, and there
is your 'vendors and others' nitch ... let them (well, yes some of -us- wearing
our other hats) worry about the technical nits like production quality.
At home here in the states, just consider the impact of wireless, shared
cable segements and other public access points. HTTP is a wonderful thing,
easy to debug, quite transparent. In those environments, too transparent.
If more secured and user-identifing websites are encrypted, this is a net
win to the end users, and our webserver administrators.
Ahh but of course, you are talking about -windows- binaries that we should
not produce. Of course, that would appear consistent with company policy.
And I see a few other binaries released recently, but oddly enough, no files
owned by jorton. Perhaps ... while you scratch your itch, those who keep
filling that /dist/httpd/binaries/ tree will scratch theirs?
Let me offer that we've done a bad job mopping up insecure versions out of
the /dist/httpd/binaries/ tree and should decide on a method of reaping
stale packages. And that I agree we need to make clear -everywhere- that
binaries are a convience, provided as a gift of one of the voulenteer project
members, not an expectation. Some users have had misassumptions on this front
in the not-to-distant past. Suggestions welcome.
The documentation work necessary would be greater if mod_ssl is split
into a separate package, and having mod_ssl in the tree is one of the
compelling features of 2.x anyway.
Yes, of course. Minor nits - but import to close. After all, we clearly
documented how to migrated from 2.0 to 2.2.
Provided that we do not find a solution that allows us to keep mod_ssl inside
the httpd tree (having an additional non ssl source tar ball that has the
modules/ssl directory removed during rolling the package seems to be
acceptable to me (not knowing if this would solve our legal pains))
I agree with Joe.
Roy's pointed out, IIUC, that notification was provided for cvs (erm, the svn
wasn't yet, was it? Big todo and good reason to collect such datum in a central
repository of crypto-locations at the ASF, since this sort of thing will be
inevitably missed in refactoring, e.g. the cvs->svn transition) and that won't
be so critical. Someone can check out svn in pieces. They can grab a tarball,
instead.
So I don't think that factoring it out-of-the-tree is the right solution.
Providing an alternate tarball from our curr
