Wesley W. Terpstra wrote: > Since there's one GPL question left, I am still posting to debian-legal. > The legal question is marked ********** for those who want to skip the rest. > > On Mon, Oct 18, 2004 at 11:49:56AM -0700, Josh Triplett wrote: >>Whether your university owns a license or not does not really affect >>Debian. icc cannot be included in Debian main. > > No, but debian can distribute precompiled object files (legally). > The binaries I meant were the object files. I understood that. Debian can _legally_ distribute the files (which is based on whether the GPL allows it), just as Debian can legally distribute everything in contrib and non-free (or it would not be there). However, this does not mean Debian will ship it in main. >>Keep in mind that if your algorithm is as good as it sounds, it will be >>around for a long time. Even if a GCC-compiled version can't achieve >>line-speed right now, if all it needs is a 2x speedup, normal increases >>in computer technology will provide that soon enough. > > True enough, but as processors get faster, so does bandwidth. > I expect that ultimately, it will always need to be as fast as possible. Possibly; however, I think bandwidth grows far slower than CPU speed and overall system power. I do understand your concern, though. >>Consider this: any package with non-free Build-Depends that aren't >>strictly required at runtime could take this approach, by shipping >>precompiled files. For example, this has come up several times with >>Java packages that tried to just ship a (Sun/Blackdown-compiled) .jar >>file in the source package. The answer here is the same: you can't ship >>compiled files to avoid having a non-free build-depends (and shouldn't >>ship compiled files at all, even if they were compiled with a Free >>compiler); the package should always be built from source. > > That is a good argument; thank you. > >>* Upload a package to main which builds using GCC. (As a side note, you >>might check to see if GCC 3.4/3.5 produces significantly better code.) > > gcc-3.3 is not an issue; it ICEs. > gcc-3.4.2 is the version I was referring to. 1) Have you submitted a bug report on 3.3? 2) Have you tried 3.5? A great deal of work has gone into making 3.5 far better at generating optimized code, particularly with vectorization and advanced instruction sets; much of this came about due to the merging of the tree-ssa branch. I don't know that it would be 2x faster, but I wouldn't be surprised if it was quite measurably faster. >>* Supply icc-built packages either on your people.debian.org site or in >>contrib; if the latter, you need to use a different package name and >>conflict with the gcc-built package in main. > > Josselin Mouette <joss@debian.org> said: > >>If you really want to distribute a package built with icc, you should >>make a separate package in the contrib section, and have it conflict >>with the package in main. > > Yes, this sounds like a good plan. > > Put the normal gcc version rsgt in main where the i386 deb has: > Recommends: rsgt-icc You cannot put a Recommends from main to non-main; the strongest relationship you can declare is Suggests. > rsgt-icc sits in contrib, completely built by icc (not just some .o s) > > Conflicts: rsgt > Provides: rsgt > Replaces: rsgt Right. > If an i386 user (with contrib sourced) runs 'apt-get install rsgt' > will that make apt install rsgt-icc? That's what I hope to accomplish. No, I don't believe it will. That's why when packages change names, it is common to still produce a binary package with the old name, which does nothing except depend on the new package. That doesn't help you in this case, of course. I think all you can do is add the Suggests: rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other, and provide a brief explanation in the README.Debian of both packages. > (PS. rsgt is not the final name) Heh; naming is tricky but fun. What does "rsgt" stand for? > ************************************************************************** > For it to sit in contrib, would I have to include the source code in contrib > as well? Or would the fact that the source code was in main already satisfy > the GPL requirement of source availability? Packages in contrib must still be Free Software, which means they must have source available. I think this is a Policy problem, though I could be wrong. The only thing packages in contrib can do that packages in main can't is declare a Depends:, Build-Depends:, or Recommends: relationship with a non-main package; they must still follow Policy, and they must still be Free Software. I don't know that it is acceptable for the source to be in a separate source package. You should also talk with the Debian OpenOffice.org team about this; they were in discussion about how to provide the contrib openoffice.org-java package (built with a non-free JDK) without needing a separate (huge) source package in contrib. As for the GPL issue, this is a difficult question: on the one hand, CD vendors and other distributors include contrib and non-free software at their own risk; on the other hand, the idea of the source package being available only in main is difficult. You would certainly be complying with the spirit of the GPL, but I don't know if you would be complying with the letter. GPL clause 3 is the relevant section; of that, Debian always ignores the "offer" option in GPL 3b and 3c, because 3b requires that the offer be "valid for at least three years" which Debian cannot guarantee, and 3c is only valid for non-commercial distribution. So looking at the rest of GPL clause 3: > 3. You may copy and distribute the Program (or a work based on it, > under Section 2) in object code or executable form under the terms of > Sections 1 and 2 above provided that you also do one of the following: > > a) Accompany it with the complete corresponding machine-readable > source code, which must be distributed under the terms of Sections > 1 and 2 above on a medium customarily used for software interchange; or, [snip 3b and 3c] [snip OS exception] > > If distribution of executable or object code is made by offering > access to copy from a designated place, then offering equivalent > access to copy the source code from the same place counts as > distribution of the source code, even though third parties are not > compelled to copy the source along with the object code. So the question is whether a source package in main "accompanies" a binary package in contrib, and/or whether "equivalent access" is offered. This is certainly questionable. It would also depend on mirroring; for example, if contrib were ever moved to a different server (which has been debated in the past), this would become clearly false. My advice would be this: unless the source is incredibly huge (such as with OO.o), then I don't think saving a few tens of MB is worth dealing with the questions and complexities this raises. >>>PS. I will provide the source code to anyone who requests it, but not yet >>>under the GPL. Only after I publish a paper about the algorithm will the >>>code be released under the GPL. >> >>Keep in mind that FFTW is GPLed, so unless you have made other >>arrangements with its copyright holders, you need to refrain from >>supplying the code or binaries to anyone unless under the GPL. > > Oh, that's a good point. > I withdrawl my offer of private pre-release. > You can only have a copy after I publish. ;) :) > Thank you for your detailed explanation and answer. No problem. I look forward to reading your algorithm and trying out your software. Again, thanks in advance for your generous contribution to Free Software. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature