Re: firmware status for eagle-usb-*

[Mike Hommey]

On Tue, Oct 19, 2004 at 05:46:07PM -0700, Josh Triplett wrote:
> This is clearly not appropriate; it is not "perfectly reasonable" to
> install a driver package without the firmware, any more than it is
> reasonable to install a dynamically-linked binary without its shared
> library dependencies.  In both cases, the functionality is limited to
> simply imforming the user that a necessary component was not installed.

Except in the case of a driver that also works on devices that have the
firmware embedded in a ROM chip.

Mike

Re: Is this software really GPL?

[Raul Miller]

On Tue, Oct 19, 2004 at 08:44:46PM -0400, Glenn Maynard wrote:
> It's misleading.

Yes.

There are lawyers who will express things in a misleading fashion if
they think that's in the best interests of their clients, and if they
think they will not get in legal trouble for doing so.

-- 
Raul

Re: Is this software really GPL?

[Josh Triplett]

Glenn Maynard wrote:
> On Tue, Oct 19, 2004 at 08:25:07PM -0400, Raul Miller wrote:
>>>"You cannot install, or ask your customer to install a GPL version of
>>>OpenQM and then install your own product unless that product is also
>>>delivered to the user under GPL or an approved variant."
>>
>>This would be accurate for the case that "your own product" incorporates
>>sources from OpenQM.
>>
>>Otherwise, it's irrelevant.
> 
> It's misleading.  I can install OpenQM--or ask customers to--and then
> install whatever I want.  If it's a library, I can't link against it
> with GPL-incompatible code, but that has nothing to do with how it was
> installed or what I ask people to do.

I suspect their intent is to make it clear that you can't weasel out of
the GPL's requirements by simply providing your application separately
from the GPLed OpenQM, which is true.  I agree that this, like many
statements on their pages, are badly misleading; on the other hand,
there are several things on their page that sound like they actually
have a better understanding of the GPL than most, such as their explicit
note that GPL != non-commercial, as well as a statement that when
someone is "violating the GPL", what they are really violating is
copyright law, since they are distributing without a license.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Re: Is this software really GPL?

[Glenn Maynard]

On Tue, Oct 19, 2004 at 08:25:07PM -0400, Raul Miller wrote:
> > "You cannot install, or ask your customer to install a GPL version of
> > OpenQM and then install your own product unless that product is also
> > delivered to the user under GPL or an approved variant."
> 
> This would be accurate for the case that "your own product" incorporates
> sources from OpenQM.
> 
> Otherwise, it's irrelevant.

It's misleading.  I can install OpenQM--or ask customers to--and then
install whatever I want.  If it's a library, I can't link against it
with GPL-incompatible code, but that has nothing to do with how it was
installed or what I ask people to do.

> > "If you are going to distribute multiple copies of openQM within your
> > company, you will probably need a commercially licensed version of
> > openQM."
> 
> This one is wierd -- but it might be true if some other assumptions
> are held to be the case (such as: you don't want to provide source code
> within your company, perhaps for policy reasons).
> 
> "probably" is a weasel word.

The statement is badly misleading.  It doesn't matter much to me if it
can be interpreted in a true way, since the only thing I really care about
here is the spread of confusion about the GPL.

-- 
Glenn Maynard

Re: firmware status for eagle-usb-*

[Josh Triplett]

Marco d'Itri wrote:
> - notwithstanding the disagreement of a few people here, even if
>   post-sarge eagle-usb-data will have to be moved to non-free, there is
>   nothing in our policy which prevents to downgrade the hard dependency
>   to a suggestion, to be able to keep shipping the free driver in main

There is most certainly a requirement in Policy to correctly express the
dependencies of a package, and consequently, to not allow the package in
main.

First, from Policy section 2.2.1, "The main section":
>  In addition, the packages in _main_
> * must not require a package outside of _main_ for compilation or
>   execution (thus, the package must not declare a "Depends",
>   "Recommends", or "Build-Depends" relationship on a non-_main_
>   package),

So if the appropriate dependency from the driver to the firmware is
Depends, Recommends, or Build-Depends, then the driver cannot be in main.

Now, for the idea that it could be simply a suggestion, see the
definitions of Depends, Recommends, and Suggests in Policy 7.2:

>  `Depends'
>   This declares an absolute dependency.  A package will not be
>   configured unless all of the packages listed in its `Depends'
>   field have been correctly configured.
> 
>   The `Depends' field should be used if the depended-on package is
>   required for the depending package to provide a significant
>   amount of functionality.

Given that the entire purpose of the driver is to actually *drive a
device*, and that it can't do that at all without the firmware, then the
depended-on package is clearly required for the depending package to
provide a significant amount of functionality, so the appropriate
relationship is a "Depends", which by policy 2.2.1 is not permitted from
a main to a non-main package.

>  `Recommends'
>   This declares a strong, but not absolute, dependency.
> 
>   The `Recommends' field should list packages that would be found
>   together with this one in all but unusual installations.

It would be an unusual driver installation indeed that could not
actually drive a device.  Nevertheless, even if the appropriate
relationship were "Recommends", the driver still could not go in main,
by policy 2.2.1.

>  `Suggests'
>   This is used to declare that one package may be more useful with
>   one or more others.  Using this field tells the packaging system
>   and the user that the listed packages are related to this one and
>   can perhaps enhance its usefulness, but that installing this one
>   without them is perfectly reasonable.

This is clearly not appropriate; it is not "perfectly reasonable" to
install a driver package without the firmware, any more than it is
reasonable to install a dynamically-linked binary without its shared
library dependencies.  In both cases, the functionality is limited to
simply imforming the user that a necessary component was not installed.

> The effect of this is that, as long as the ftpmasters team is happy with
> the license clarification from Sagem, you can keep eagle-usb-data too in
> main for sarge.

Yes, that's correct for Sarge; you may, of course, want to begin working
on the issue, since this will become a release-critical bug immediately
after the Sarge release.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Re: Is this software really GPL?

[Josh Triplett]

Raul Miller wrote:
> Is there any reason to believe that by "GPL" they mean the "GNU Public
> License"?

Just a note: s/GNU Public License/General Public License/g.  "GPL" is
"General Public License", and "GNU GPL" is "GNU General Public License";
there is no such thing as the "GNU Public License", although it is a
rather common misinterpretation.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Re: Is this software really GPL?

[Raul Miller]

On Tue, Oct 19, 2004 at 07:46:07PM -0400, Glenn Maynard wrote:
> On Tue, Oct 19, 2004 at 07:36:08PM -0400, Raul Miller wrote:
> > Is there any reason to believe that by "GPL" they mean the "GNU Public
> > License"?
> 
> The G in "GPL" is "General", not "GNU".  (I'm sure you know this, but
> you said "GNU Public License" several times in this mail.)

Sorry about that, I meant "GNU General Public License".

Anyways, I'm having more second thoughts than just about my acronym
expansion.

> > I can think of several possible scenarios:
> > 
> > [1] GPL does mean "GNU Public License", but no actual source is available
> > under that license.  In this case, the GPL grants no rights.
> 
> Like case #4, if this is true, the author is probably not competent.
> For example,
> 
> "You cannot install, or ask your customer to install a GPL version of
> OpenQM and then install your own product unless that product is also
> delivered to the user under GPL or an approved variant."

This would be accurate for the case that "your own product" incorporates
sources from OpenQM.

Otherwise, it's irrelevant.

> "If you are going to distribute multiple copies of openQM within your
> company, you will probably need a commercially licensed version of
> openQM."

This one is wierd -- but it might be true if some other assumptions
are held to be the case (such as: you don't want to provide source code
within your company, perhaps for policy reasons).

"probably" is a weasel word.

> Maybe we should forward this to the FSF; they would probably be interested
> in trying to have the misinformation being spread on this page corrected
> (or having a note inserted that the "GPL" here is not their GPL, but I doubt
> that's actually the case--unless the author of this page is deliberately
> trying to spread confusion).  Spreading false information about the GPL
> does significant damage to Free Software.

I'd wait a day or two, to see if someone can make better sense of this.

Thanks,

-- 
Raul

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

[Josh Triplett]

John H. Robinson, IV wrote:
> Glenn Maynard wrote:
>>On Mon, Oct 18, 2004 at 10:01:05PM -0700, John H. Robinson, IV wrote:
>>I'm saying that a package built with ecc (or icc or whatever) is not
>>the same package that you'll get if you build the same sources with
>>gcc; it's significantly functionally different.
> 
> The only difference is in *performance*. If there are other differences,
> then there is a bug in one of the two compilers. If you are equating
> performance with functionality, then we are going to have a very hard
> time communicating.

I'm going to ignore for the moment the fact that compilers are *not*
always functionally identical, since Glenn Maynard seems to be covering
that point quite effectively.

Performance is certainly part of functionality, if the program is
incapable of performing sufficiently in order to accomplish its task in
many cases for which people will want to use it.  Quoting from Wesley W.
Terpestra's original message at the beginning of this thread:
> Now, on to the dilemma: icc produces object files which run ~2* faster
> than the object files produced by gcc when SSE2 is used.
[...]
> 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.
 ^^^

So when someone goes to modify the package, either the security team
doing a security update or simply a user exercising their right to
modify the package, and they discover that when they modify the package
it suddenly gets much slower, to the point that it can no longer do the
task that the original non-free-compiled binary did, they would be
severely surprised and disappointed, and rightfully so.  This would be a
loss of functionality.

The correct answer is that on a completely Free system, it never had
that functionality in the first place.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Re: Is this software really GPL?

[Don Armstrong]

On Tue, 19 Oct 2004, Raul Miller wrote:
> > > 
> > > I strongly suggest that you read the following two web pages:
> > >  http://easyco.com/initiative/openqm/opensource/index.htm
> > > and the accompanying faq:
> > >  http://easyco.com/initiative/openqm/opensource/faq.htm
> > > 
> 
> On Tue, Oct 19, 2004 at 04:48:33PM -0700, Don Armstrong wrote:
> > Yeah, those webpages are basically indicate that they haven't read
> > the GPL and don't understand what it means at all.
> 
> That's what I thought at first.
> 
> Rereading it, I think those pages are OK.  Basically, all they seem
> to say is that if you distribute under the GPL you have to supply full
> sources to what you distribute.

Yeah, which is an additional restriction not present in the GPL.

The primary problem is that they're construing that list as a set of
restrictions against when you can use the GPLed version, which doesn't
fit with the GPL at all. [You can always use a GPLed program, you just
can't violate the terms of the GPL itself.]

It's possible that they have done this unintentionally, and intend
this list as merely a "what does using the GPLed version mean I have
to do?" query, rather than an "in order to use the GPLed version you
must do (or not do) the following" list.

Either way, it really needs some clarification.


Don Armstrong

-- 
Nothing is as inevitable as a mistake whose time has come.
 -- Tussman's Law

http://www.donarmstrong.com   http://rzlab.ucr.edu

Re: Is this software really GPL?

[Glenn Maynard]

On Tue, Oct 19, 2004 at 07:36:08PM -0400, Raul Miller wrote:
> Is there any reason to believe that by "GPL" they mean the "GNU Public
> License"?

The G in "GPL" is "General", not "GNU".  (I'm sure you know this, but
you said "GNU Public License" several times in this mail.)


> I can think of several possible scenarios:
> 
> [1] GPL does mean "GNU Public License", but no actual source is available
> under that license.  In this case, the GPL grants no rights.

Like case #4, if this is true, the author is probably not competent.
For example,

"You cannot install, or ask your customer to install a GPL version of
OpenQM and then install your own product unless that product is also
delivered to the user under GPL or an approved variant."

"If you are going to distribute multiple copies of openQM within your
company, you will probably need a commercially licensed version of
openQM."

These statements have nothing to do with the GNU General Public License.
(I won't expound on why, since I'm pretty sure that everyone listening
already knows.)

Maybe we should forward this to the FSF; they would probably be interested
in trying to have the misinformation being spread on this page corrected
(or having a note inserted that the "GPL" here is not their GPL, but I doubt
that's actually the case--unless the author of this page is deliberately
trying to spread confusion).  Spreading false information about the GPL
does significant damage to Free Software.

-- 
Glenn Maynard

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

[Josh Triplett]

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 <[EMAIL PROTECTED]> 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

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

[Josh Triplett]

Wouter Verhelst wrote:
> On Mon, Oct 18, 2004 at 06:55:30PM -0400, Raul Miller wrote:
>>>On Mon, Oct 18, 2004 at 07:51:00PM +0200, Josselin Mouette wrote:
Main must be built with only packages from main.
>>On Tue, Oct 19, 2004 at 12:37:45AM +0200, Wouter Verhelst wrote:
> As a side note, I think the comparison to Java-software someone made was
> a flawed one. There is a major difference between "it can be compiled,
> but it won't be as fast" and "it can be ran by free software, but not
> compiled". Some java software is in the latter category; what we are
> discussing is in the former.

There are pieces of Java software in several different categories; the
most common is certainly "it won't build with a Free compiler", but I
have also seen "I don't want to rebuild the .jar file because then the
checksum won't match upstream", as well as just plain "why should I
bother rebuilding".

Also, the original question was in the context of saying that the
software might well be unusably slow if compiled with GCC, and that
compiling with ICC would bring it to a usable speed; that implies ICC is
required to produce a usable binary, which sounds quite like the Java
situation: runnable on a Free system but requiring non-free tools to build.

>>I'm interested in your reasons for making this assertion.
>>
>>If your point is that it's possible build software whose source is
>>in main using compilers which are not in Main, I'd agree with you.
>>However, I don't see any reason to consider the resulting builds to be
>>a part of main.
> 
> I don't see any reason why we should not consider the resulting builds
> to be part of main.
> 
> I am fully aware that there are people who think that all non-free
> software should be banned from the face of the earth (Hi Richard!).
> However, the fact that some Free Software package is built using
> non-free Software, even though it could be built using only Free
> compilers, does not suddenly make the Free Software package non-free.

I agree with that statement: the resulting binary is not "non-free",
given that source is supplied.  You should note that all packages in
contrib are required to be Free Software, and that the only reason they
are in contrib is that they require non-free software for compilation or
execution.

> What is 'Free Software' is defined differently by both Debian and the
> Free Software Foundation; however, GPL'ed source code which is built
> using a non-free compiler does not, in my view, fail any test of either
> of those definitions.

Agreed, to the extent that it is meaningful to talk about the Freeness
of a binary.  The point in question is not whether the software is Free,
but whether it can go in main, which requires more than just being Free:
it also requires that packages in main be sufficient to build and run it.

Now, as for the argument that they are sufficent, though they aren't
actually used, I have two responses to that:
1) As I said in this message, it doesn't sound like a GCC-compiled
version would actually be capable of performing some of the tasks the
ICC-compiled version could, so GCC isn't sufficient.
2) You may well have found a bug in Policy, where it didn't cover one of
the corner cases; I suspect there are many such cases, given that I
don't think Policy is a legalistic "impossible to weasel out of"
document, but more a set of rules designed to document existing
practice for people who mostly _want_ to follow it.  I would therefore
suggest that this item in Policy should be corrected, to make it clear
that the package must not only be buildable using software from main,
but that it must actually be _built_ using software from main.

>>>Wesley's software can be built using software in main. It will not be as
>>>fast, but it will still do its job, flawlessly, without loss of
>>>features, with the ability to modify the software to better meet one's
>>>needs if so required.
>>
>>I have no disagreement with this statement.

I do.  Wesley suggested that the software could not do its job
flawlessly when compiled with GCC, because it was too slow to keep up
with "line speeds".  This is yet another reason why it is not acceptable
to ship a package in main built with a non-free compiler: if everyone is
using that compiled version, how do you even know the other version is
usable at all?  It sounds as though it would not be sufficient for many
applications.

- Josh Triplett



signature.asc
Description: OpenPGP digital signature

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

[Josh Triplett]

Lewis Jardine wrote:
> Wouter Verhelst wrote:
>> If you still insist, consider this: If I would know i386 assembler
>> (which I don't), I could theoretically hand-optimize software before I
>> upload it. Since I did hand-optimization, the resulting binary would no
>> longer be built using only Free Software; it would also incorporate the
>> fruit of my labour. Is the resulting binary now suddenly non-free -- or,
>> at least, should it go to contrib instead of main? If so, why? If not,
>> what's the difference between this example, and the question of
>> icc-built software?
>>
> Wouldn't the resulting Binary be non-free, as it no longer comes with
> the complete source (the 'preferred form for modification', as the GPL
> puts it)? Your hand-optimised assembler code is now part of the source,
> and if you don't provide the assembler source, the source is not complete.

That's correct: in order to satisfy your obligations under the GPL, you
would need to provide the hand-optimized assembler code.

(It is possible, of course, that Wouter is suggesting direct
modification of the machine code; if that is indeed your preferred form
for modification, then providing it is sufficient.  I seriously doubt
that is a common occurance, and at a minimum it should be clearly
documented if it is the case.)

- Josh Triplett



signature.asc
Description: OpenPGP digital signature

Re: Is this software really GPL?

[Raul Miller]

Note: I've left Anthony Youngman's email address in the headers,
but I seem to have a local problem where email to Anthony bounces.
[I can work around that, using telnet, but it's a pain.]

> > 
> > I strongly suggest that you read the following two web pages:
> >  http://easyco.com/initiative/openqm/opensource/index.htm
> > and the accompanying faq:
> >  http://easyco.com/initiative/openqm/opensource/faq.htm
> > 

On Tue, Oct 19, 2004 at 04:48:33PM -0700, Don Armstrong wrote:
> Yeah, those webpages are basically indicate that they haven't read the
> GPL and don't understand what it means at all.

That's what I thought at first.

Rereading it, I think those pages are OK.  Basically, all they seem
to say is that if you distribute under the GPL you have to supply full
sources to what you distribute.

-- 
Raul

Re: Is this software really GPL?

[Raul Miller]

On Tue, Oct 19, 2004 at 07:36:08PM -0400, Raul Miller wrote:
> [4] "GPL" means "GNU Public license" and all sources are readily
> available under the GPL.  In this case, the author of those pages is
> probably not competent.

Actually, the pages at those urls look fine -- it's either myself or
the other people you've been exchanging email with who aren't competent.

-- 
Raul

Re: Is this software really GPL?

[Don Armstrong]

[I'm taking the liberty of Cc:'ing you against Debian list
policy. Please set MFT in the future if you wish people to respond to
you personally.]

On Tue, 19 Oct 2004, Anthony W. Youngman wrote:
> Sorry if this is not quite the right place, but I'm somewhat fuming ...
> 
> There's a really nice piece of software, called QM (it's a database)
> that has allegedly been released under the GPL by its owner, one
> Martin Philips, of a company called Ladybridge, in England.
> 
> He was talked into doing this by a company called EasyCo, based in
> the States.
> 
> I joined the mailing list, and then there was a post saying that
> some of the code was invariant. When I said that the GPL said I
> could change it, Martin said that if I tried he would set the
> lawyers on me! (And no, I'm not fuming at Martin - I get the
> impression he's been duped :-(

Hrm. Sounds like you should ask him if he really intends for the code
to be placed under the GPL, and suggest that he read:

http://www.gnu.org/philosophy/
and
http://www.gnu.org/licenses/gpl.html

especially the preamble of the latter. If he or his lawyers have
specific questions, they should ask [EMAIL PROTECTED]

> 
> I strongly suggest that you read the following two web pages:
>  http://easyco.com/initiative/openqm/opensource/index.htm
> and the accompanying faq:
>  http://easyco.com/initiative/openqm/opensource/faq.htm
> 

Yeah, those webpages are basically indicate that they haven't read the
GPL and don't understand what it means at all. Unfortunatly, since the
copyright holder appears to not have even licensed his code properly,
and a case could be made that those are additional restrictions on top
of the GPL, your only recourse is to try to get them to actually
license the code under the GPL, full stop.

If not, strongly suggest that they not misconstrue their program as
being licensed under the GPL, and perhaps put the FSF in touch with
them so that they get an idea that what they are doing is bad.
 
> Oh - and the guy I'm dealing with said he would be absolutely
> delighted if someone could get Debian to distribute this package!

Heh. Until they clean up their licensing mess, there's no way we can
distribute it. I'd even be wary of using this program at all based on
the questionable assumptions upstream seems to be making.


Don Armstrong

-- 
Of course Pacman didn't influence us as kids. If it did, we'd be
running around in darkened rooms, popping pills and listening to
repetitive music.

http://www.donarmstrong.com http://rzlab.ucr.edu

Re: Is this software really GPL?

[Raul Miller]

On Tue, Oct 19, 2004 at 11:23:33PM +0100, Anthony W. Youngman wrote:
> I strongly suggest that you read the following two web pages:
>   http://easyco.com/initiative/openqm/opensource/index.htm
> and the accompanying faq:
>   http://easyco.com/initiative/openqm/opensource/faq.htm

Is there any reason to believe that by "GPL" they mean the "GNU Public
License"?

By this, I don't mean private email -- I mean, is there source available
with the GPL associated with it?

I can think of several possible scenarios:

[1] GPL does mean "GNU Public License", but no actual source is available
under that license.  In this case, the GPL grants no rights.

[2] Similar, but some sources have that license and some don't.  In this
case, where the sources form complete programs, I'd think the GPL terms
hold, and where sources are not licensed under the GPL or they can't be
made to form programs, the GPL terms probably do not hold.

[3] "GPL" stands for something else -- perhaps with some license clauses
in common with the gnu license, but where something else is really
going on.

[4] "GPL" means "GNU Public license" and all sources are readily
available under the GPL.  In this case, the author of those pages is
probably not competent.

-- 
Raul

Is this software really GPL?

[Anthony W. Youngman]

Sorry if this is not quite the right place, but I'm somewhat fuming ...

There's a really nice piece of software, called QM (it's a database) 
that has allegedly been released under the GPL by its owner, one Martin 
Philips, of a company called Ladybridge, in England.


He was talked into doing this by a company called EasyCo, based in the 
States.


I joined the mailing list, and then there was a post saying that some of 
the code was invariant. When I said that the GPL said I could change it, 
Martin said that if I tried he would set the lawyers on me! (And no, I'm 
not fuming at Martin - I get the impression he's been duped :-(


Anyways, I'm having rather a set-to on email with EasyCo about the 
licencing. They pointed me at two web pages, an "about openQM" and a 
"FAQ" page. Here.



I strongly suggest that you read the following two web pages:
 http://easyco.com/initiative/openqm/opensource/index.htm
and the accompanying faq:
 http://easyco.com/initiative/openqm/opensource/faq.htm


Bear in mind they are talking about a program that is allegedly 
dual-licenced. Commercial and GPL. SOMEBODY needs larting with a 
clue-by-four (if it's me, please do - I'd like to know why!). Except my 
emails with EasyCo so far give me the impression I'm dealing with a SCO 
lawyer - I wonder why ... I talk about distributing *source*, so they 
quote clause *3* of the GPL at me ... Oh - and I just happened to have 
quoted clauses 6 and 7 at them at the time ...


Bear in mind this platform includes a compiler. I'm told it's a 
compiler/linker, but the commercial equivalents I know of aren't, and 
the LGPL equivalent I'm writing most certainly isn't. To my mind, a 
compiler/linker implementation is a pretty big design blunder ...


I'd better not say more except to tell you to look for what they say 
about "the purpose of the GPL", about "incitement to distribute", and 
distribution to franchisees/subsidiaries.


Oh - and the guy I'm dealing with said he would be absolutely delighted 
if someone could get Debian to distribute this package!


Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999

Re: automatisk svar fra kundeservice@colorline.no

[Liv Bakka]

Skulle gjerne bestille en pakketur for 9 personer 
den 5.nov -7.nov. Båt Sfj.-Strømstad, buss Strømstad-Gøteborg, tur kode 
9050. Hvis jeg ikke kan bestille her kan dere vennligst gi meg telf. nr 
hvor jeg kan bestille turen.
Med vennlig hilsen 
Liv Bakka
Vestre Braarudgt. 26
3181 Horten
Mob. 91 85 02 30

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

[Thomas Bushnell BSG]

"John H. Robinson, IV" <[EMAIL PROTECTED]> writes:

> The only difference is in *performance*. If there are other differences,
> then there is a bug in one of the two compilers. If you are equating
> performance with functionality, then we are going to have a very hard
> time communicating.

This is not true.  The program may depend on the details of how a
compiler in fact works (for example, how structure members are
packed).  Such a thing might be a bug, but it is there nonetheless,
and is not a compiler bug.

And if the binary in the archive was made by some other tool, then
debugging resulting problems is a nightmare.

Thomas

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

[Glenn Maynard]

On Tue, Oct 19, 2004 at 09:16:17AM -0700, John H. Robinson, IV wrote:
> The only difference is in *performance*. If there are other differences,
> then there is a bug in one of the two compilers. If you are equating
> performance with functionality, then we are going to have a very hard
> time communicating.

I guess so.  I'd consider a security update that significantly reduced
the performance of the package due to a different compiler being used to
be a severe error.  I suspect the stable RM would agree.  You apparently
don't care, but I suspect you're in a tiny minority (and for the sake
of the quality of Debian stable releases, I hope so).

> > Huh?  You ignored what I said: you can't make a stable update using a
> > different compiler, because it can introduce both performance and (more
> > importantly) new bugs, which is completely unacceptable for a Debian
> > stable security update.
> 
> Actually, later in my previous message I accepted your agrument on
> pragmatic grounds.

It's one real-life example of why depending on non-free components to
build Debian is unacceptable.  That's why Debian exists: to build an
entirely free system--not "entirely free, except you'll need these non-
free tools to actually build it".

> You are the one that brought up the bogus argument that if the icc
> packaged one were introduced into main, that any end-user would have to
> accept the icc license.

No, I didn't.  I said that you'd have to do that if you wanted to produce
the package, which is entirely true; if you don't do so, you can only
build with a different compiler, which gives you a different thing.

> This is almost akin to saying that if a package were built on a vmware
> virtual machine, the end-user would have to accept the vmware license,
> or that the package would have to go into contrib.

This, on the other hand, is entirely bogus.  Building in a VM doesn't
change the output; building with a different compiler certainly does.

-- 
Glenn Maynard

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

[John H. Robinson, IV]

I am not subscribed to debian-legal

Glenn Maynard wrote:
> On Mon, Oct 18, 2004 at 10:01:05PM -0700, John H. Robinson, IV wrote:
> 
> I'm saying that a package built with ecc (or icc or whatever) is not
> the same package that you'll get if you build the same sources with
> gcc; it's significantly functionally different.

The only difference is in *performance*. If there are other differences,
then there is a bug in one of the two compilers. If you are equating
performance with functionality, then we are going to have a very hard
time communicating.

> Huh?  You ignored what I said: you can't make a stable update using a
> different compiler, because it can introduce both performance and (more
> importantly) new bugs, which is completely unacceptable for a Debian
> stable security update.

Actually, later in my previous message I accepted your agrument on
pragmatic grounds.

> Are you claiming that changing from one compiler to another, or changing
> optimization flags, can't introduce bugs?  If so, please stay away from
> any security-sensitive packages ... :)

I'm saying that it should not introduce bugs. In a perfect world, of
course. We don't live in one.

> > gcc is written under the GPL. I can write a non-free program, keep the
> > source entirely secret, and distribute my program in binary form only,
> > with a very restrictive license. The gcc license does not contaminate
> > the resultant binary (unless, of course, I put gcc code in my program).
> > Similarly, the ecc license should not prevent compiling GPL'd code. If
> > it did, ecc would be unsuitable for any purpose, period.
> 
> This doesn't seem relevant.

You are the one that brought up the bogus argument that if the icc
packaged one were introduced into main, that any end-user would have to
accept the icc license.

This is almost akin to saying that if a package were built on a vmware
virtual machine, the end-user would have to accept the vmware license,
or that the package would have to go into contrib.

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  

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

[Glenn Maynard]

On Tue, Oct 19, 2004 at 10:39:45AM +0200, Wouter Verhelst wrote:
> No, it is not. What you advocate is essentially that a later compilation
> must result in the exact same binary, disregarding the fact that our
> toolchain will change..

Please review this post:

   http://lists.debian.org/debian-legal/2004/10/msg00302.html

> > Problems arise if there are differences between what the two compilers
> > build.  For example, there might at some point be a bug which only shows
> > up under gcc.
> 
> That is a non-issue. We have 11 architectures; if there is a bug which
> only shows up under gcc, then the software will most likely exhibit that
> buggy behaviour on those 11 other architectures.

No, it's an extremely serious issue.  If you upload a security update,
with a one-line patch, the changes should be minimal--but they can be
very major if you change compilers.

> If it does not (i.e., it is a bug which only shows up under gcc on
> i386), then this is a bug in gcc which will most likely be found by
> other applications as well (the strain we put on our compilers by
> compiling some 8GB worth of software is enormous)

So you're actually claiming that recompiling software with a compiler
from a stable Debian release can never introduce bugs.  Please refrain
from doing updates to stable Debian releases.

Also, it's just as unacceptable to *fix* bugs accidentally in a stable
release.  For example, OpenSSL might have an unknown bug as a result
of a compiler glitch that causes something useful but incorrect to be
allowed.  This is not a bug that would be fixed in a stable release.
If a stable update is made later to fix an unrelated security bug, you
wouldn't be allowed to go and fix this at the same time.  If you change
compilers, however, you could end up inadvertently doing that, resulting
in undocumented, non-critical changes in a stable package that could
break existing systems, which is something Debian tries extremely hard
to prevent.

> Or what about a developer who modified the gcc code to suit his own
> needs, but did not, as the GPL allows him to do, distribute either the
> source to his modifications or a binary built from his modified source?

This is unacceptable, for the same reasons; nobody else can make a stable
update to the package.

-- 
Glenn Maynard

Re: firmware status for eagle-usb-*

[Benoît Audouard]

> In article <[EMAIL PROTECTED]> you wrote:
>
> Loïc, I suggest you read the whole debian-legal thread named "non-free
> firmware: driver in main or contrib?", because it answers many of the
> points you raised.
> I will summarize the points relevant to the eagle-usb-* packages:

thanks Marco, as I did not take this time to summarize in my previous
answer :
http://lists.debian.org/debian-legal/2004/10/msg00299.html

> - distribution of firmwares with no source code available in debian/main
>   has been forbidden by the second-last general resolution, but the last
> general resolution removed this restriction just for sarge (as long as
> the license allows distribution)
> - the GPL issue is probably a non-issue: if the copyright owner (Sagem)

Analog Digital, Inc. is the copyright holder for firmware and dsp_code
We are currently working with them, the distribution issue has been
raised, the licence issue is to come as the answer "all the files in
adi.zip file can be distributed" is only suficient for distribution.
That's one of the reasons why I began :
http://dev.eagle-usb.org/wakka.php?wiki=DeveloppementGPL
Maybe GPL (with sourcecode) can be obtained, at least for older firmware.
For latest firmware I've got to ask (with suficient reasons, it may be
possible, or at least a licence in the list given by Nathanael).

>   stated that what the binary blobs they provide is source, I think that
> the ftpmasters team will accept the package (the ftpmasters decide
> what goes in debian, not debian-legal...)
> - notwithstanding the disagreement of a few people here, even if
>   post-sarge eagle-usb-data will have to be moved to non-free, there is
> nothing in our policy which prevents to downgrade the hard dependency
> to a suggestion, to be able to keep shipping the free driver in main
>
> The effect of this is that, as long as the ftpmasters team is happy with
> the license clarification from Sagem, you can keep eagle-usb-data too in
> main for sarge.
>
>> I'm really sorry I re-started a long-discussed troll again, and I'm
>> sad Debian won't provide support for a lot of hardware in a close
>> future.
> Do not mistake the opinion of a few vocal debian-legal users with the
> one of all developers. Many other developers share your concern and will
> fight to not let this happen.
> Please join debian-legal and keep defending the freeness of your
> package.

Comments are welcome to help identify possible impacts of this choice of
licence in the near term and the long term :
http://dev.eagle-usb.org/wakka.php?wiki=RequirementsEagleUsbGPL
Short terms requirements are validated (#ST) by Analog and Sagem, longer
terms requiremens are to be discussed soon (#LT).
My concerns are indeed for availability on CD for the end-user, an
acceptable way to install, clear licencing that is accepted by all.

@++
Ben'. aka baud123

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

[Wouter Verhelst]

On Mon, Oct 18, 2004 at 06:28:01PM -0700, John H. Robinson, IV wrote:
[...]
> This package is buildable by tools in main. It meets the letter of the
> law. The spirit seems a bit ambiguous. Good case in point, the m68k
> cross-compiled stuff, where the cross-compiler used was non-free. (I
> have not verified the accuracy of the non-free claim of the cross-
> compiler.

I didn't say that. The compiler was built from gcc sources, but the
cross-compiler (as it was used) was not uploaded to the archive.

> Also, this discussion is academic as the maintainer is going to split
> the package into two: gcc build in main, and icc built in contrib. Given
> the circumstance, I felt that this action is the best.

Agreed.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

On Mon, Oct 18, 2004 at 05:47:26PM -0700, Steve Langasek wrote:
> On Tue, Oct 19, 2004 at 02:04:42AM +0200, Wouter Verhelst wrote:
> > A difference in optimization is not relevant to a package's freedom.
> 
> If compiling the program with a non-free compiler gains you users who would
> not find the package usable otherwise, distributing binaries built with
> such a compiler induces your users to be dependant (indirectly) on non-free
> software.  That is a freedom issue.

Okay, that is a fair point. I'll leave it at that.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

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

[Colin Watson]

On Tue, Oct 19, 2004 at 08:11:50PM +1000, Hamish Moffatt wrote:
> On Mon, Oct 18, 2004 at 10:24:44PM -0400, Glenn Maynard wrote:
> > Exact words are:
> > 
> >  In addition, the packages in _main_
> > * must not require a package outside of _main_ for compilation or
> >   execution (thus, the package must not declare a "Depends",
> >   "Recommends", or "Build-Depends" relationship on a non-_main_
> >   package),
> > 
> > If you build with different tools, you have a different package.  "X
> 
> That's true if you define a package as an exact .deb, but not if you define
> it as a source package (.orig.tar.gz/.diff.gz/.dsc). The latter seems to
> be a more useful definition in the context of compilation, IMHO.

The quote above seems to refer to both, since it speaks of Depends and
Recommends (which only apply to binary packages) and Build-Depends
(which only apply to source packages).

-- 
Colin Watson   [EMAIL PROTECTED]

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

[Brian Thomas Sniffen]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Mon, Oct 18, 2004 at 08:25:48PM -0400, Raul Miller wrote:
>> On Tue, Oct 19, 2004 at 01:47:34AM +0200, Wouter Verhelst wrote:
>> > The first section of the SC says that Debian will remain 100% Free
>> > Software.
>> 
>> That is the title of that section.
>> 
>> If you bother to read it, you'll see "We will never make the system
>> require the use of a non-free component. "
>
> A binary which has been compiled using a non-free compiler does not
> require non-free software to run; nor does it require the same compiler
> to be built again. If it does, then it doesn't belong in main; that is
> not in dispute.

It certainly does require the same compiler to be built again.  See
"Reflections on Trusting Trust"; the choice of compiler is part of the
language spec.

The source is what's needed to replicate the binary.
A compiler which compiles to PPC code, for example, won't replicate an
x86 binary.  Similarly, an SSE-aware compiler is not the same as a 386 compiler.

> No, it is not. What you advocate is essentially that a later compilation
> must result in the exact same binary, disregarding the fact that our
> toolchain will change..

I think you mischaracterize your opponent's argument.  Rather, we want
indistinguishable binaries.  Going from gcc 2.95 to 3.4 certainly
produces changes, but not of the sort discussed here -- in this case,
he's saying it does require icc to get the useful binary.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: firmware status for eagle-usb-*

[Marco d'Itri]

In article <[EMAIL PROTECTED]> you wrote:

Loïc, I suggest you read the whole debian-legal thread named "non-free
firmware: driver in main or contrib?", because it answers many of the
points you raised.
I will summarize the points relevant to the eagle-usb-* packages:

- distribution of firmwares with no source code available in debian/main
  has been forbidden by the second-last general resolution, but the last
  general resolution removed this restriction just for sarge (as long as
  the license allows distribution)
- the GPL issue is probably a non-issue: if the copyright owner (Sagem)
  stated that what the binary blobs they provide is source, I think that
  the ftpmasters team will accept the package (the ftpmasters decide
  what goes in debian, not debian-legal...)
- notwithstanding the disagreement of a few people here, even if
  post-sarge eagle-usb-data will have to be moved to non-free, there is
  nothing in our policy which prevents to downgrade the hard dependency
  to a suggestion, to be able to keep shipping the free driver in main

The effect of this is that, as long as the ftpmasters team is happy with
the license clarification from Sagem, you can keep eagle-usb-data too in
main for sarge.

> I'm really sorry I re-started a long-discussed troll again, and I'm sad
> Debian won't provide support for a lot of hardware in a close future.
Do not mistake the opinion of a few vocal debian-legal users with the
one of all developers. Many other developers share your concern and will
fight to not let this happen.
Please join debian-legal and keep defending the freeness of your
package.

-- 
ciao,
Marco

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

[Hamish Moffatt]

On Mon, Oct 18, 2004 at 10:24:44PM -0400, Glenn Maynard wrote:
> On Mon, Oct 18, 2004 at 06:28:01PM -0700, John H. Robinson, IV wrote:
> > Note the exact words (I am assuming that Glenn copied them verbatim):
> > the package in main must be buildable with tools in main
> 
> Exact words are:
> 
>  In addition, the packages in _main_
> * must not require a package outside of _main_ for compilation or
>   execution (thus, the package must not declare a "Depends",
>   "Recommends", or "Build-Depends" relationship on a non-_main_
>   package),
> 
> If you build with different tools, you have a different package.  "X

That's true if you define a package as an exact .deb, but not if you define
it as a source package (.orig.tar.gz/.diff.gz/.dsc). The latter seems to
be a more useful definition in the context of compilation, IMHO.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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

[Wesley W. Terpstra]

I know this thread has progressed beyond the actual situation 
I asked about, but I wanted to just throw in my opinion too.

On Tue, Oct 19, 2004 at 09:13:24AM +0200, Andreas Barth wrote:
> A program is IMHO not only specified by the fact that it does certain
> transformations from input to output, but also by the speed it does
> this. If this specification can be matched by gcc, why consider using
> icc at all? And if not, it requires icc.

This is now also my point of view.

When I started this thread, I also _felt_ that contrib was the correct 
place for my application, but didn't really know why. Now I can explain 
it better. The proposal of keeping one version in main and one in contrib
also addresses my concern about usability.

So, I am happy with the outcome of this discussion already. =)

-- 
Wesley W. Terpstra

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

[Wouter Verhelst]

On Tue, Oct 19, 2004 at 09:13:24AM +0200, Andreas Barth wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) [041019 00:40]:
> > Wesley's software can be built using software in main. It will not be as
> > fast, but it will still do its job, flawlessly, without loss of
> > features, with the ability to modify the software to better meet one's
> > needs if so required.
> 
> I disagree.
> 
> A program is IMHO not only specified by the fact that it does certain
> transformations from input to output, but also by the speed it does
> this.

There can be cases where compiling software using more recent toolchain
versions will result in a binary not running as fast as before (because
the newer libc is a bit more bloaty, or because some aggressive
optimization which was enabled before but which was deemed buggy by
design afterwards, was disabled again, or whatnot). Where is the
difference with using a non-free compiler?

> If this specification can be matched by gcc, why consider using
> icc at all? And if not, it requires icc. (You can also consider what
> happens when we want to do a security update: Does the security team
> need to install icc, or do we want that the software runs significantly
> slower afterwards, and misses its specification?)

If that is an issue, then it is also an issue for software currently in
main but which is built using toolchain versions that are now no longer
in main.

> If icc is required for that application, than it needs to go to contrib.

Indeed. However, as long as the software does indeed compile correctly
using gcc, one can say that icc is not required.

> If not, please compile it with gcc.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

On Mon, Oct 18, 2004 at 08:25:48PM -0400, Raul Miller wrote:
> On Tue, Oct 19, 2004 at 01:47:34AM +0200, Wouter Verhelst wrote:
> > The first section of the SC says that Debian will remain 100% Free
> > Software.
> 
> That is the title of that section.
> 
> If you bother to read it, you'll see "We will never make the system
> require the use of a non-free component. "

A binary which has been compiled using a non-free compiler does not
require non-free software to run; nor does it require the same compiler
to be built again. If it does, then it doesn't belong in main; that is
not in dispute.

Also, if the software compiled using a non-free compiler requires an
additional license from the distributor, then it doesn't belong in main
either; but AIUI, this is not the case (it only requires an additional
license from the person using the compiler).

> > It does not say that the binary bits of Debian can be restored
> > to something which will produce the exact same MD5 sum using only Free
> > Software[1].
> 
> This is a straw man argument.
> http://www.nizkor.org/features/fallacies/straw-man.html

No, it is not. What you advocate is essentially that a later compilation
must result in the exact same binary, disregarding the fact that our
toolchain will change..

> > Since Wesley's software will be released under the GPL, it
> > will clearly be Free Software, so there is no problem.
> 
> There is a problem if building that component requires the use
> of a non-free compiler.

Well, it does not /require/ the use of a non-free compiler.

> > The fact that Wesley wanted to build his package using non-free software
> > does not really matter -- as long as it does build using Free software.
> 
> It doesn't matter if there is no difference in what is built.
> 
> Problems arise if there are differences between what the two compilers
> build.  For example, there might at some point be a bug which only shows
> up under gcc.

That is a non-issue. We have 11 architectures; if there is a bug which
only shows up under gcc, then the software will most likely exhibit that
buggy behaviour on those 11 other architectures.

If it does not (i.e., it is a bug which only shows up under gcc on
i386), then this is a bug in gcc which will most likely be found by
other applications as well (the strain we put on our compilers by
compiling some 8GB worth of software is enormous)

> > Heck, some developers might have installed icc and might be compiling
> > their packages using that compiler instead of gcc; as long as their
> > software does not use too many gcc-isms, you should not even notice so
> > in the source. How would you tell that such a package is built using icc
> > instead of gcc, other than by benchmarking?
> 
> [1] I hope no one is doing that.

I wouldn't care, as long as it would work correctly.

> [2] We probably wouldn't notice this issue until it creates problems.

I don't think it would create problems. See below.

> > If you still insist, consider this: If I would know i386 assembler
> > (which I don't), I could theoretically hand-optimize software before I
> > upload it. Since I did hand-optimization, the resulting binary would no
> > longer be built using only Free Software; it would also incorporate the
> > fruit of my labour. Is the resulting binary now suddenly non-free -- or,
> > at least, should it go to contrib instead of main? If so, why? If not,
> > what's the difference between this example, and the question of
> > icc-built software?
> 
> If you've hand optimized it, the hand optimized assembler becomes a part
> of the sources.

Okay, what about this then? The m68k kernel maintainer at one point, if
I'm not mistaken, used to compile m68k kernels with a cross-compiler he
built.

As a result, the compiler used to compile the kernel is not in main.
Does that make the resulting kernel binary non-free?

Or what about a developer who modified the gcc code to suit his own
needs, but did not, as the GPL allows him to do, distribute either the
source to his modifications or a binary built from his modified source?

(where he only modified the optimizer code, not the parser code)

[...]
> > I don't see any reason why we should not consider the resulting builds
> > to be part of main.
> 
> If you can guarentee that when the package built with icc is tested
> that any bugs which would result from building using at least one free
> compiler will be evident, and if you can guarantee that systems which
> use icc-built software will continue to function if they use some free
> compiler to build that software then the problem is more philosophical
> than practical.
> 
> That said, I don't see any viable way for you to provide any such
> guarantees.

Easy.

I can see three classes of problems that could result in the software
not being usable when compiled by a different compiler than the one used
when the software was distributed:

* The software simply does not compile, due to a parser bug in one of
  the compilers; either 

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

[Andreas Barth]

* Wouter Verhelst ([EMAIL PROTECTED]) [041019 00:40]:
> On Mon, Oct 18, 2004 at 07:51:00PM +0200, Josselin Mouette wrote:
> > Le lundi 18 octobre 2004 à 19:22 +0200, Wesley W. Terpstra a écrit :
> > > 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.
> > > 
> > > On the other hand, is this still open source?
> > > Is this allowed by policy?
> > > Can this go into main?
> > 
> > Main must be built with only packages from main.

> No, that's not true.
> 
>  In addition, the packages in _main_
> * must not require a package outside of _main_ for compilation or
>   execution (thus, the package must not declare a "Depends",
>   "Recommends", or "Build-Depends" relationship on a non-_main_
>   package),
> 
> There's a difference, which is crucial. ICC may not be Free Software,
> policy does not say you must only use Free Software to build a package;
> it says you must not /require/ a package outside main to build it.
> 
> The difference is subtle, but crucial.
> 
> Wesley's software can be built using software in main. It will not be as
> fast, but it will still do its job, flawlessly, without loss of
> features, with the ability to modify the software to better meet one's
> needs if so required.

I disagree.

A program is IMHO not only specified by the fact that it does certain
transformations from input to output, but also by the speed it does
this. If this specification can be matched by gcc, why consider using
icc at all? And if not, it requires icc. (You can also consider what
happens when we want to do a security update: Does the security team
need to install icc, or do we want that the software runs significantly
slower afterwards, and misses its specification?)

If icc is required for that application, than it needs to go to contrib.
If not, please compile it with gcc.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

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

[Glenn Maynard]

On Mon, Oct 18, 2004 at 10:01:05PM -0700, John H. Robinson, IV wrote:
> I agree with this. This is also not the point. You keep talking about
> pracakge that can only be built with a non-free compiler. The one in
> question can be built with a free or non-free compiler.

No, that's not what I said.  I'm saying that a package built with ecc
(or icc or whatever) is not the same package that you'll get if you
build the same sources with gcc; it's significantly functionally different.
If it wasn't significantly different, nobody would bother to compile
with the non-free compiler in the first place, so it's clear that the
choice of compiler matters to some people, and making a stable update
that changed to gcc would be an unacceptable stable change.

> > For example, suppose OpenSSL is built with ecc (Expensive C Compiler),
> > because it produces faster binaries, the Debian package is created with
> > it, and ends up in a stable release.  A security bug is found, and the
> > maintainer isn't available.  Can another developer fix this bug?  No:
> > you can't possibly make a stable update with a completely different
> > compiler, halving the speed and possibly introducing new bugs.  (Debian
> > is very conservative and cautious with stable updates; this is one of
> > the reasons many people use it.)
> 
> Yes. Assuming that OpenSSL will compile properly with both gcc and ecc,
> and the source is not using tricks to change functionality when compiled
> wiht one or the other. To me, using ecc or gcc is, or at least should
> be, similar to using gcc -O1 or gcc -O9.

Huh?  You ignored what I said: you can't make a stable update using a
different compiler, because it can introduce both performance and (more
importantly) new bugs, which is completely unacceptable for a Debian
stable security update.  You should be using the same compiler, and
the same compiler flags, too.  Debian's approach to security updates
is very clear: change only what's necessary to fix the bug.

Are you claiming that changing from one compiler to another, or changing
optimization flags, can't introduce bugs?  If so, please stay away from
any security-sensitive packages ... :)

> gcc is written under the GPL. I can write a non-free program, keep the
> source entirely secret, and distribute my program in binary form only,
> with a very restrictive license. The gcc license does not contaminate
> the resultant binary (unless, of course, I put gcc code in my program).
> Similarly, the ecc license should not prevent compiling GPL'd code. If
> it did, ecc would be unsuitable for any purpose, period.

This doesn't seem relevant.

-- 
Glenn Maynard

Re: firmware status for eagle-usb-*

[Josh Triplett]

Loïc Minier wrote:
> Don Armstrong <[EMAIL PROTECTED]> - Mon, Oct 18, 2004:
>>No sourcecode bits:
>>http://people.debian.org/~terpstra/thread/20021106.222149.24f92b22.en.html
> 
>  Quite interesting, although related to code running on the host, most
>  of the thread is interesting.

Note that where the code runs is not relevant to whether it must be
Free; if Debian ships it in main, it must be Free.

>>In the context of DSP Binaries:
>>http://people.debian.org/~terpstra/thread/20030922.064726.2833dd35.en.html
> 
>  Interesting, and particularly this:
>  
>  (where it is stated that if the source has been lost, binary is the
>  preferred form of modification, which could eventually match the Sagem
>  case)

It is possible, yes, but this generally only occurs with software for
which either the original author has no source anymore, or the original
author is not reachable.

>>And the incredibly gargantuan keep non-free proposal thread:
>>http://people.debian.org/~terpstra/thread/20040129.052350.5b5e7192.en.html
> 
>  It's 3am, I won't read that one!  ;)

:)

>>And finally:
>>http://www.debian.org/vote/2004/vote_003 and
>>http://www.debian.org/vote/2004/vote_004
> 
>  Hmm that's a strong commitment of Debian, and I can't argue against
>  that.
> 
>  Anyway, my initial goal was only to report some history of Sagem with
>  this driver, and stating that Pierre Machard cann't reply to this right
>  now.
> 
>  I'm really sorry I re-started a long-discussed troll again, and I'm sad
>  Debian won't provide support for a lot of hardware in a close future.

You aren't trolling; yours was a legitimate question that just happened
to be answered previously.  Debian-legal has a very long "case history",
which is often referenced in future decisions; this approach creates a
steep learning curve for people who just want to send debian-legal a
question.  Regulars have the advantage of knowing more of the context
and therefore being able to search past discussions more effectively.

As for the proliferation of hardware with non-free firmware, that is
highly unfortunate, but it seems as though it may continue for the near
future; hopefully this problem will be avoidable eventually, either
through more "open" hardware or through replacements such as LinuxBIOS.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

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

[John H. Robinson, IV]

I am not subscribed to debian-legal.

Glenn Maynard wrote:
> 
> Consider a major, practical reason we require that packages be buildable
> with free tools: so people--both Debian and users--can make fixes to the
> software in the future.

I agree with this. This is also not the point. You keep talking about
pracakge that can only be built with a non-free compiler. The one in
question can be built with a free or non-free compiler.

> For example, suppose OpenSSL is built with ecc (Expensive C Compiler),
> because it produces faster binaries, the Debian package is created with
> it, and ends up in a stable release.  A security bug is found, and the
> maintainer isn't available.  Can another developer fix this bug?  No:
> you can't possibly make a stable update with a completely different
> compiler, halving the speed and possibly introducing new bugs.  (Debian
> is very conservative and cautious with stable updates; this is one of
> the reasons many people use it.)

Yes. Assuming that OpenSSL will compile properly with both gcc and ecc,
and the source is not using tricks to change functionality when compiled
wiht one or the other. To me, using ecc or gcc is, or at least should
be, similar to using gcc -O1 or gcc -O9.

Similarly, I do not consider a signifcant performance boost to be a
change in functionality. I'm thinking something like this:

#ifdef ecc
// this enables the -S option
#elif defined(gcc)
// remove -S, but add in -o instead
#else
// neither -S nor -o available
#endif

In this case, the compiler used would have a significant change in
functionality, and would require the build-dep on ecc, and would be
contrib at best.

> On the same token, users are similarly unable to exercise the level of
> caution needed when making security updates on critical systems, unless
> they subject themselves to whatever non-free license the compiler uses.

gcc is written under the GPL. I can write a non-free program, keep the
source entirely secret, and distribute my program in binary form only,
with a very restrictive license. The gcc license does not contaminate
the resultant binary (unless, of course, I put gcc code in my program).
Similarly, the ecc license should not prevent compiling GPL'd code. If
it did, ecc would be unsuitable for any purpose, period.

> This is a fundamental reason it's required that packages be buildable
> using free tools, and why I don't think "you can build a kind-of similar
> package using free tools, but the one we're giving you can only be built
> with non-free tools" is acceptable.

Again, if it could only be built properly and working with ecc, I will
happily agree with you until the cows come home to roost. This would be a
long time, as cows donot generally roost.

Specifically, this package could be built with either gcc or icc. I will
accept the argument from a pragmatic standpoint, in as much a bug in icc
would be harder to track down, but not from a ``it is a different
package'' because of using icc instead of gcc.

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  

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

[Matthew Dempsky]

"John H. Robinson, IV" <[EMAIL PROTECTED]> writes:

> This package is buildable by tools in main. It meets the letter of the
> law. The spirit seems a bit ambiguous. Good case in point, the m68k
> cross-compiled stuff, where the cross-compiler used was non-free. (I
> have not verified the accuracy of the non-free claim of the cross-
> compiler)

I don't follow that at all.

As I see it, the "spirit" of the DFSG, Social Contract, and
what-have-you are that Debian's main archive must be able to bootstrap
itself and that packages present in it should have been constructed as
such.  An example was given earlier of another package (openoffice.org
I believe) that supported recompilation using a different JDK.

Also, I presume the cross-compiler they were referring to was gcc (I
don't know of any other i386-hosted, m68k-targeted compilers capable
of building the Linux kernel).

gcc isn't non-free.  icc *is*.

Keeping that in mind *is* in the spirit of Debian.

Also, I wouldn't be surprised to know their gcc cross-compiler was
derived from the toolchain-source package which is in main.

Re: Academic Free License 2.1 -- free or not?

[Arnoud Engelfriet]

Francesco Poli wrote:
> On Sun, 17 Oct 2004 14:56:54 +0200 Arnoud Engelfriet wrote:
> > You're right. The license is intended to be a common-law
> > contract. Hence the phrases about assent. So the idea is that the
> > licensee has agreed to everything in the license.
> 
> Being a common-law-contract is troublesome, for the licensee could
> result in having given up a freedom that he/she had before accepting the
> contract. Even if the triggering clause is subtle and we don't notice
> the issue.

I agree. But Larry Rosen obviously feels differently. I guess he
wants both parties to be bound by the license terms, and that the
license itself should be carefully written to make sure it does not
give up any freedoms.

> > When accepting the terms
> > of the GPL, I also must give up certain rights about warranties that
> > I normally expect to have.
> 
> I didn't see that way: I saw the disclaimer of warranty as a declaration
> (valid even if I don't accept the license and I merely use the piece of
> software without copying, distributing or modifying it).

I think it's a part of the GPL and not just a declaration about a
factual situation. I wonder what warranties I could claim if I
do not accept the license. The software was legally distributed
to me, and that gives me some entitlements under copyright law.

> If the law says the warranty *may* be disclaimed and the software has
> this disclaimer attached, I'm warned that there is no warranty: I loose
> no right in accepting the license, as I didn't have any such right in
> the first place.

I'm not even sure if the issue of warranties is relevant to
freedom of software. Even without any warranty you can always use,
modify and distribute the software.

And if it breaks, not only do you get to keep the pieces,
you get to fix it!

Arnoud

-- 
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/