Re: Is this better for tomsrtbt?
here with bzip2, I get 51,200 bytes for BSD, GPL, and LGPL, tarred. That should be acceptable for a TRB distribution archive, no? It breaks one of the primary design goals, which is that the tarball can be created from the floppy and vice versa in a completely symetrical way, because there is no distribution archive content that isn't available on the floppy, currently, which is desirable. So, even if I do it the way you are suggesting, it means that it is illegal to make a copy of a any tomsrtbt floppy and give it to someone. Adding the 51K to the archive is, given how tomsrtbt is used, irrelevant, and adding it to the floppy image itself is problematic at best. If my download link is the only way I distribute it, and if my download link has the tarball and the licenses, then I am in fact distributing the licenses with the programs, the risc of non compliance is with anyone who then might RE-distribute it thinking they could create the tarball from the floppy and then distribute that tarball without the licenses. I think I am OK on that risk with just a one-line notice pointing out that I have distributed X licenses along with the distribution (and all the mirrors do the same, that is, they have those top level files in the SAME ARCHIVE as the tarball), and that if you re-distribute it, you had better do the same. I can just picture a user fest where they have a box of tomsrtbt floppies and a box of license floppies and they clip one of each together with a paperclip in order to give you tomsrtbt, and then evey time they hand such a bundle to a user group attendee that person hands back the licencse floppy, having received it. Maybe I should distribute it that way, as a 2 diskette package, where the licenses are on diskette 2? support, and list it as a source tarball. The advantage is that by Unifying the makefiles into one source tarball that can be build with one 'make' command is in the plan. I am getting married on 5/7, and have already a mortgage and 2 children (we've been engaged for 8 years), so this is not going to be something that happens quickly. I am going to focus any short term time on plugging any non-compliant behaviour. Now, again, as I read it, if I provide an http or ftp directory, which contains 10 files, and one of those has all the licenses, and one is the tarball that makes the floppy, and one is an html file that clearly lists both and explains what they are and why, then *I* am in compliance with: ... give any other recipients of the Program a copy of this License along with the Program. Now, if someone chooses to copy 1 from column A and 0 from column B to their system, they are fine, unless and until they decide to redistribute it. I will make sure all the licenses are distributed clearly with the program (that is, any place you have an opportunity to get the program from me will also have the licenses shown in the same package or directory), and I will add notices to the affect that the tomsrtbt floppy *by itself* cannot be copied or distributed, because it does not include the license. Heck, I'll put a prompt right in the clone.s script. And if it really becomes necessary to replace emacs with 2^17 bytes of licenses on the actual floppy, there will be a certain balanced irony. And I'll still have vi. -Tom
RE: Is this better for tomsrtbt?
From: Tom Oehser [SMTP:[EMAIL PROTECTED]] Now, again, as I read it, if I provide an http or ftp directory, which contains 10 files, and one of those has all the licenses, and one is the tarball that makes the floppy, and one is an html file that clearly lists both and explains what they are and why, then *I* am in compliance with: [DJW:] The problem here is that you can almost guarantee that people will deep link to the floppy constructing tarball, defeating the whole purpose of the requirements that the licence accompany the software, i.e. to ensure that every recipient is fully informed of the licence. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS.
Re: Is this better for tomsrtbt?
on Wed, Apr 25, 2001 at 07:44:56AM -0400, Tom Oehser ([EMAIL PROTECTED]) wrote: here with bzip2, I get 51,200 bytes for BSD, GPL, and LGPL, tarred. That should be acceptable for a TRB distribution archive, no? It breaks one of the primary design goals, which is that the tarball can be created from the floppy and vice versa in a completely symmetrical way, because there is no distribution archive content that isn't available on the floppy, currently, which is desirable. So, even if I do it the way you are suggesting, it means that it is illegal to make a copy of a any tomsrtbt floppy and give it to someone. Adding the 51K to the archive is, given how tomsrtbt is used, irrelevant, and adding it to the floppy image itself is problematic at best. Technical aspects are understood. Even without knowing or understanding the technical wizardry involved in making tomsrtbt, I'm damned impressed. It's a featureful toolkit. Note, however, that technical and legal requirements don't always mesh. And in a world governed by both, there may be two masters to serve. The out, if you will, is that you aren't responsible for enforcing downstream compliance with the GPL (section 6), nor, I believe, the LGPL, or BSD, nor are downstream distributors answerable to your compliance status (GPL section 4). Breaking technical symmetry by distributing an archive with licenses, but creating a floppy (and then from it an archive) without them, may be a non-symmetric, but acceptable, hack. Notice on the floppy that distribution requires inclusion of the license(s) (electronic or hardcopy form should work) may be sufficient or recommended. I don't see casual distribution as the concern in any event, it's large-scale distribution which matters (e.g.: mirror sites, inclusion in other packages such as the LinuxCare BBC). Another hack might be to wrap the tarball itself in another tarball containing the licenses, a README, and the tomsrtbt tarball. Which leaves your symmetry problem intact by encapsulating it in a larger problem. If my download link is the only way I distribute it, and if my download link has the tarball and the licenses, then I am in fact distributing the licenses with the programs, This is your interpretation, RMS and/or the copyright holder may feel differently. A related situation is the Debian distribution, in which several licenses, including the GPL, LGPL, BSD, and Artistic License, are distributed as a separate archive than the software to which they apply. Linkage is via the Debian packaging system, or so the argument goes. My understanding is that this is acceptable to RMS, he'd raised the issue at some point last year. So you might be right. It seems clear to me that the licenses should be prominently included on the archive site, with instructions that both tomsrtbt *and* the licenses need to be distributed, if this route is taken. the risk of non-compliance is with anyone who then might RE-distribute it thinking they could create the tarball from the floppy and then distribute that tarball without the licenses. I think I am OK on that risk with just a one-line notice pointing out that I have distributed X licenses along with the distribution (and all the mirrors do the same, that is, they have those top level files in the SAME ARCHIVE as the tarball), Note, as above, third party compliance isn't your concern under the three licenses in question. and that if you re-distribute it, you had better do the same. I can just picture a user fest where they have a box of tomsrtbt floppies and a box of license floppies and they clip one of each together with a paperclip in order to give you tomsrtbt, and then every time they hand such a bundle to a user group attendee that person hands back the license floppy, having received it. Maybe I should distribute it that way, as a 2 diskette package, where the licenses are on diskette 2? That's a thought. ...or very small print on a floppy label ;-) Here's a thought for a niche business: floppy disk envelopes printed with readable copies of the Debian common-licenses: GPL, LGPL, BSD, Artistic, to satisfy licensing requirements. Probably as a fold-out of some sort. support, and list it as a source tarball. The advantage is that by Unifying the makefiles into one source tarball that can be build with one 'make' command is in the plan. I am getting married on 5/7, and have already a mortgage and 2 children (we've been engaged for 8 years), so this is not going to be something that happens quickly. I am going to focus any short term time on plugging any non-compliant behavior. The standard for GPL is that [t]he source code for a work means the preferred form of the work for making modifications to itplus the scripts used to control compilation and installation of the executable -- your existing build process, whatever it is, is the preferred form, and should be sufficient, if not
Re: Is this better for tomsrtbt?
Ok, thanks. By the way, I have as a result of these discussions made a bunch of enhancements to http://www.toms.net/rb/license.html, which is pretty difficult to accidentally avoid at this point, and which will be on all the mirrors tomorrow. I added a key of what license goes with which file for the whole contents, all the relevent licenses, and a few other things. It is now grown over 100K, I am happy to announce. -Tom
Re: Is this better for tomsrtbt?
about 2 years. Now, guess what libc5.so.5.4.13 file is currently in use on the MuLinux distribution? Yep, the 432,684 byte one I created about 2 years ago. Now, the author of MuLinux does *not* mention that he used This is the foundation of LGPL which libc uses. They have the right to do this and you can not stop them from doing that as long as you are using (L)GPL:ed software and make modifications to them. But you can add a restriction, so everyone has to mention you. And IIRC no Copyright notice may be removed. Of course, I could just be a prick and ask him for the source code. I don't in point of fact believe that maintainers of distributions that grab binaries are actually keeping track of where the binaries came from. I did not in fact make changes to the source, all I did was play with Makefiles and config.h files and compiler options and stripping tools, so he could in fact just provide me any boilerplate libc5.so.5.4.13 archive and it would be the source that qualifies as 'the program', but, unless he in fact is tracking where each one of the binaries came from, how does he know that? I guess the config opts dont belong to that. I am distributing the source I built it with with it. Am I required to provide the *exact* makefile and config.h and compile settings that would reproduce the 432,684 object? I can't do that, I have since improved it down to 416,361, and I am *NOT* keeping an RCS log of every single config.h and CCFLAGS condition that existed!!! Did you try # strip -s -R .note -R .comment libc.so.5 It works for me. And no, I am not keeping logs. (Did you ever meet a programmer who did not hate to write docu?) For that matter, the GPL requires me to provide source for 3 years after I distribute something. Now, it has been 2 years since I distributed it. He is redistributing it now. What if, 2 years from now, someone asks him for the source! *He* is required to provide it, after all, it is within the 3 years since *he* distributed it. But, *I* am no longer required to have kept it around. So, if he doesn't bother to get the source code from where he got the binaries within 3 years, he may be stuck in a situation where he is breaking the GPL and I am past the window where I have to help him. What about versions? If I distributed the "ls" program from fileutils version 3.13 2 years ago, do I have to be able to provide the source to exactly 3.13 now, or is 3.14 still 'the program'? I assume I have to be able to provide the source to *exactly* what I distributed 2 years ago. Now, it adds *enormously* to this if someone is *redistributing* that, and they *didn't* get the source code from me 2 years ago. It means that if someone wants the source from them, they'll either say 'sorry, I dunno where it came from' or they'll say 'maybe it came from tomsrtbt or slackware or something, ask them'. -Tom I hope versions are ok, but I usually add the source. And if I bring out a new version, I delete the old. -mirabilos
Re: Is this better for tomsrtbt?
Tom Oehser [EMAIL PROTECTED] What I don't like is other people just copying the *actual binary* without giving any credit or acknoledgement that *they* don't want to bother to compile it *themselves*. As long as they mention where they got it, I'm fine with it. So, in the case above, am I required not to add the 'give credit and mention where you got it' clause to the binary object, even if I make the source code available without any such restriction? Yes. That would be in violation of Section 2b of the GPL. The GPL doesn't really clarify this, it is, after all, aiming at the source code, and there is probably no consideration that anyone would *care* about a particular binary compile output. Compiling a program into object code is certainly forming a derivative work, and thus it falls under Section 2. The GPL does not need to enumerate every different way to form derivative works in order for it to apply to them. Also, if you look at the language in the first line of Section 3, it is clear that the GPL considers object code to fall under Section 2. Now, I can *definitely* apply this restriction to all the scripts and Luas that I wrote from scratch, *maybe* apply it to the agglomeration and the arrangement (such as using a very small gzipped root and bzip2ed /usr, is that copyrightable?) The idea of compressing filesystems? No, as copyright applies to expressions and not ideas. The actual filesystems of course are copyrightable, but then they are derivative of the works they contain, and you will have to follow the GPL. and *maybe* apply it to my versions of the documents and man pages. It is *possible* that I can apply it to binary objects where I am making the program *in source* available *without* restriction, but I dunno from reading the licenses. Are you talking about the GPL? The GPL states very explicitly in Section 2b that derived works must be distributed under the terms of the GPL. There is no provision for extra restrictions. But I can *ABSOLUTELY* make it clear that this is my desire, want, and expectation, to the fullest extent legally available to me. Which, under the GPL, is nil, unless you can find a law requiring attribution. Don't pretend that this "desire, want, and expectation" is part of the license, though. IANAL. That is what I'm getting at, in my license- "as far as legally possible, if you reuse ANY of this, you must give credit to the source". --
Re: Is this better for tomsrtbt?
Did you add your own copyright notice to these programs? I'm digging around for copyright notices, they're a bit scarce You ought to be covered under GPL in this case. The GPL says: 4. You may not ... sublicense ... and: 6. ... You may not impose any further restrictions ... It is pretty clear that I *cannot* require my own copyright be carried. Incidentally, where's TRBs sources? It depends which sources you want, give me a specific component. For example, if you want the 'dd' on tomsrtbt, my preference is that you get it directly from me, either ftp, http, or email; given both that I have modified it and that the 3.13 version of fileutils would be hard to find otherwise. If you want the 'lilo', for example, on tomsrtbt, my preference is that you download it from the canonical archive, as I have not patched it and it is current; but if you want it directly from me I can provide it via either http, ftp, or email. There is no unified source tree or combined build process for tomsrtbt, for the purpose of providing the source code each component is a seperate entity, and given that there does not exist a unified source tree, I can't give it to you. Let me know any particular source you want and how you would prefer to get it. ...and have you mentioned this to the MuLinux author? A lot of license enforcement starts out with "say, I noticed" type letters. The point is, when I distributed it 2 years ago, I did *not* have such a stated requirement. I really don't care enough in this case to pursue it. I want to prevent people from taking the binary objects and copying them into their own mini distributions without mentioning where they got them. If you're modifying works based under the GPL and BSD licenses, the existing licenses give you this right. I think you're asking for what you already have. Nope. They are free to redistribute the binaries without mentioning anything. Moreover, they are free under 3(c) to answer a request for the source code by referring the requestor to me. (Though I'm a little unclear about the 3-year thing. What happens if they are counting on 3(c), and my 3-year period lapses, well, *his* 3 year period hasn't lapsed, so the implication is that at the end of the 3rd year, he had better get the source while he still can... -Tom
Re: Is this better for tomsrtbt?
What is it you want to protect? I'll give you an example. My bootdisk currently includes a libc5.so.5.4.13 that I have down to only 416,361 bytes. More than 2 years ago, back in October of 1998, I had it only down to 432,684 bytes. I havn't distributed that binary libc.so for about 2 years. Now, guess what libc5.so.5.4.13 file is currently in use on the MuLinux distribution? Yep, the 432,684 byte one I created about 2 years ago. Now, the author of MuLinux does *not* mention that he used a bunch (more than just this) of stuff directly out of tomsrtbt, he did *not* ever contact me about how to build it that small, and I would be curious in the abstract to know what he would do if someone asked him for the source code sufficient to rebuild it. Now, it is within 3 years of when I distributed it- so he could still ask me for the source to the libc I distributed 2 years ago- and he does mention tomsrtbt positively as another minilinux to check out- but I think it is fair that I require that users of anything I *can* require this of, give me credit. (Note: this is not meant to single out MuLinux, there are others doing the same thing). At a MINIMUM, it is only fair that a user of one of these know where the stuff came from, after all, what if I stuck a trojan in it? I really want any object file created by a compiler on my machine to be so documented. It isn't fair that users of these distributions are allowed to have the impression that their distribution author actually built it. In fact, I *do* build everything on tomsrtbt directly from source, and I *don't* crib stuff without giving fair credit to the authors and others who do the work. I want to prevent people from taking the binary objects and copying them into their own mini distributions without mentioning where they got them. I guess one question I have is, suppose I have on my web site: hello.c and a.out Where hello.c is a GPL program and a.out is an object file that I artistically chose to use "-m386 -O2 -fomit-frame-pointer -fno-strength-reduce", stripped with ELF-Tiny elf object utilities, used an older GCC to save a few bytes, and cetera. GPL prevents me from adding restrictions to 'the program'. Well, I am not restricting it- it is right there- "hello.c" is the program- and I'm glad to include the *instructions* for how to build it the smallest way- and the intent of the GPL is clearly to protect the freedom of the source. What I don't like is other people just copying the *actual binary* without giving any credit or acknoledgement that *they* don't want to bother to compile it *themselves*. As long as they mention where they got it, I'm fine with it. So, in the case above, am I required not to add the 'give credit and mention where you got it' clause to the binary object, even if I make the source code available without any such restriction? The GPL doesn't really clarify this, it is, after all, aiming at the source code, and there is probably no consideration that anyone would *care* about a particular binary compile output. Now, I can *definitely* apply this restriction to all the scripts and Luas that I wrote from scratch, *maybe* apply it to the agglomeration and the arrangement (such as using a very small gzipped root and bzip2ed /usr, is that copyrightable?) and *maybe* apply it to my versions of the documents and man pages. It is *possible* that I can apply it to binary objects where I am making the program *in source* available *without* restriction, but I dunno from reading the licenses. But I can *ABSOLUTELY* make it clear that this is my desire, want, and expectation, to the fullest extent legally available to me. That is what I'm getting at, in my license- "as far as legally possible, if you reuse ANY of this, you must give credit to the source". -Tom
