Wesley W. Terpstra wrote: > I am developing a very CPU-intensive, open-source error-correcting code. > > The intention of this code is that you can split a large (> 5GB) > file across multiple packets. Whenever you receive enough packets that > their combined size = the file size, you can decode the packets to > recover the file, regardless of which packets you get. Sounds very interesting; there would be a ton of applications for that. Thanks in advance for deciding to make it Open Source / Free Software. > This means a lot of calculation over gigabytes worth of data. > Therefore, speed of utmost importance in this application. > > The project itself includes an ocaml compiler (derived from fftw) which > generates C code to perform various types of Fast Galois Transforms. Some > of the output C code uses SSE2 exclusively. This C code is then compiled > and linked in with the other C sources that make up the application. Interesting approach. > Now, on to the dilemma: icc produces object files which run ~2* faster > than the object files produced by gcc when SSE2 is used. (The non-SSE2 > versions are also faster, but so significantly) Both gcc and icc can > compile the generated C files. My University will shortly own a licence > for icc which allows us to distribute binaries. Whether your university owns a license or not does not really affect Debian. icc cannot be included in Debian main. > So, when it comes time to release this and include it in a .deb, I ask > myself: what would happen if I included (with the C source and ocaml > compiler) some precompiled object files for i386? As long as the build > target is i386, these object files could be linked in instead of using > gcc to produce (slower) object files. This would mean a 2* speedup for > users, which is vital in order to reach line-speed. Other platforms > recompile as normal. 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. 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. What you can do is this: * 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.) (Steps below this point are optional.) * Make it easy for people to rebuild using icc. See the openoffice.org packages for an example; they contain support for rebuilding using a non-free JDK based on a flag in DEB_BUILD_OPTIONS. * 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. > On the other hand, is this still open source? It is not particularly meaningful to talk about compiled binaries being Open Source or not. Your program would obviously be Open Source, since it would be available under the GPL; it is acceptable *under the GPL* to provide binaries compiled with non-free compilers, unless the resulting compiled binary is somehow derivative of a non-free work that is not an OS component. In the end, if people want to exercise their rights under the GPL, they will want the source, not the binaries, and you are supplying that source alongside the binaries, which satisfies the GPL. > Is this allowed by policy? > Can this go into main? No. Packages in main must be built using only other packages in main; icc is not in main, so you can't ship an icc-built package in main. > 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. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature