Date: Sun, 28 Jan 1996 22:46:32 -0700 From: Nate Williams <nate@sri.MT.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: nate@sri.MT.net (Nate Williams), Hackers@freebsd.org Subject: Re: Unzip for package tools (was re: FBSD 2.1) Message-ID: <199601290546.WAA07266@rocky.sri.MT.net> In-Reply-To: <199601290548.QAA09561@genesis.atrad.adelaide.edu.au> References: <199601290532.WAA07213@rocky.sri.MT.net> <199601290548.QAA09561@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Obviously, this breaks down for things development tools (gcc and > > friends) and other parts of the system, but those aren't necessary to > > build a running system for the most part. (Actually, ld.so is both > > GPL'd and necessary which is too bad unless you want to build a static > > only system). > > Not to be rude, but I can't see the "problem scenario" being at all > realistic. It's not only realistic, it's happening. :) > We have a vendor who will take FreeBSD, remove the networking > support, remove the C compiler from their distribution, rebuild everything > static, hunt down and dike out everything else even vaguely GPLish, and > not rework their installation tools? Why do you have to remove the networking support? It's also quite easy to remove everything GPL'ish from the system by simpling removing /usr/src/gnu from the build tree. > > Again, it's not a super-critical problem, but it's also not the best of > > solutions either. > > It's a lot better than the current situation, which depends, amusingly > enough, on the GPL'd tar and gzip. Ahh, but tar can be replaced easily with a PD version, or BSD pax it it's that critical. Heck, Andy Tanenbaum already donated the version of tar in minix if we want it. Gzip is another thing altogether, but assuming you're making your own custom release you can easily replace gzip with compress. Also, assuming the vendor is doing a custom release, the initial install is the easy part. The after-sale support is where the difficulties lie. I do agree that the current tools are using GPL code, but I'd like to avoid if possible bringing in code with similar restrictions. However, it may not be possible. :( (BTW - I was one of the original proponents of using zip, and still think it's by far the best solution available at the present time. I just wish we could get a more 'free' ZIP library.) Oh, and as far as doing the ZIP api, I'm not be the right person for the job anymore. I signed a psuedo-NDA from Sun for the Java stuff, and it turns out that Sun has implemented a ZIP API used in Java (for storing the class libraries) which I now have the source for. There is the possibility of 'contamination' which will preclude me from actually authoring the ZIP api library. :( Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601290546.WAA07266>