[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reproducible, precompiled .o files: what say policy+gpl?

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


> 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

Reply to: