Date: Mon, 19 Oct 1998 10:11:23 -0600 From: Brett Glass <brett@lariat.org> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: Producing non-GPLed tools for FreeBSD Message-ID: <4.1.19981019100241.0677ace0@mail.lariat.org> In-Reply-To: <199810190637.XAA16847@dingo.cdrom.com> References: <Your message of "Mon, 19 Oct 1998 00:23:11 MDT." <4.1.19981019000937.06571220@mail.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:37 PM 10/18/98 -0700, Mike Smith wrote: >As has been mentioned previously, the ELF object format is copiously >described by the ELF documentation, sources for which have been posted >here several times. Unfortunately, I'm not a full-time subscriber to "hackers," so I haven't seen them. Could you send a pointer or two off-list? >> Unfortunately, when I looked for the source in the 3.0-current tree, I >> discovered, to my horror, that both programs were in the /src/gnu >> subdirectory. This creates a problem. Technically, if I use GPLed source, I >> must GPL the resulting product. And both as(1) and ld(1) are GPLed. > >Binutils uses libbfd, which unfortunately is licensed under the GPL, >not the LGPL. What sorts of routines does libbfd contain? (I'm intentionally not looking at stuff until I can determine that I won't be "contaminated" by doing so.) >> Thus, without descriptions of the output formats that do not require me to >> read the source code, I can't produce tools that I am 100% sure can be >> licensed under the Berkeley license and/or sold as commercial products. > >Since such documentation exists, you're safe here. You can also >consult with the relevant experts, who can give you uninfected advice. That would be useful. What about the intermediate formats, though? In order to link statically with library files or third party code, I'll need to be able to deal with the object format. >To be quite honest, if all you're doing when you look at the code is >reverse-engineering the interface(s), it's unlikely that your >derived specification will be subject to the GPL. Specification, no. But more code...? Hard to tell. I'd rather make sure I'm "clean." >If you obtain this >specification without looking at the code (eg. by conversing with >someone else who has done the work) then you're almost certainly clean >(this is the standrd 'clean room' methodology). That's what I'd like to do. Better still, it'd be nice if there were some docs.... Even Microsoft documents things like its object format and register models! That's why I was so startled to find out that there was no way to get this information for FreeBSD without reading GPLed code. It sounds as if a non-GPLed linker (without debugging support in the earliest version) would be the first step. If I can do a statically linked "hello world" and then a dynamically linked one (I don't want to use numbered syscalls, since this mechanism is deprecated), I can then make an assembler. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19981019100241.0677ace0>