Re: Copyright notice gives info on source files, not the packaged binaries -is that correct?

[Paul Wise]

On Mon, May 10, 2021 at 2:18 PM Alexander Mazuruk wrote:

> I'm writing this as I've noticed that some packages have copyright file
> filled with records for source code, while the package contains binaries.

Essentially all packages in Debian do this, with a couple of
exceptions where the maintainer thought about this problem already.
For example, for src:libicns I installed different copyright files in
each binary package since the license is different for the library vs
the utilities.

> Shouldn't those package's COPYRIGHT contain info about final license
> that those binaries are distributed with?

In theory yes, in practice, no.

>* yes. -> should I file a bug report for such packages?

The problem is an archive-wide one that is just left unsolved, not one
to be solved in individual packages.

>* no -> how can I know what license a package actually has in such
> case? Are there some officially recommended tools?

It is in theory possible to trace the translation from source to
binary, but in practice it is mostly impossible. Even if you ptrace
the full build process (making it much slower), there is no general
way to determine what file is generated from what other file. Fixing
this would involve adding instrumentation to every compiler, build
system, many different tools and probably lots of Debian packaging and
upstream projects. This is a project on the order of magnitude of
Bootstrappable Builds or Reproducible Builds; a multi-decade-long
effort by many different people. There are potentially benefits to
this beyond copyright/license info correctness for binaries too, so it
would be an interesting project, but it would be hard to convince
entire communities of people to work on this.

In practice, shipping the relevant source for the binaries is likely
enough to achieve license compliance, so shipping pedantically correct
copyright/license info for the binaries is not necessary and shipping
source is much easier to do, so that is what Debian tends to do.

> We are trying to do start license compliance for Docker images and are a
> bit stumped on how to proceed with such packages in Debian-based containers.

I suggest you ship source for all the binary packages used, then add
source for all the packages installed during each of their build
processes. Or just ship a full Debian archive containing every source
package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Copyright notice gives info on source files, not the packaged binaries -is that correct?

[Sam Hartman]

Alexander> I wanted to get some clarification as I couldnt find this
Alexander> info via googling/debian pages (but I might've missed
Alexander> something obvious, if so - I'd appreciate pointing me in
Alexander> right direction on what should i read)

Under section 2.4 of debian policy, any distribution license that you
are required to comply with needs to be placed in the copyright file in
the binary package.  We do tend to organize license and copyright
information by source because that is convenient to us.  But based on
policy, if you comply with all of the licenses listed in the copyright
file for a given binary package when dealing with binaries in that
package, that would be a conservative approach to take.

In particular if because of a build dependency a binary required
additional license restrictions to be followed beyond the licenses of
its source, my reading of policy is that needs to be mentioned in
debian/copyright.
Failing to do so sounds like a bug to me.

Admittedly, that corner case sounds like one we didn't consider
thoroughly in our machine-readable copyright file spec.

Obviously there are cases where by interpreting the copyright in a finer
grain manner, you could discover situations where your license
compliance obligations are less.
As an example, if only some of the binary packages built from a given
source package are under a copyleft license, handling modifications
might be easier.

It's true that our current approach to managing license information does
not make that easy to discover.
That's not a bug, although obviously you could discuss whether improving
that would be a welcome feature change.

Copyright notice gives info on source files, not the packaged binaries -is that correct?

[Alexander Mazuruk]

Hello,


I'm writing this as I've noticed that some packages have copyright file 
filled with records for source code, while the package contains binaries.

I've CCd maintainer of one of such packages (bsdutils)


I wanted to get some clarification as I couldnt find this info via 
googling/debian pages (but I might've missed something obvious, if so - 
I'd appreciate pointing me in right direction on what should i read)


Shouldn't those package's COPYRIGHT contain info about final license 
that those binaries are distributed with?

   * yes. -> should I file a bug report for such packages?

   * no -> how can I know what license a package actually has in such 
case? Are there some officially recommended tools?
     is there some other place where the actual pkg license 
should reside?


We are trying to do start license compliance for Docker images and are a 
bit stumped on how to proceed with such packages in Debian-based containers.


Best Regards

Alexander Mazuruk

Open source files without copyright holder

[Benjamin Drung]

[ Note the cross-posting... ]

Hi debian-legal,

The COPYING.md file of rdma-core [1] says: "Refer to individual files
for information on the copyright holders." but some files (e.g.
ibacm/man/ibacm.1) do not specify a copyright holder. The copyright
holder grants the user additional rights by putting the code under a
open source license. Is it okay to benefit from these rights without
knowing the copyright holder? How could someone verify that the
copyright claim is correct?

If not, please ensure that every file has specified a copyright holder
(or having a default copyright holder).

[1] https://github.com/linux-rdma/rdma-core/blob/master/COPYING.md

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
Web: https://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Achim Weiss.

Re: Source files

[Riley Baird]

On Mon, 26 Oct 2015 23:06:25 +0100
Francesco Poli  wrote:

> On Fri, 23 Oct 2015 12:13:52 +1100 Riley Baird wrote:
> 
> [...]
> > But even if the person who wrote a program wrote it in such a way that
> > it was unreasonably difficult to understand (something which is very
> > unlikely), then we must say that that, even though no better form of
> > modification ever existed, it is non-free.
> 
> Then I am afraid we will have to agree to disagree: I am convinced that
> a program cannot be considered non-free just because it is difficult to
> understand.

Okay, I guess we will.


pgpVCN_hzlkAa.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Fri, 23 Oct 2015 12:13:52 +1100 Riley Baird wrote:

[...]
> But even if the person who wrote a program wrote it in such a way that
> it was unreasonably difficult to understand (something which is very
> unlikely), then we must say that that, even though no better form of
> modification ever existed, it is non-free.

Then I am afraid we will have to agree to disagree: I am convinced that
a program cannot be considered non-free just because it is difficult to
understand.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpzrehCLmJae.pgp
Description: PGP signature

Re: Source files

[Riley Baird]

> > Being insecure shouldn't be a reason for a program to be declared
> > non-free, but being unreasonably difficult to understand should be.
> 
> Not if the program is difficult to understand even for its
> maintainers...

A program will never be *unreasonably* difficult to understand for its
maintainers. A program that is unreasonably difficult to understand
cannot have maintainers as such because being a maintainer involves
bug-fixing, and bug-fixing requires non-trivial modifications to be
made.

But even if the person who wrote a program wrote it in such a way that
it was unreasonably difficult to understand (something which is very
unlikely), then we must say that that, even though no better form of
modification ever existed, it is non-free.

> > 
> > Otherwise, the distinction between proprietary and open-source would
> > be academic, both users and developers seeing no practical difference
> > between the two.
> 
> The difference is that a program where the source is kept secret is
> difficult to understand for everyone, except for its developers.
> A program where the former source got lost, instead, is difficult to
> understand for everyone, without exceptions: nobody has the monopoly of
> a secret that helps him/her to understand/audit/modify the program.

Someone not having a monopoly on a secret may be necessary for a
program to be free, but it is not sufficient.


pgpHJijEhZgwU.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Tue, 20 Oct 2015 18:17:31 +1100 Riley Baird wrote:

> On Mon, 19 Oct 2015 22:43:59 +0200
> Francesco Poli  wrote:
> 
> > On Mon, 19 Oct 2015 11:00:19 +1100 Riley Baird wrote:
> > 
> > [...]
> > > We can declare that the source did exist, but it doesn't anymore.
> > 
> > I don't think so.
> 
> Why not? "The preferred form of modification among those that have
> existed" is just as good as "The preferred form of modification among
> those that currently exist".

Yearning for forms that have existed in the past, but no longer exist
now, is not too useful.
It is similar to yearning for forms that do not exist and have never
existed.

Hence I don't agree that it is "just as good" as choosing which form is
preferred among those that currently exist.

[...]
> > a program should *not* be declared non-free, just
> > because it is insecure or difficult to audit.
> 
> Being insecure shouldn't be a reason for a program to be declared
> non-free, but being unreasonably difficult to understand should be.

Not if the program is difficult to understand even for its
maintainers...

> 
> Otherwise, the distinction between proprietary and open-source would
> be academic, both users and developers seeing no practical difference
> between the two.

The difference is that a program where the source is kept secret is
difficult to understand for everyone, except for its developers.
A program where the former source got lost, instead, is difficult to
understand for everyone, without exceptions: nobody has the monopoly of
a secret that helps him/her to understand/audit/modify the program.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpmqgnkcXJ4h.pgp
Description: PGP signature

Re: Source files

[Riley Baird]

On Mon, 19 Oct 2015 22:43:59 +0200
Francesco Poli  wrote:

> On Mon, 19 Oct 2015 11:00:19 +1100 Riley Baird wrote:
> 
> [...]
> > We can declare that the source did exist, but it doesn't anymore.
> 
> I don't think so.

Why not? "The preferred form of modification among those that have
existed" is just as good as "The preferred form of modification among
those that currently exist".
 
> > People use open-source software for a variety of reasons. Some people
> > use it for security reasons. Auditing a program where all copies of the
> > C++ source no longer exist is exactly as difficult as auditing the
> > program where all copies of the C++ source are kept secret by the
> > maintainer.
> 
> This may be true, but a program should *not* be declared non-free, just
> because it is insecure or difficult to audit.

Being insecure shouldn't be a reason for a program to be declared
non-free, but being unreasonably difficult to understand should be.

Otherwise, the distinction between proprietary and open-source would
be academic, both users and developers seeing no practical difference
between the two.


pgpfYFc2TfTco.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Mon, 19 Oct 2015 11:00:19 +1100 Riley Baird wrote:

[...]
> We can declare that the source did exist, but it doesn't anymore.

I don't think so.

> 
> People use open-source software for a variety of reasons. Some people
> use it for security reasons. Auditing a program where all copies of the
> C++ source no longer exist is exactly as difficult as auditing the
> program where all copies of the C++ source are kept secret by the
> maintainer.

This may be true, but a program should *not* be declared non-free, just
because it is insecure or difficult to audit.

There are examples out there of DFSG-free programs which are not as
well written as one would desire, but this does *not* mean those
programs are non-free: of course, you may decide to avoid them like the
plague, because you don't feel safe with them. That may be perfectly
legitimate and reasonable, for some cases, but I would not call those
programs non-free, just insecure and/or badly written...

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp9YfGq2pbFf.pgp
Description: PGP signature

Re: Source files

[Riley Baird]

> > > One completely different thing is when nobody has some form of
> > > the work any longer. That form cannot be preferred for making
> > > modifications, since it no longer exists. In this case, the actual
> > > source is the preferred form for making modifications, among the
> > > existing ones.
> > 
> > I write a program in C++ and release the binaries under a free license.
> > The binaries are not the source form. But five years later, when I lose
> > the USB which contained the only copy of the C++ code, the binaries
> > become source.
> 
> If the (previously existing) source is really lost, what else can we do?
> We have to choose which form is preferred *among the existing ones*.

We can declare that the source did exist, but it doesn't anymore.

People use open-source software for a variety of reasons. Some people
use it for security reasons. Auditing a program where all copies of the
C++ source no longer exist is exactly as difficult as auditing the
program where all copies of the C++ source are kept secret by the
maintainer.


pgpetyggrvUSM.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Thu, 15 Oct 2015 08:57:47 +0900 Charles Plessy wrote:

> Le Wed, Oct 14, 2015 at 11:47:02PM +0200, Francesco Poli a écrit :
> > 
> > I am personally convinced that nowadays the definition of source should
> > *no longer* be regarded as an open question: I think that the most
> > commonly used and accepted definition of source code is the one found
> > in the GNU GPL license.
> 
> Hi Francesco and everybody,
> 
> sorry for drifting that thread further... I can not help adding that, the 
> world
> being in perpetual change, the definition of source will one day become an 
> open
> question again.  My favorite guess is that at some point, it will be argued
> that the commit messages and the revisions of a file are part the source, 
> since
> inspecting them is part of the "preferred" way to modify the file.  But we are
> not there yet...

It may happen in the future, maybe, but please note that it would again
be the "preferred form for making modifications" definition of source.
The only thing that would change is people's preferences...

Anyway, as you say, we are not there yet.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpNedUHvA52e.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Thu, 15 Oct 2015 09:12:21 +0200 Ole Streicher wrote:

[...]
> Yes, this is a nice summary. Thank you very much;

You're welcome!

> would it be possible
> to add it somewhere to Debian (Wiki or so?)

I tend to avoid the Debian Wiki, because it is a licensing mess: almost
nobody cares about adding licensing info to the pages that are created
(in order to make them DFSG-free), hence every Wiki user has the
technical possibility to modify pages, but no legal permission to do so!
I think this is terrible, especially for a project like Debian, which
is *supposed* to care about software freedom, but then *so often*
forgets about it...   :-(

See


for the details.
Among other things, the bug report has been even closed with wrong and
rambling considerations... I think that it should be reopened.

> And (unrelated to Debian)
> may it be possible to submit to the FSF for inclusion? It actually would
> help much for discussion with some upstream about what they are required
> to release.
[...]

I really doubt the FSF would agree with my point of view, especially
with my opinion on applying the same freedom standards to all types of
works, rather than distinguishing programs, documentation, essays,
artistic works, and so forth...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpw8NBaltnFM.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Thu, 15 Oct 2015 09:02:08 +0200 Vincent Bernat wrote:

>  ❦ 15 octobre 2015 10:26 +1100, Ben Finney  :
[...]
> > There are many cases that are clarified by that
> > definition, to the point of clear resolution.
> 
> The recent discussions on debian-devel@ shows that not everybody agree
> with this definition. Notably, several persons think the source code for
> one project should depend on the user, not on the developer.

Maybe I am misunderstanding you here (I have not read the debian-devel
discussions), but this sounds like a really harmful definition of
source: let's suppose you write a program in C and release the C code
under a DFSG-free license; after that, one user insists that he/she
prefers COBOL over C, and thus he/she claims you have not distributed
source code, unless you make COBOL code available! Your program is
therefore non-free!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp59Ru7Iiw9W.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Thu, 15 Oct 2015 09:50:06 +1100 Riley Baird wrote:

> On Wed, 14 Oct 2015 23:47:02 +0200
> Francesco Poli  wrote:
[...]
> > For further details on what I think about the definition of source,
> > anyone interested may read my essay:
> > http://www.inventati.org/frx/essays/softfrdm/whatissource.html
> 
> That's a good essay! Hopefully, something like that will become the
> reference that Debian actually uses in the future.

I am glad you and other people liked it.

> 
> I have some concerns, though:

Some of your concerns have already received responses from someone
else, but let me reply to the following one.

[...]
> > One completely different thing is when nobody has some form of
> > the work any longer. That form cannot be preferred for making
> > modifications, since it no longer exists. In this case, the actual
> > source is the preferred form for making modifications, among the
> > existing ones.
> 
> I write a program in C++ and release the binaries under a free license.
> The binaries are not the source form. But five years later, when I lose
> the USB which contained the only copy of the C++ code, the binaries
> become source.

If the (previously existing) source is really lost, what else can we do?
We have to choose which form is preferred *among the existing ones*.

One can take the binary executable as source, if he/she prefers to use
that form in order to make modifications to the program.

Another possibility is generating another form from one of the existing
forms (for instance: decompile the binary executable and, possibly,
enhance the result by hand, until it becomes readable enough to be
usefully modified). If the newly created form is preferred over the
other existing forms, then it *is* the new source.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp42gK2wVJlf.pgp
Description: PGP signature

Re: Source files

[Ian Jackson]

Charles Plessy writes ("Re: Source files"):
> sorry for drifting that thread further... I can not help adding
> that, the world being in perpetual change, the definition of source
> will one day become an open question again.  My favorite guess is
> that at some point, it will be argued that the commit messages and
> the revisions of a file are part the source, since inspecting them
> is part of the "preferred" way to modify the file.  But we are not
> there yet...

I'm told that Red Hat make the source code to their kernels available
to their customers only in the form of a tarball plus single giant
patch.  They do not make the git history available.  This is perhaps
because it's convenient for them but probably also because it prevents
anyone else from building on the work they have done to create their
kernels, cherry picking their changes, etc.  It also significantly
hampers anyone trying to derive from their work.

I think that for the Linux kernel, at least, the preferred form for
modification is the git history.  I realise that most people don't
(yet) agree with me; and the implications are nontrivial, so I expect
acceptance of this idea to lag somewhat.

Ian.

Re: Source files

[Ben Finney]

Paul Wise  writes:

> On Mon, Oct 12, 2015 at 5:49 PM, Ole Streicher  wrote:
>
> > https://bugs.debian.org/798900
>
> FYI folks: the outcome of this bug report is that the jQuery
> dataTables plugin has been packaged properly and built from source
> properly using the upstream build system.

Great news, thank you for reporting back!

> This was done by the other person in the thread Sascha Steinbiss, who
> had a different package flagged by lintian because of this long line.
> I believe Sascha also plans to remove the embedded copy of the build
> artefact from the other package where lintian flagged the long line.

Excellent.

-- 
 \ “I have had a perfectly wonderful evening, but this wasn't it.” |
  `\ —Groucho Marx |
_o__)  |
Ben Finney

Re: Source files

[Paul Wise]

On Mon, Oct 12, 2015 at 5:49 PM, Ole Streicher  wrote:

> For one of my packages (python-astropy), I got a Lintian error that it
> would contain a non-source file jquery.dataTables.js. This is mainly
> discussed in a bug report
>
> https://bugs.debian.org/798900

FYI folks: the outcome of this bug report is that the jQuery
dataTables plugin has been packaged properly and built from source
properly using the upstream build system. This was done by the other
person in the thread Sascha Steinbiss, who had a different package
flagged by lintian because of this long line. I believe Sascha also
plans to remove the embedded copy of the build artefact from the other
package where lintian flagged the long line.

https://anonscm.debian.org/cgit/users/sascha-guest/datatables.js.git/

The long line itself is also present in the source of the jQuery
dataTables plugin. I would guess that it is automatically generated by
an IDE or something else (maybe jshint) parsing the other JS files and
inserting the names of global variables from those files. It would be
interesting to find out exactly how it works though. In any case, the
long line turned out to be completely unrelated to the actual problems
found; an embedded copy of a build artefact from a separate project
without the separate project being packaged separately and built from
upstream source using the upstream build system.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Source files

[Ole Streicher]

Ángel González  writes:
> On 15/10/15 00:50, Riley Baird wrote:
>> On Wed, 14 Oct 2015 23:47:02 +0200
>> Francesco Poli  wrote:
>>
>>> The alternatives you propose are vague at best.
>>>
>>> For further details on what I think about the definition of source,
>>> anyone interested may read my essay:
>>> http://www.inventati.org/frx/essays/softfrdm/whatissource.html
>> That's a good essay! Hopefully, something like that will become the
>> reference that Debian actually uses in the future.
> Yes, good work, Francesco.

Yes, this is a nice summary. Thank you very much; would it be possible
to add it somewhere to Debian (Wiki or so?) And (unrelated to Debian)
may it be possible to submit to the FSF for inclusion? It actually would
help much for discussion with some upstream about what they are required
to release.

>> I have some concerns, though:
>>> The preferred form of a work for making modifications to it.
>> This fails to address the issues raised earlier in this thread:
>> What about CVS headers?
> Well, the file with the CVS headers is probably what you would use
> for making modifications.

To actually change the CVS header, "one" (in the definition of Fancescos
FAQ) would prefer to commit the file, which makes this line a
non-source -- here the source is the RCS file in the CVS repository
(which is usually not distributed).

>>> The person whose preference should be taken into account is the
>>> one who last modified the version of the work under consideration.
>>> If he/she prefers to modify the work in a given form, then that
>>> form is the source code for the work.
>> Company A writes a program A* in C++ and gives binaries away under a
>> free license to Person B. Person B has excellent knowledge of how to
>> edit binary executables and changes it to create program B*. It
>> would follow that the binary executable
>> is source.
> Yes. The source for B* is the binary. The source for A* is the C++ files.
> (I added the names above for clarification)
>
> However, that shouldn't lead to the that compiling a program and
> changing two bytes with an hex editor makes the original files no
> longer be “source”.
> In most cases, we should also look at the source of A* when working
> with B*, at least if B* is expected to be free software.

Changing generated files is not so rare and IMO would really cause a
problem. I have a case, where the file still has the header "This file
is generated! Do not edit!" but was edited by upstream, and I am afraid
that this will cause "some" confusion when I upload it to NEW.

>>> One completely different thing is when nobody has some form of
>>> the work any longer. That form cannot be preferred for making
>>> modifications, since it no longer exists. In this case, the actual
>>> source is the preferred form for making modifications, among the
>>> existing ones.
>> I write a program in C++ and release the binaries under a free license.
>> The binaries are not the source form. But five years later, when I lose
>> the USB which contained the only copy of the C++ code, the binaries
>> become source.
> I'm most worried about authors falsely claiming «I lost the source» as
> an excuse for not disclosing them.

Often one sees whether a file is re-generated in the next release or if
it was edited by hand, which would then prove of disprove the author's
claim. I would, however, extend the group who needs "prefers" the
current form of a file towards "the author and other people with enough
knowledge".

I still think that the definition given there is not applicable to data
(the photography example there), but this is a different story.

Best regards

Ole

Re: Source files

[Vincent Bernat]

 ❦ 15 octobre 2015 10:26 +1100, Ben Finney  :

>> > I am personally convinced that nowadays the definition of source
>> > should *no longer* be regarded as an open question: I think that the
>> > most commonly used and accepted definition of source code is the one
>> > found in the GNU GPL license.
>>
>> It is a commonly used and accepted definition, but as evidenced by
>> this conversation and the others which have occurred on Debian
>> recently, it is too vague to be easily applied.
>
> That's not true. There are many cases that are clarified by that
> definition, to the point of clear resolution.

The recent discussions on debian-devel@ shows that not everybody agree
with this definition. Notably, several persons think the source code for
one project should depend on the user, not on the developer.
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Source files

[Riley Baird]

On Thu, 15 Oct 2015 16:05:39 +1100
Ben Finney  wrote:

> Riley Baird 
> writes:
> 
> > Okay, I guess that handling problematic cases by consensus works too.
> > We can intuitively state what is and what is not source in practically
> > all cases, even if we can't give a reason for it.
> 
> We should be able to give good reason for it, we certainly should not
> rely on intuition when it comes to the effects of restrictive laws.

I thought that we were having a discussion about what source code
should be for the purposes of the DFSG, not what source code is for the
purposes of the law.


pgpp3Z6cXf_pY.pgp
Description: PGP signature

Re: Source files

[Ben Finney]

Riley Baird 
writes:

> Okay, I guess that handling problematic cases by consensus works too.
> We can intuitively state what is and what is not source in practically
> all cases, even if we can't give a reason for it.

We should be able to give good reason for it, we certainly should not
rely on intuition when it comes to the effects of restrictive laws.

What we can't do is decide all possible cases in advance. We still need
discussion and reasoned argument.

-- 
 \  “We tend to scoff at the beliefs of the ancients. But we can't |
  `\scoff at them personally, to their faces, and this is what |
_o__) annoys me.” —Jack Handey |
Ben Finney

Re: Source files

[Riley Baird]

On Thu, 15 Oct 2015 10:26:47 +1100
Ben Finney  wrote:

> Riley Baird 
> writes:
> 
> > On Wed, 14 Oct 2015 23:47:02 +0200
> > Francesco Poli  wrote:
> >
> > > I am personally convinced that nowadays the definition of source
> > > should *no longer* be regarded as an open question: I think that the
> > > most commonly used and accepted definition of source code is the one
> > > found in the GNU GPL license.
> >
> > It is a commonly used and accepted definition, but as evidenced by
> > this conversation and the others which have occurred on Debian
> > recently, it is too vague to be easily applied.
> 
> That's not true. There are many cases that are clarified by that
> definition, to the point of clear resolution.
> 
> This is a big improvement over no consensus definition. It is
> demonstrably not “too vague to be easily applied”.
> 
> You may want a definition that is easily applied to *all* problematic
> cases, but that's unattainable I fear. If you're looking for a perfect
> definition of some legal concept, you're dealing with the wrong species.
> 
> Meanwhile, let's use the consesnus definition of “source form of the
> work” which has been very helpful to date. Some problematic cases will
> of course remain, and we will deal with them as they arise.

Okay, I guess that handling problematic cases by consensus works too. We
can intuitively state what is and what is not source in practically all
cases, even if we can't give a reason for it.


pgpt0qzFw4e8t.pgp
Description: PGP signature

Re: Source files

[Charles Plessy]

Le Wed, Oct 14, 2015 at 11:47:02PM +0200, Francesco Poli a écrit :
> 
> I am personally convinced that nowadays the definition of source should
> *no longer* be regarded as an open question: I think that the most
> commonly used and accepted definition of source code is the one found
> in the GNU GPL license.

Hi Francesco and everybody,

sorry for drifting that thread further... I can not help adding that, the world
being in perpetual change, the definition of source will one day become an open
question again.  My favorite guess is that at some point, it will be argued
that the commit messages and the revisions of a file are part the source, since
inspecting them is part of the "preferred" way to modify the file.  But we are
not there yet...

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: Source files

[Ángel González]

On 15/10/15 00:50, Riley Baird wrote:

On Wed, 14 Oct 2015 23:47:02 +0200
Francesco Poli  wrote:


The alternatives you propose are vague at best.

For further details on what I think about the definition of source,
anyone interested may read my essay:
http://www.inventati.org/frx/essays/softfrdm/whatissource.html

That's a good essay! Hopefully, something like that will become the
reference that Debian actually uses in the future.

Yes, good work, Francesco.



I have some concerns, though:

The preferred form of a work for making modifications to it.

This fails to address the issues raised earlier in this thread:
What about CVS headers?

Well, the file with the CVS headers is probably what you would use
for making modifications.



What about patches created using quilt?

quilt is a version control system (in form of patches). IMHO it doesn't
affect for the definition of source. You don't edit the file using quilt,
you use vi, emacs, notepad… and store the changes using quilt, but
you could as well be using tar(1).
The source is the file that you edit. It may be distributed as original
file + a number of patch files, but that's orthogonal.



The person whose preference should be taken into account is the
one who last modified the version of the work under consideration.
If he/she prefers to modify the work in a given form, then that
form is the source code for the work.

Company A writes a program A* in C++ and gives binaries away under a
free license to Person B. Person B has excellent knowledge of how to
edit binary executables and changes it to create program B*. It would follow 
that the binary executable
is source.

Yes. The source for B* is the binary. The source for A* is the C++ files.
(I added the names above for clarification)

However, that shouldn't lead to the that compiling a program and 
changing two bytes with an hex editor makes the original files no longer 
be “source”.
In most cases, we should also look at the source of A* when working with 
B*, at least if B* is expected to be free software.




One completely different thing is when nobody has some form of
the work any longer. That form cannot be preferred for making
modifications, since it no longer exists. In this case, the actual
source is the preferred form for making modifications, among the
existing ones.

I write a program in C++ and release the binaries under a free license.
The binaries are not the source form. But five years later, when I lose
the USB which contained the only copy of the C++ code, the binaries
become source.
I'm most worried about authors falsely claiming «I lost the source» as 
an excuse for not disclosing them.



I'm also not too keen on the last part about space-inefficient form for 
audiovisual works. Which once more shows that software licenses are not 
the best suited license for media files :)

Re: Source files

[Ben Finney]

Riley Baird 
writes:

> On Wed, 14 Oct 2015 23:47:02 +0200
> Francesco Poli  wrote:
>
> > I am personally convinced that nowadays the definition of source
> > should *no longer* be regarded as an open question: I think that the
> > most commonly used and accepted definition of source code is the one
> > found in the GNU GPL license.
>
> It is a commonly used and accepted definition, but as evidenced by
> this conversation and the others which have occurred on Debian
> recently, it is too vague to be easily applied.

That's not true. There are many cases that are clarified by that
definition, to the point of clear resolution.

This is a big improvement over no consensus definition. It is
demonstrably not “too vague to be easily applied”.

You may want a definition that is easily applied to *all* problematic
cases, but that's unattainable I fear. If you're looking for a perfect
definition of some legal concept, you're dealing with the wrong species.

Meanwhile, let's use the consesnus definition of “source form of the
work” which has been very helpful to date. Some problematic cases will
of course remain, and we will deal with them as they arise.

-- 
 \   “Come on, if your religion is so vulnerable that a little bit |
  `\   of disrespect is going to bring it down, it's not worth |
_o__)   believing in, frankly.” —Terry Gilliam, 2005-01-18 |
Ben Finney

Re: Source files

[Riley Baird]

On Wed, 14 Oct 2015 23:47:02 +0200
Francesco Poli  wrote:

> On Wed, 14 Oct 2015 20:43:31 +1100 Riley Baird wrote:
> 
> > > What I meant here is that you should explain a bit what you consider a 
> > > source and what not
> > 
> > This question comes up in so many discussions, we really need to have a
> > definition that we can all live with, record it somewhere and then move
> > on.
> > 
> > I can think of several ideas:
> [...]
> > If you have any other ideas, submit them. If you think that one of
> > these definitions is too vague, explain and suggest an improvement.
> > Also, if you agree with one of these definitions, say so!
> 
> Riley,
> please do not add confusion to the matter.

I wasn't trying to add confusion, sorry if it seemed this way.

> I am personally convinced that nowadays the definition of source should
> *no longer* be regarded as an open question: I think that the most
> commonly used and accepted definition of source code is the one found
> in the GNU GPL license.

It is a commonly used and accepted definition, but as evidenced by this
conversation and the others which have occurred on Debian recently, it
is too vague to be easily applied.

> The alternatives you propose are vague at best.
>
> For further details on what I think about the definition of source,
> anyone interested may read my essay:
> http://www.inventati.org/frx/essays/softfrdm/whatissource.html

That's a good essay! Hopefully, something like that will become the
reference that Debian actually uses in the future.

I have some concerns, though:
> The preferred form of a work for making modifications to it.

This fails to address the issues raised earlier in this thread:
What about CVS headers? What about patches created using quilt?

> The person whose preference should be taken into account is the
> one who last modified the version of the work under consideration.
> If he/she prefers to modify the work in a given form, then that
> form is the source code for the work.

Company A writes a program in C++ and gives binaries away under a
free license to Person B. Person B has excellent knowledge of how to
edit binary executables. It would follow that the binary executable
is source.

> One completely different thing is when nobody has some form of
> the work any longer. That form cannot be preferred for making
> modifications, since it no longer exists. In this case, the actual
> source is the preferred form for making modifications, among the
> existing ones.

I write a program in C++ and release the binaries under a free license.
The binaries are not the source form. But five years later, when I lose
the USB which contained the only copy of the C++ code, the binaries
become source.


pgp31wRmDaOmw.pgp
Description: PGP signature

Re: Source files

[Francesco Poli]

On Wed, 14 Oct 2015 20:43:31 +1100 Riley Baird wrote:

> > What I meant here is that you should explain a bit what you consider a 
> > source and what not
> 
> This question comes up in so many discussions, we really need to have a
> definition that we can all live with, record it somewhere and then move
> on.
> 
> I can think of several ideas:
[...]
> If you have any other ideas, submit them. If you think that one of
> these definitions is too vague, explain and suggest an improvement.
> Also, if you agree with one of these definitions, say so!

Riley,
please do not add confusion to the matter.

I am personally convinced that nowadays the definition of source should
*no longer* be regarded as an open question: I think that the most
commonly used and accepted definition of source code is the one found
in the GNU GPL license.
The alternatives you propose are vague at best.

For further details on what I think about the definition of source,
anyone interested may read my essay:
http://www.inventati.org/frx/essays/softfrdm/whatissource.html


I hope this helps.
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpeBSGOCLz50.pgp
Description: PGP signature

Re: Source files

[Riley Baird]

> What I meant here is that you should explain a bit what you consider a 
> source and what not

This question comes up in so many discussions, we really need to have a
definition that we can all live with, record it somewhere and then move
on.

I can think of several ideas:
1. Source code must not be the output of anything. Everything, however
   trivial or impractical must be generated.
2. Source code must be the preferred form for modification of a work.
   Preferred is from the perspective of the person or people that
   substantially created the work. Generated outputs are okay if they
   are the form which the maintainer actually uses to make
   modifications.
3. Source code is code which a person who has reasonable knowledge of
   the programming language being used would not find it complicated
   to make substantial modifications to. It is immaterial what the
   maintainer actually does.
4. Source code is code which a person who has reasonable knowledge of
   the programming language being used would have the ability to
   understand the general operation of.
5. Source code is that which is not machine code. Obfuscated javascript
   is source code.

If you have any other ideas, submit them. If you think that one of
these definitions is too vague, explain and suggest an improvement.
Also, if you agree with one of these definitions, say so!


pgpP9D1Ex1kxx.pgp
Description: PGP signature

Re: Source files

[Ole Streicher]

On 14.10.2015 10:35, Bastien Roucaries wrote:

Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streicher  a 
écrit :

I am not a specialist at all for Javascript, and all I try is just
to keep a Python package (with a very responsive upstream!) in a
good shape. Unfortunately, nobody with Javascript experience and
also nobody from the Lintian team (who wrote the heuristics to
identify this file as non-source, and also underlined that they
still claim the file to be non-source) took part in the discussion
here so far. It looks a bit weird for me that they create a Lintian
"error" and seem not to have a (even preliminary and discussable)
"source" definition. So, I think that the lintian tag in question
is more a "wild guess" and should be marked as such.


Next Lintian version will count ; and ne more clever.

However line > 512 will be tagged due to regex récursion problèm and
it is totally insane.


What I meant here is that you should explain a bit what you consider a 
source and what not -- here for the discussion, and in the lintian tag 
documentation for the help of the users. Just experimenting some random 
heuristics without a proper definition (at least a working one) is not 
enough to qualify the tag for something other than "experimental", IMO.


Best regards

Ole

Re: Source files

[Bastien Roucaries]

Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streicher  a 
écrit :
>
>
>Am 13.10.2015 um 22:23 schrieb Walter Landry:
>> Ole Streicher  wrote:
>>> Walter Landry  writes:
 Ole Streicher  wrote:
> What are the general guidelines here? Somewhere in written form?
>The
> DFSG does not contain a hint here.
 The rule of thumb that I have seen applied is that 'source' is the
 preferred form of modification for the people making modifications.
 If a person really prefers editing 1400 character lines, then that
>is
 the source.  However, you can not just state that you prefer that.
>>> I'd prefer just to ignore the line: it is a comment line that is not
>>> needed for the functionality, so I see no reason to touch it at all.
>The
>>> only reason to touch it for me would be to delete it.
>> Sorry, I had not noticed that it was a comment.  I am confused as to
>> why it is there.  Do you know why?  Could you get upstream to delete
>> this seemingly useless line?  That would solve your immediate problem
>> and clean up the code.
>
>Upstream included the code on my request as an external source. I think
>it would be not a good idea to ask them for the removal of the line,
>since then their version would deviate from the original source.
>
>I am not a specialist at all for Javascript, and all I try is just to
>keep a Python package (with a very responsive upstream!) in a good
>shape. Unfortunately, nobody with Javascript experience and also nobody
>from the Lintian team (who wrote the heuristics to identify this file
>as
>non-source, and also underlined that they still claim the file to be
>non-source) took part in the discussion here so far. It looks a bit
>weird for me that they create a Lintian "error" and seem not to have a
>(even preliminary and discussable) "source" definition. So, I think
>that
>the lintian tag in question is more a "wild guess" and should be marked
>as such.

Next Lintian version will count ; and ne more clever.

However line > 512 will be tagged due to regex récursion problèm and  it is 
totally insane.


>
>Best regards
>
>Ole

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: Source files

[Ole Streicher]

Am 13.10.2015 um 22:23 schrieb Walter Landry:
> Ole Streicher  wrote:
>> Walter Landry  writes:
>>> Ole Streicher  wrote:
 What are the general guidelines here? Somewhere in written form? The
 DFSG does not contain a hint here.
>>> The rule of thumb that I have seen applied is that 'source' is the
>>> preferred form of modification for the people making modifications.
>>> If a person really prefers editing 1400 character lines, then that is
>>> the source.  However, you can not just state that you prefer that.
>> I'd prefer just to ignore the line: it is a comment line that is not
>> needed for the functionality, so I see no reason to touch it at all. The
>> only reason to touch it for me would be to delete it.
> Sorry, I had not noticed that it was a comment.  I am confused as to
> why it is there.  Do you know why?  Could you get upstream to delete
> this seemingly useless line?  That would solve your immediate problem
> and clean up the code.

Upstream included the code on my request as an external source. I think
it would be not a good idea to ask them for the removal of the line,
since then their version would deviate from the original source.

I am not a specialist at all for Javascript, and all I try is just to
keep a Python package (with a very responsive upstream!) in a good
shape. Unfortunately, nobody with Javascript experience and also nobody
from the Lintian team (who wrote the heuristics to identify this file as
non-source, and also underlined that they still claim the file to be
non-source) took part in the discussion here so far. It looks a bit
weird for me that they create a Lintian "error" and seem not to have a
(even preliminary and discussable) "source" definition. So, I think that
the lintian tag in question is more a "wild guess" and should be marked
as such.

Best regards

Ole

Re: Source files

[Walter Landry]

Ole Streicher  wrote:
> Walter Landry  writes:
>> Ole Streicher  wrote:
>>> What are the general guidelines here? Somewhere in written form? The
>>> DFSG does not contain a hint here.
>>
>> The rule of thumb that I have seen applied is that 'source' is the
>> preferred form of modification for the people making modifications.
>> If a person really prefers editing 1400 character lines, then that is
>> the source.  However, you can not just state that you prefer that.
> 
> I'd prefer just to ignore the line: it is a comment line that is not
> needed for the functionality, so I see no reason to touch it at all. The
> only reason to touch it for me would be to delete it.

Sorry, I had not noticed that it was a comment.  I am confused as to
why it is there.  Do you know why?  Could you get upstream to delete
this seemingly useless line?  That would solve your immediate problem
and clean up the code.

Cheers,
Walter Landry

Re: Source files

[Charles Plessy]

> Charles Plessy  writes:
> > 
> > Maybe the long line was machine-generated at the beginning, but it does not
> > matter anymore.

Le Tue, Oct 13, 2015 at 10:12:07AM +0200, Ole Streicher a écrit :
> 
> Why not? If I take the GPL definition, the question is not whether it is
> actual (and, BTW, also not whether it is automatically generated) but
> what "is preferred" (holy passive) for modification.

Yes, that what I wanted to mean :)  To me, it looks like the file that we are
discussing is the preferred form for modification.

-- 
Charles

Re: Source files

[Ole Streicher]

Charles Plessy  writes:
> Maybe the long line was machine-generated at the beginning, but it does not
> matter anymore.

Why not? If I take the GPL definition, the question is not whether it is
actual (and, BTW, also not whether it is automatically generated) but
what "is preferred" (holy passive) for modification.

> And by the way, while anybody is free to disbelieve that a file is a real
> source file, the only persons whose judgement really matter on that subject 
> are
> the members of the FTP team.

I would guess that the FTP team should have guidelines here, which would
be nice to presented in this discussion.

> So you are free to disagree with random bug reporters, and they are
> free to escalate it if they are not convinced by your arguments,

 which is one of the purposes of this discussion.

> but in the meantime, Debian's point of view is that the file is source
> unless the contrary has been demonstrated, given that it has passed
> the screening of the FTP team when it entered our archive.  You can
> also add Lintian overrides if the Lintian maintainers are uncooperative.

Sure. Actually, I added an overrides here. However, lintian sets some
standards, and they need to be discussed.

Best regards

Ole

Re: Source files

[Ole Streicher]

Ben Finney  writes:
> Ole Streicher  writes:
>> However, it contains one line
>> /*globals $, jQuery,define,_fnExternApiFunc,[...]
>> which is ~1400 characters long and may be automatically inserted.
>
> I would say the test of whether a file is source is whether it can be
> described as “the preferred form of the work for making modifications to
> it”.
>
> If the preferred form for making modifications is to edit some *other*
> file, then re-generate, the generated file is no IMO source for the
> purpose of the DFSG.

This is the case for the CVS/RCS $ Id: $ line, which is actually
generated by committing the edited file to an RCS (,v) file (which is
/different/ from the actual file).

>> The "preferred" in the definition is a bit ambitious -- some people
>> may prefer a different form than others.
>
> Do you mean “ambiguous”? If so, I agree. But that ambiguity does not
> prevent the definition from being quite useful for deciding cases like
> this.

I meant ambigous, sorry. In this case (as in the case of the CVS/RCS Id
line), it is not helping, since some people may prefer not to edit this
line at all: I f.e. would just ignore the line in the Javascript
source, since it does not have a functional influence, and I do not care
about the line at all. Others would like to keep the consistency, as I
would like to do in the case of the CVS/RCS Id. Who is right then?

>> If someone copies a files from somewhere else, and then patches is to
>> fits the local needs: Is the patched file a "source"?
>
> Patching results in a *different* work (and, according to your described
> provenance, the patches result in a derived work of the prior one).
>
> Is the resulting file still one which would be preferred for making
> modifications to that new work?

Not in all cases. One use case would be to bring the file in sync with
the current developments of the original file. For this, I would prefer
patches instead of just the changed file.

> If so, that file is the source for whatever automatically-generated
> form of the work (e.g. compiled binaries) they then produce from that
> source.

The example is not about whether the changes were made manually or
automatically, but about what is preferred to work with. And there are
use cases which would require to have the patches separated (being them
manually generated or not), so by the GPL definition the patched file is
not a source.

>> Someone would probably prefer to have the original file and the patch
>> instead
>
> That would not be the source form of the later (derived) work. You have
> created, in this scenario, two separate works, each of which has a
> distinct source form.

Anyway, I have a use case for the derived work where I would prefer to
have the modifications in form of patches -- which makes the derived
work itself a non-source (since for this use case it is not the
preferred form of modification).

>> What are the general guidelines here? Somewhere in written form? The
>> DFSG does not contain a hint here.
>
> You're right. They're guidelines, and (as you know) the DFSG doesn't
> actually refer to the GPL's definition of source.
>
> The current state of copyright law doesn't allow firm, clearly-defined
> specifications of what is or is not legal; the law is in many ways
> incoherent from a logical perspective.

The question here is not about what is legal, but about what we accept
in Debian. If a file is licenses by BSD, it does not matter whether it
complies to a specific "source" definition to obey this copyright.

Best regards

Ole

Re: Source files

[Ole Streicher]

Walter Landry  writes:
> Ole Streicher  wrote:
>> What are the general guidelines here? Somewhere in written form? The
>> DFSG does not contain a hint here.
>
> The rule of thumb that I have seen applied is that 'source' is the
> preferred form of modification for the people making modifications.
> If a person really prefers editing 1400 character lines, then that is
> the source.  However, you can not just state that you prefer that.

I'd prefer just to ignore the line: it is a comment line that is not
needed for the functionality, so I see no reason to touch it at all. The
only reason to touch it for me would be to delete it.

> So if a file is generated mechanically, whatever scripts that generate
> the file are the 'source'.  However, if someone actually edited the
> 1400 character line, then it could become 'source'.

Similarly, one could patch a binary executable with a  hex editor :-)

> I have not seen the example of CVS status lines before.  I think
> Debian generally ignores that kind of technical violation because
>
> 1) CVS is free software
> 2) Those lines are not critical to functionality.
> 3) The lines are very short and not difficult to modify.

If you want to keep consistency, it is actually difficult to impossible:
The $ Id: $ line is created from the RCS file from the CVS server which
is usually missing in the sources. Generally, one would "prefer" not to
touch this line at all, but to interact with the CVS server -- which is
not possible since the CVS tree is not included.

So, there is no difference to the long line from the questioned file:
without keeping consistency, editing is simple (and both have no
influence on the functionality), but if you want to keep the consistency
(and some people would *prefer* that), it is difficult to impossible.

So, strictly speaking, CVS (or RCS, or SVN) autogenerated lines are not
source and should not exist in Debian sources, right?

Best regards

Ole

Re: Source files

[Charles Plessy]

Le Mon, Oct 12, 2015 at 11:49:03AM +0200, Ole Streicher a écrit :
> 
> For one of my packages (python-astropy), I got a Lintian error that it
> would contain a non-source file jquery.dataTables.js. This is mainly
> discussed in a bug report
> 
> https://bugs.debian.org/798900
> 
> however it seems that the problem is more general. The python-astropy
> package indeed contains a file jquery.dataTables.js, which for me,
> however, looks like a good source: It is well readable, it contains
> comments, etc.:
> 
> https://sources.debian.net/src/python-astropy/1.0.4-1/astropy/extern/js/jquery.dataTables.js/
> 
> However, it contains one line
> 
> /*globals $, jQuery,define,_fnExternApiFunc,[...]
> 
> which is ~1400 characters long and may be automatically inserted. This
> line is now taken by lintian as indication that the file is not a source
> file. Aside from the question whether this heuristics is too simple, I
> am now curious on how a "source" is defined in the Debian context. Is it
> f.e. required that every single character was inserted manually? Or that
> at least some of the content was created manually?

Hi Ole,

looking at the upstream work on GitHub 
(https://github.com/DataTables/DataTablesSrc),
I see that the long line is changed from time to time in commits that change
other lines as well.  Therefore, it does not look like jquery.dataTables.js is
an autogenerated file.

Maybe the long line was machine-generated at the beginning, but it does not
matter anymore.  By all means, the file is regularly edited like any as a
source file.

And by the way, while anybody is free to disbelieve that a file is a real
source file, the only persons whose judgement really matter on that subject are
the members of the FTP team.  So you are free to disagree with random bug
reporters, and they are free to escalate it if they are not convinced by your
arguments, but in the meantime, Debian's point of view is that the file is
source unless the contrary has been demonstrated, given that it has passed the
screening of the FTP team when it entered our archive.  You can also add
Lintian overrides if the Lintian maintainers are uncooperative.

Thanks for your hard work, and have a nice day,

Charles Plessy

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: Source files

[Ben Finney]

Ole Streicher  writes:

> However, it contains one line
>
> /*globals $, jQuery,define,_fnExternApiFunc,[...]
>
> which is ~1400 characters long and may be automatically inserted.

If it's automatically inserted into that file, that seems to entail the
resulting file is not the source but is instead automatically generated
from the *actual* source.

> Can a generated file be a source at all?
>
> The only definition I know about what is a source is from GPL:
>
> | The “source code” for a work means the preferred form of the work for
> | making modifications to it.

I would say the test of whether a file is source is whether it can be
described as “the preferred form of the work for making modifications to
it”.

If the preferred form for making modifications is to edit some *other*
file, then re-generate, the generated file is no IMO source for the
purpose of the DFSG.

> The "preferred" in the definition is a bit ambitious -- some people
> may prefer a different form than others.

Do you mean “ambiguous”? If so, I agree. But that ambiguity does not
prevent the definition from being quite useful for deciding cases like
this.

> And, autogenerated lines (like the CVS Id, or the signature in
> debian/changelog) are preferred not not be changed at all by a third
> party. Would that make these files non-source?

The question of “preferred form of the work for making modifications” is
still useful in that case, IMO.

If the file into which the chunk of text is inserted remains the
preferred form for making modifications to the work, then that file is
part of the source form of the work.

> If someone copies a files from somewhere else, and then patches is to
> fits the local needs: Is the patched file a "source"?

Patching results in a *different* work (and, according to your described
provenance, the patches result in a derived work of the prior one).

Is the resulting file still one which would be preferred for making
modifications to that new work? If so, that file is the source for
whatever automatically-generated form of the work (e.g. compiled
binaries) they then produce from that source.

> Someone would probably prefer to have the original file and the patch
> instead

That would not be the source form of the later (derived) work. You have
created, in this scenario, two separate works, each of which has a
distinct source form.

> What are the general guidelines here? Somewhere in written form? The
> DFSG does not contain a hint here.

You're right. They're guidelines, and (as you know) the DFSG doesn't
actually refer to the GPL's definition of source.

The current state of copyright law doesn't allow firm, clearly-defined
specifications of what is or is not legal; the law is in many ways
incoherent from a logical perspective.

The ever-changing capabilities of what modifications are feasible and
what works can be combined, and how they can be combined, also thwarts
efforts to make an enduring set of guidelines that remain relevant as
technology changes.

We can only attempt to predict, based on ways copyright cases have been
observed to behave, and based on the published general advice of legal
experts, what are the likely risks and benefits of certain actions.

-- 
 \  “Any intelligent fool can make things bigger and more complex… |
  `\It takes a touch of genius – and a lot of courage – to move in |
_o__)the opposite direction.” —Albert Einstein |
Ben Finney

Re: Source files

[Walter Landry]

Ole Streicher  wrote:
> What are the general guidelines here? Somewhere in written form? The
> DFSG does not contain a hint here.

The rule of thumb that I have seen applied is that 'source' is the
preferred form of modification for the people making modifications.
If a person really prefers editing 1400 character lines, then that is
the source.  However, you can not just state that you prefer that.  We
reserve the right to not believe you.  Otherwise, proprietary software
vendors could state the the binary is the 'source'.

So if a file is generated mechanically, whatever scripts that generate
the file are the 'source'.  However, if someone actually edited the
1400 character line, then it could become 'source'.

I have not seen the example of CVS status lines before.  I think
Debian generally ignores that kind of technical violation because

1) CVS is free software
2) Those lines are not critical to functionality.
3) The lines are very short and not difficult to modify.

Cheers,
Walter Landry

Source files

[Ole Streicher]

Hi,

For one of my packages (python-astropy), I got a Lintian error that it
would contain a non-source file jquery.dataTables.js. This is mainly
discussed in a bug report

https://bugs.debian.org/798900

however it seems that the problem is more general. The python-astropy
package indeed contains a file jquery.dataTables.js, which for me,
however, looks like a good source: It is well readable, it contains
comments, etc.:

https://sources.debian.net/src/python-astropy/1.0.4-1/astropy/extern/js/jquery.dataTables.js/

However, it contains one line

/*globals $, jQuery,define,_fnExternApiFunc,[...]

which is ~1400 characters long and may be automatically inserted. This
line is now taken by lintian as indication that the file is not a source
file. Aside from the question whether this heuristics is too simple, I
am now curious on how a "source" is defined in the Debian context. Is it
f.e. required that every single character was inserted manually? Or that
at least some of the content was created manually?

Is it acceptable that a line (or several lines) are automatically
handled by the editor (Emacs could do that, f.e.)?

Is it acceptable that a line (or several lines) are handled by external
scripts? What about the signature lines, for example in
debian/changelog? They are usually handled by dch, not by a human -- are
they to be considered as non-source?

What about lines that hare handled by CVS? 

/* $Id: capi.h,v 1.4.6.1 2001/09/23 22:25:05 kai Exp $

is obviously not added manually.

Can a generated file be a source at all?

The only definition I know about what is a source is from GPL:

| The “source code” for a work means the preferred form of the work for
| making modifications to it.

This says nothing about manually created or generated.

The "preferred" in the definition is a bit ambitious -- some people may
prefer a different form than others. And, autogenerated lines (like the
CVS Id, or the signature in debian/changelog) are preferred not not be
changed at all by a third party. Would that make these files non-source?

If someone copies a files from somewhere else, and then patches is to
fits the local needs: Is the patched file a "source"? Someone would
probably prefer to have the original file and the patch instead -- or at
least the source file additionally to the patched one. I have, however,
a few packages which contain a modified file, and where the original one
is not available anymore (since it is >15 years old). At least, I would
strongly prefer to have this in the form "original file + patch", since
then I could see what was changed, and possibly replace these files with
the package where they come from, or at least update them to the current
version. Are these modified files to be considered as non-source, and
therefore the package undistributable?

Finally the question is how one can decide whether a file is "source":
Even if it is completely autogenerated, if the maintainer finds the file
as usable for modifications, why should it then not be marked as
"source"? Shall he hunt of whether a piece of code was inserted by a
non-human? Shall he require that all original (unchanged) files are
included as well?

What are the general guidelines here? Somewhere in written form? The
DFSG does not contain a hint here.

Best regards

Ole

Re: Missing licenses in upstream source files

[Ben Finney]

"Giacomo A. Catenazzi"  writes:

> Ben Finney wrote:
> 
> > Too often, though, such files are a set of license *terms* only
> > (e.g. the text of the GPL), with no copyright status or explicit
> > *grant* of license. That's not enough for Debian to know the
> > rights of recipients: mere inclusion of license terms is not a
> > grant of license under those terms.
> 
> I don't agree. Only in journals you will find copyright notice and
> author on every pages. Don't mean that there are copyright problem
> on my favorite book, in inner pages. I think it the same for
> sources. You could write the license (or a reference) on every file,
> or you could write only a general file (e.g. COPYING), if it is
> clear that the license cover all the files. This is true
> particularly for small programs. On large programs or when there are
> multiple licenses I recommend upstreams to put a copyright notice
> and license for every important file (i.e. sources and non-trivial
> header files).

Since this concurs with what I said, it seems we agree. I don't know
who you're disagreeing with, but I'm glad we're of the same opinion.

-- 
 \“When you go in for a job interview, I think a good thing to |
  `\  ask is if they ever press charges.” —Jack Handey |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Missing licenses in upstream source files

[Bernhard R. Link]

* Giacomo A. Catenazzi  [090320 10:08]:
> >Too often, though, such files are a set of license *terms* only (e.g.
> >the text of the GPL), with no copyright status or explicit *grant* of
> >license. That's not enough for Debian to know the rights of
> >recipients: mere inclusion of license terms is not a grant of license
> >under those terms.
>
> I don't agree. Only in journals you will find copyright notice and author
> on every pages.  Don't mean that there are copyright problem
> on my favorite book, in inner pages. I think it the same for sources.
> You could write the license (or a reference) on every file, or you could
> write only a general file (e.g. COPYING), if it is clear that the
> license cover all the files.

While I agree that a single licence grant suffices, two limitations:

1) The grant should be in a form that it is reasonable to believe it
fits two the whole content:

a) simply a COPYING file in the tarball with the GPL in it does not
suffice, and especially not if the package uses autotools. As when those
are called the wrong way (i.e. without arguments), they just copy the
file in. Also in other cases just copying a license file in is hard to
take as an grant of an license, a little sentence above the license or
in the documentation or somewhere else like "this program is available
under " is a grant in my non-lawyerish eyes.

b) when package contains materials from obviously different origin[1], it
is far too likely that something went wrong upstream, so better ask
for clarification.

2) When being in upstream role or making suggestions to upstream,
please choose the "one license grant per non-trivial file" approach.
It makes lives easier for all people much easier. Especially as code
tends to hitch-hike in other programs. When you then have some code
that every search engine shows you is copied from somewhere else, but
you do not know where it origins from or if it actually has a free
license, things get ugly...

Hochachtungsvoll,
Bernhard R. Link

[1] like sources with different coding style, or code and other things
like images and so on.


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Missing licenses in upstream source files

[Giacomo A. Catenazzi]

Ben Finney wrote:
[note: quotations in random order]


(We're now in ‘debian-legal’ territory; please follow up there.)




Too often, though, such files are a set of license *terms* only (e.g.
the text of the GPL), with no copyright status or explicit *grant* of
license. That's not enough for Debian to know the rights of
recipients: mere inclusion of license terms is not a grant of license
under those terms.


I don't agree. Only in journals you will find copyright notice and author
on every pages.  Don't mean that there are copyright problem
on my favorite book, in inner pages. I think it the same for sources.
You could write the license (or a reference) on every file, or you could
write only a general file (e.g. COPYING), if it is clear that the
license cover all the files.  This is true particularly for small programs.
On large programs or when there are multiple licenses I recommend upstreams
to put a copyright notice and license for every important file (i.e.
sources and non-trivial header files).

IANAL, but other contributors are not listed in the "legal header",
but still copyright owner, so the same assumptions we do:
"not all contributor are listed, and same license as top header" we could
do the same assumptions for file without explicit legal notice (but
with a top level license and an AUTHOR-like file).

See below:

> What is needed is an explicit copyright notice and grant of license.
> An example:
>
> Copyright 2009 Ben Finney 
> You have permission to copy, modify, and redistribute under the
> terms of the WTFPL. For full license terms, see LICENSE.txt.
>
> That is, we need the copyright status (who holds it, when did it
> begin) and explicit grant of license (what the recipient is permitted
> to do with the work) to be unambiguous for every part of the work. Or
> in other words, you need enough explicit information, from the
> copyright holder, to write the ‘debian/copyright’ file.
>
> If the referenced file has *all* of that, and every part of the work
> is unambiguously covered by it, it's enough.

There are not such thing as "unambiguous" ;-)

I sent you few patches:
patch A: a patch to correct a typo
patch B: a patch to enhance the WTFP
(code-only patch, without touching the "legal header").
and I did a NMU:
patch C: a not yet defined patch

You (as most of upstream) incorporated patches A and B in your sources,
without further reference (but maybe on a CREDIT file or changelog).

Are you still the only copyright owner? I don't think so.
What license on my modification?  the same license (or public domain?)
If you want to relicense the program to WTFAOPL, did you need my
permission?

A tangent question:
What about patch C: note in debian/copyright I wrote that
packing things are licensed with the WTFPL4
[Note that dh-make on GPL2 only program uses GPL3 for packaging license].
My interpretation is that patch C will have the original license
and only debian/* have the WTFPL4.

ciao
cate


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Missing licenses in upstream source files

[Ben Finney]

(We're now in ‘debian-legal’ territory; please follow up there.)

Dominik Smatana  writes:

> One more "license-newbie" question:
> 
> In some upstream source files there is just one single line comment at
> beginning:
> 
> // Please see included LICENSE.TXT
> 
> licensecheck says "UNKNOWN" of course...
> 
> Is such reference to external file sufficient for source files to be
> packed for Debian?

What is needed is an explicit copyright notice and grant of license.
An example:

Copyright 2009 Ben Finney 
You have permission to copy, modify, and redistribute under the
terms of the WTFPL. For full license terms, see LICENSE.txt.

That is, we need the copyright status (who holds it, when did it
begin) and explicit grant of license (what the recipient is permitted
to do with the work) to be unambiguous for every part of the work. Or
in other words, you need enough explicit information, from the
copyright holder, to write the ‘debian/copyright’ file.

If the referenced file has *all* of that, and every part of the work
is unambiguously covered by it, it's enough.

Too often, though, such files are a set of license *terms* only (e.g.
the text of the GPL), with no copyright status or explicit *grant* of
license. That's not enough for Debian to know the rights of
recipients: mere inclusion of license terms is not a grant of license
under those terms.

-- 
 \  “I hope some animal never bores a hole in my head and lays its |
  `\   eggs in my brain, because later you might think you're having a |
_o__) good idea but it's just eggs hatching.” —Jack Handey |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: 25+2 packages with (Glade) generated C source files without the source

[Ian Jackson]

Others have explained why this is not a critical bug in this specific
case.  (Although as an aside it seems quite incomprehensible to me
that these projects, and Gnome in general, have effectively thrown
away the source!)

But there was one misunderstanding here which I think is important to
correct:

Manterola writes ("Re: 25+2 packages with (Glade) generated C source files 
without the source"):
> On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:
> > [ stuff ]
> 
> No.  .c files are still source code.

This is not correct.  `Source code' means (in the words of the GPL)
the preferred form for modification.  In many programs the .c code is
automatically generated from some other input in the source tree.
Compilers for some languages even work by translating the source code
to C and feeding it to a C compiler.

The output from code generators and language translators is not
source, even though it may be in C (or some other language that humans
sometimes write).  So Sami was right to suspect that there was a
serious problem here and to investigate.

Whether something is source or not cannot be determined simply by
looking at which language it is written in.  The question is: if we
wanted to edit this, which file would we need to change ?

If someone somewhere still has the input file, and is generating new
versions of the output, then the input file is still the preferred
form for modification.  If the input file is completely lost, or the
output file has been directly edited to the point where the input file
is no longer relevant, then the output file has become the source
code.

I would say that _at the time when these projects were first shipped_
in this state, it _was_ a clear violation (both of our principles and
of the GPL) to do so.  If we had noticed at the time that the source
was missing, and insisted that it was provided and that the package
should be built from it, the source would not now be lost.

> We might ask authors to include their .glade files, IF they still have
> them (if they don't, then the .c files have already become the actual
> source code).

If the .glade files can still be found, and the glade2 translator
resurrected and plumbed back into the build system of these programs,
we would be in a much better position.  As Sami says, many of these
programs are effectively immutable because editing the autogenerated C
is impractical.

But that's a lot of work.  I'm not sure it can be done sensibly in
time for lenny.  If such changes _can_ be made in time then they're
probably pretty safe.  After all the output from glade2's code
generator can be compared with the current manually-edited files.  I'm
not sure if the RMs would agree :-).

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 25+2 packages with (Glade) generated C source files without the source

[Sami Liedes]

On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote:
> I’m pretty sure many of the list are in similar cases. Now loading the
> UI directly into the application is the standard, but not so long ago
> people generated template code with glade and then edited it by hand.
> The .glade file was removed simply because it has become irrelevant.

Ok, my bad then. I admit I'm not too familiar with glade, although I
did know that the newest glade does not generate source code (but what
argument is that, this code was obviously generated with glade, the
existence of the newer version wouldn't magically make this the
preferred form of modification, would it!?).

Although I do wonder, since this seems to mean that the interfaces are
(or at least seem to me) quite immutable. For example, take a look at

   http://www.hut.fi/~sliedes/interface.c

which is from the package lopster.

It has a number of functions like create_window() and
create_options_win() which still at least look quite repulsive for any
attempts to make any real or substantive edits to the interface.

For example, the variable declarations in those functions:
create_window() has 541 local variables named like pixmap57, hbox419,
label547, hseparator49, frame 384. create_options_win() has 496. The
code (4710 lines in case of create_window()) doesn't look much more
editable either.

But I do trust you when you say that the "do not edit" note is
obsolete, I just wonder since after a cursory inspection this code
definitely doesn't look like anything I would want to touch to edit a
complex UI :) Of course if they are edited anyway, that might make
them the preferred form of modification.

Thanks for clarifying that, anyway, and sorry for the noise.

Sami


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 25+2 packages with (Glade) generated C source files without the source

[Neil Williams]

On Sat, 2008-08-30 at 23:19 -0300, Margarita Manterola wrote:
> On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:
> > The only questionable case I found
> > by this sampling is dia, where the file is "generated by Glade and
> > then hand-coded to make GNOME optional and add the underline for
> > accelerated buttons".
> 
> And what's there to question, then?
> 
> This is exactly the case I was talking about.  Some people might use
> glade to generate a .c as a starting point, and then continue editing
> the file (or not, but just keep the .c file, once it's been
> generated).  This is perfectly fine, and we do NOT need the .glade
> files used.

(Especially when glade-3 does not actually support generating any C code
or updating the C source code files output by glade-2.)

Any bugs filed so far should be closed forthwith. The comment is old, it
relates to a function of Glade that was removed by Glade upstream and
whether the .glade file is distributed or not, the C can no longer be
generated with the current version of glade.

All this process has really shown is that upstream teams are commonly
lazy about removing old comments. Yawn.

Sorry, Sami, but this was a waste of effort.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: 25+2 packages with (Glade) generated C source files without the source

[Josselin Mouette]

Le dimanche 31 août 2008 à 04:17 +0300, Sami Liedes a écrit :
> I went through some of these and checked them by hand, and generally
> couldn't find the glade project anywhere in the source tarball (it
> might be in the diff, I didn't check for that - would that BTW be OK,
> to have source code in diff only?). The only questionable case I found
> by this sampling is dia, where the file is "generated by Glade and
> then hand-coded to make GNOME optional and add the underline for
> accelerated buttons".

I’m pretty sure many of the list are in similar cases. Now loading the
UI directly into the application is the standard, but not so long ago
people generated template code with glade and then edited it by hand.
The .glade file was removed simply because it has become irrelevant.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: 25+2 packages with (Glade) generated C source files without the source

[Margarita Manterola]

On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:

> I grepped the source tarballs in Lenny (testing) main section for the
> note "DO NOT EDIT THIS FILE - it is generated by Glade." which
> indicates the file is generated using the Glade UI editor. Then I
> checked if these packages have any *.glade* files, which would be the
> Glade projects, i.e. the "source code" (at least in the GPL sense,
> "preferred form of modification") for these. For those of these
> packages for which this is not a false alarm, I believe this would
> fail DFSG #2, and for those being licensed under GPL, it would
> probably make them non-distributable.

No.  .c files are still source code.  And even taking into account the
"DO NOT EDIT THIS FILE" comment, it doesn't clearly mean that the
author of the program necessarily has not edited it.

We might ask authors to include their .glade files, IF they still have
them (if they don't, then the .c files have already become the actual
source code).  But in any case it's not a violation of DFSG #2, since
.c files are still source code.  Bugs like these would be wishlist, at
most.

The "preferred form of modification" for this case is quite relative.
Some people do prefer to edit .c files instead of .glade files,
because you don't need a special tool for that.

> The only questionable case I found
> by this sampling is dia, where the file is "generated by Glade and
> then hand-coded to make GNOME optional and add the underline for
> accelerated buttons".

And what's there to question, then?

This is exactly the case I was talking about.  Some people might use
glade to generate a .c as a starting point, and then continue editing
the file (or not, but just keep the .c file, once it's been
generated).  This is perfectly fine, and we do NOT need the .glade
files used.

-- 
Besos,
Marga


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

25+2 packages with (Glade) generated C source files without the source

[Sami Liedes]

[Note that I'm not subscribed to either d-d or d-legal so if you want
to ask me something, the quickest way is to Cc: me]

Hi,

I grepped the source tarballs in Lenny (testing) main section for the
note "DO NOT EDIT THIS FILE - it is generated by Glade." which
indicates the file is generated using the Glade UI editor. Then I
checked if these packages have any *.glade* files, which would be the
Glade projects, i.e. the "source code" (at least in the GPL sense,
"preferred form of modification") for these. For those of these
packages for which this is not a false alarm, I believe this would
fail DFSG #2, and for those being licensed under GPL, it would
probably make them non-distributable.

I went through some of these and checked them by hand, and generally
couldn't find the glade project anywhere in the source tarball (it
might be in the diff, I didn't check for that - would that BTW be OK,
to have source code in diff only?). The only questionable case I found
by this sampling is dia, where the file is "generated by Glade and
then hand-coded to make GNOME optional and add the underline for
accelerated buttons".

I haven't filed bugs for any of these, save for tangogps which was the
first case I encountered and after which I got the idea to do this.

In addition to the cases I found in main, the packages easyspice and
gtktrain in contrib seem suspect too (but I didn't take such a close
look).

Here's the list of the 25 packages and the relevant source files:


bygfoot
src/support.c
src/misc2_interface.c
src/interface.c
src/misc2_interface.h
src/support.h
src/options_interface.c
src/options_interface.h
src/misc3_interface.c
src/misc_interface.c
src/interface.h
src/misc3_interface.h
src/misc_interface.h

dia
app/sheets_dialog.c: * DO NOT EDIT THIS FILE - it is generated by Glade and 
then hand-coded
app/sheets_dialog.c- * to make GNOME optional and 
add the underline
app/sheets_dialog.c- * for accelerated buttons.
app/sheets_dialog.h

gcompris
src/boards/gtans_support.h
src/boards/gtans_interface.h

gcrontab
gcrontab-0.8.0/src/support.c
gcrontab-0.8.0/src/interface.c
gcrontab-0.8.0/src/support.h
gcrontab-0.8.0/src/interface.h
src/support.c
src/interface.c
src/support.h
src/interface.h
*** NOTE: yes, I did report also the bug that the source is there twice

ggz-gnome-client
motd-editor/interface.c
motd-editor/interface.h
src/support.c
src/profilesi.h
src/support.h
src/msgboxi.c
src/profilesi.c
src/interface.h
src/msgboxi.h

ggz-gtk-games
chess/support.c
chess/support.h
combat/support.c
combat/support.h
dots/support.c
dots/support.h
hastings/support.c
hastings/support.h
reversi/support.c
reversi/support.h

gnusim8085
src/support.c
src/interface.c
src/support.h
src/interface.h

gpe-contacts
support.c
support.h

gsetroot
src/support.c
src/interface.c
src/support.h
src/interface.h

gtans
interface.c
interface.h
support.c
support.h

gtkpool
gtkpool/support.h
gtkpool/support.cpp

hf
hfterm/src/support.c
hfterm/src/support.h

hoz
hozgtk_i.c
hozgtk_i.h
hozgtk_s.c
hozgtk_s.h

kmd
src/breakview.h
src/breakview.c
src/breaksupport.h
src/breaksupport.c

lopster
src/support.c
src/interface.c
src/support.h
src/interface.h

lxappearance
src/glade-support.c
src/demo-ui.h
src/main-dlg-ui.h
src/demo-ui.c
src/main-dlg-ui.c
src/glade-support.h

netmon-applet
interface.c
interface.h
support.c
support.h

prismstumbler
include/support.h
src/support.c

psemu-video-x11
src/support.c
src/interface.c
src/support.h
src/interface.h

tangogps
src/support.h
src/interface.h

teg
client/gui-gnome/interface.h

timemachine
src/support.c
src/support.h

tleenx2
src/support.c
src/interface.c
src/support.h
src/interface.h

trousers
src/tspi/gtk/support.c
src/tspi/gtk/interface.c
src/tspi/gtk/support.h
src/tspi/gtk/interface.h

xwota
src/support.c
src/manual.c
src/query.h
src/station_info.h
src/private_messages.h
src/private_messages.c
src/support.h
src/default_preferences.c
src/xwota_main.c
src/xwota_main.h
src/about.c
src/private_messages_settings.h
src/station_info.c
src/manual.h
src/query.c
src/about.h
src/default_preferences.h
src/private_messages_settings.c


And possibly in contrib:

easyspice
gtktrain

Sami


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbtctl: two questions regarding use of LGPL and GPL in source files

[Nathanael Nerode]

Øystein Gisnås wrote:

> I've gone through license considerations of RFP-marked package
> libbtctl lately, and have questions about two concerns:
> 
> * 7 source files are have LGPL license in their headers, but link
> against bluez-libs, which is licensed under the GPL. One such file
>
ishttp://cvs.gnome.org/viewcvs/libbtctl/src/btctlimpl.c?rev=1.20&view=markup.
> The overall license of libbtctl is GPL. Shouldn't the license in each
> of the 7 source files be changed to GPL since they link against a
> GPL'ed library?

No.  LGPL is approximately equivalent to GPL+LGPL.  The source files are
LGPL (in case someone takes them out and uses them for some other project).
The combination is GPL.

Basically, whenever you add a bit of GPL to an LGPL thing, you get GPL --
but the LGPLed bits remain LGPL in case someone wants to separate them out
and use them for something else.

> 
> * Some source files are LGPL and some are GPL. The end-result library
> is GPL. My conclusion is that this is DFSG compatible. Am I right?
> 
> Cheers,
> Øystein Gisnås

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...

Re: libbtctl: two questions regarding use of LGPL and GPL in source files

[Josselin Mouette]

Le jeudi 28 septembre 2006 à 05:01 +0200, Øystein Gisnås a écrit :
> I've gone through license considerations of RFP-marked package
> libbtctl lately, and have questions about two concerns:
> 
> * 7 source files are have LGPL license in their headers, but link
> against bluez-libs, which is licensed under the GPL. One such file
> ishttp://cvs.gnome.org/viewcvs/libbtctl/src/btctlimpl.c?rev=1.20&view=markup.
> The overall license of libbtctl is GPL. Shouldn't the license in each
> of the 7 source files be changed to GPL since they link against a
> GPL'ed library?

You can do that, but there is no need to do it, as there isn't any
problem with mixing GPL and LGPL code.

> * Some source files are LGPL and some are GPL. The end-result library
> is GPL. My conclusion is that this is DFSG compatible. Am I right?

The end-result is a mix of GPL and LGPL, and practically speaking it has
the effects of the GPL. This is of course perfectly free.

Cheers,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

libbtctl: two questions regarding use of LGPL and GPL in source files

[Øystein Gisnås]

I've gone through license considerations of RFP-marked package
libbtctl lately, and have questions about two concerns:

* 7 source files are have LGPL license in their headers, but link
against bluez-libs, which is licensed under the GPL. One such file
ishttp://cvs.gnome.org/viewcvs/libbtctl/src/btctlimpl.c?rev=1.20&view=markup.
The overall license of libbtctl is GPL. Shouldn't the license in each
of the 7 source files be changed to GPL since they link against a
GPL'ed library?

* Some source files are LGPL and some are GPL. The end-result library
is GPL. My conclusion is that this is DFSG compatible. Am I right?

Cheers,
Øystein Gisnås

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Fri, 29 Jul 2005 15:58:36 +0100 Andrew Suffield wrote:

> > Yes, I think it's time to propose a GR to do a  s/program/work/  in
> > the DFSG. Since IANADD, I cannot propose GRs, but I hope that some
> > DDs will help.
> 
> It's not quite that simple; you can't just change that bit alone. I'm
> working on something here. More on this later.

I'm looking forward to seeing something concrete to discuss about!

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpnI6duGhc2m.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Andrew Suffield]

On Thu, Jul 28, 2005 at 11:47:58PM +0200, Francesco Poli wrote:
> On Thu, 28 Jul 2005 15:00:29 +0100 Steve McIntyre wrote:
> 
> > Florian Weimer wrote:
> [...]
> > >The GR did not change the wording of the DFSG at all.  However, it's
> > >clear that a significant shift took place in SC interpretation, from
> > >a foggy definition of "program" to a more dogmatic "everything we
> > >ship is software" approach.  Our interpretation of the DFSG must
> > >reflect this change.  The only way to do this is to interpret
> > >"progarm" in the broadest possible sense.
> > 
> > Please, no. We've already had long, tedious discussions about what
> > "software" means. Don't go trying to change the meaning of "program"
> > too. If you think that the places where we currently talk about
> > "program" are unclear and should say "software", then propose a GR to
> > get them changed. We ship lots of things that are NOT programs...
> 
> Yes, I think it's time to propose a GR to do a  s/program/work/  in the DFSG.
> Since IANADD, I cannot propose GRs, but I hope that some DDs will help.

It's not quite that simple; you can't just change that bit alone. I'm
working on something here. More on this later.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Brian M. Carlson]

On Thu, 2005-07-28 at 20:08 -0700, Steve Langasek wrote:
> On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote:
> > On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
[argument of program vs. software]
> > If you are only looking at the DFSG, you are missing the point.  The
> > point is that the Social Contract requires that all software in Debian
> > (that is, main) must comply with the Debian Free Software Guidelines.
> > That was the interpretation debian-legal used before last year's GR, and
> > the GR, while editorial, simply made that clearer.
> 
> > Therefore, if the DFSG said that "All ham sandwiches must include source
> > code...", then the Social Contract would still require that all
> > provisions of the DFSG apply to all of main.
> 
> Yes, the DFSG must be applied to everything in main.

So then it must be applied to non-programs as well.

> How do you get from there to "the words 'ham sandwich' must be read as
> 'software'", exactly?

My point was that regardless of the words to be used to describe the
material that the DFSG talks about (in my example, "ham sandwich"), the
Social Contract explicitly applies the DFSG to all works in main (the SC
explicitly uses the word "work").  Because of this, it would be silly to
say that some works require more freedoms than others.

I would say that DFSG 2 should apply to at least documentation, as well
as programs.  My argument goes as follows:  if I write a groff document,
and convert it into HTML with the groff in Debian, it will be
non-standards conformant HTML and pretty crappy HTML in general.  Newer
versions of groff at least fix some of the problems, so it is
conceivable that you might want to reprocess it with groff CVS.  You'd
need the source to do that.  If DFSG 2 should apply to documentation as
well as programs, then why shouldn't it apply to all software?

I might be more persuaded that your interpretation were the case, even
with the Social Contract as it is now, if the text of DFSG 2 were "The
program must include source code... . This section does not apply to
non-programs."  Of course, then we have the definition of program about
which to worry.

Also, nobody has proposed a definition of "program" that is not the same
as "software", in regards to the DFSG.  If you can find one that is
acceptable to at least the ftpmasters (and hopefully debian-legal), then
please state it.

Most likely, someone made an error of precision when writing the DFSG,
as it is common in English to use varying terms to refer to the same
thing and not to repeat words unnecessarily.  Although in this case, as
I said, the authors of the DFSG were imprecise.  They aren't dead, so it
is still possible to ask them what they meant (and I believe this has
already been done).

You also snipped my text about DFSG 6, so I have a question.  Do you
think that DFSG 6 should not apply to all works in main?  Or DFSG 7, 8,
or 9?  If not, why exempt DFSG 2, when there clearly is a definition of
source that can define what the source is for every piece of software?
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: generated source files, GPL and DFSG

[Steve Langasek]

On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote:
> On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
> > I'm arguing with your interpretation of "program" to mean anything you
> > want - in this case potentially any random string of bytes. That most
> > certainly _is_ new, and is completely bogus. As I said, propose a GR
> > to change the wording s/program/software/ of DFSG#2 if you want that
> > meaning. Redefining/reinterpreting commonly-used words is a very good
> > way to alienate people...

> If you are only looking at the DFSG, you are missing the point.  The
> point is that the Social Contract requires that all software in Debian
> (that is, main) must comply with the Debian Free Software Guidelines.
> That was the interpretation debian-legal used before last year's GR, and
> the GR, while editorial, simply made that clearer.

> Therefore, if the DFSG said that "All ham sandwiches must include source
> code...", then the Social Contract would still require that all
> provisions of the DFSG apply to all of main.

Yes, the DFSG must be applied to everything in main.

How do you get from there to "the words 'ham sandwich' must be read as
'software'", exactly?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Brian M. Carlson]

On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
> I'm arguing with your interpretation of "program" to mean anything you
> want - in this case potentially any random string of bytes. That most
> certainly _is_ new, and is completely bogus. As I said, propose a GR
> to change the wording s/program/software/ of DFSG#2 if you want that
> meaning. Redefining/reinterpreting commonly-used words is a very good
> way to alienate people...

If you are only looking at the DFSG, you are missing the point.  The
point is that the Social Contract requires that all software in Debian
(that is, main) must comply with the Debian Free Software Guidelines.
That was the interpretation debian-legal used before last year's GR, and
the GR, while editorial, simply made that clearer.

Therefore, if the DFSG said that "All ham sandwiches must include source
code...", then the Social Contract would still require that all
provisions of the DFSG apply to all of main.

In addition, DFSG 6 and several other DFSG sections apply to "programs".
If you are claiming that suddenly non-program software does not have to
comply with DFSG 6, then we have a problem.

Also, from policy 2.2.1:

 Every package in _main_ and _non-US/main_ must comply with the DFSG
 (Debian Free Software Guidelines).

Note that it does not say: "Only programs in _main_..." or "Every
program in _main_...".  Therefore, it is still a serious bug.

In addition, the etch RC policy requires that:

  All content in main and contrib must meet the DFSG, both in .debs and
  in the source (including the .orig.tar.gz)

I see no support for your opinion in actual, codified Debian policy[0].

[0] By policy, I don't mean just policy.txt.gz; I mean all technical and
non-technical policy documents.
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Thu, 28 Jul 2005 15:00:29 +0100 Steve McIntyre wrote:

> Florian Weimer wrote:
[...]
> >The GR did not change the wording of the DFSG at all.  However, it's
> >clear that a significant shift took place in SC interpretation, from
> >a foggy definition of "program" to a more dogmatic "everything we
> >ship is software" approach.  Our interpretation of the DFSG must
> >reflect this change.  The only way to do this is to interpret
> >"progarm" in the broadest possible sense.
> 
> Please, no. We've already had long, tedious discussions about what
> "software" means. Don't go trying to change the meaning of "program"
> too. If you think that the places where we currently talk about
> "program" are unclear and should say "software", then propose a GR to
> get them changed. We ship lots of things that are NOT programs...

Yes, I think it's time to propose a GR to do a  s/program/work/  in the DFSG.
Since IANADD, I cannot propose GRs, but I hope that some DDs will help.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpV2L7hMdicG.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Jacobo Tarrio]

O Xoves, 28 de Xullo de 2005 ás 16:19:02 +0200, Florian Weimer escribía:

> > I'm arguing with your interpretation of "program" to mean anything you
> > want - in this case potentially any random string of bytes.
> Why do you think this would change anything?  Isn't this the
> assumption under which debian-legal operates in general?  With a few

 No, that's "software", not "program", which is any random string of bytes.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

[Raul Miller]

On 7/28/05, Andreas Barth <[EMAIL PROTECTED]> wrote:
> * Raul Miller ([EMAIL PROTECTED]) [050727 18:45]:
> > On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > I'd prefer to approach this issue from a different direction.
> >
> > The point behind the DFSG is that we need to be able to solve problems
> > in the stuff we distribute.
> 
> Sorry, but I disagree. The point behind the DFSG is that our priorities
> are our users and the free software community, according to our social 
> contract.

Ok, I'll say that more verbosely:

The point behind the DFSG is that we need to be able to solve problems
in the stuff we distribute for our users, and for the benefit of the
free software
community.

Thanks,

-- 
Raul

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Steve McIntyre:

>>Why do you think this would change anything?  Isn't this the
>>assumption under which debian-legal operates in general?  With a few
>>practical exceptions, of course (license texts, public key
>>certificates, etc.), but the general rule seems to be followed.
>
> What?
>
> I'm astounded by your argument here. Go look in a dictionary,
> _please_. "Program" does not mean what you think it means. Re-defining
> a common word like this is not a good route for earning
> credibility.

I'm not redefining anything.  I'm entirely descriptive.  Have a look
at the list archives if you don't believe me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Andreas Barth:

>> > I'm arguing with your interpretation of "program" to mean anything you
>> > want - in this case potentially any random string of bytes.
>  
>> Why do you think this would change anything?  Isn't this the
>> assumption under which debian-legal operates in general?
>
> Actually, it is not the assumption under which the DFSG operates in
> general.

Quite deliberately, I wrote "debian-legal", not "DFSG". 8-)

I don't know much about DFSG interpretation by the people who actually
decide what's DFSG-compliant and what's not.  Maybe their view is
suffficently distinct, but the archive doesn't show it, IMHO.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Steve McIntyre]

On Thu, Jul 28, 2005 at 04:19:02PM +0200, Florian Weimer wrote:
>* Steve McIntyre:
>
>>>The interpretation I outlined is certainly not new.  It reflects the
>>>current practice, and I think we're in a pretty good position as far
>>>as compliance is concerned.  Even the notorious GNU FDL issue is not a
>>>real problem here (beyond the invariant section business) -- the GNU
>>>FDL requires open formats.
>>
>> I'm arguing with your interpretation of "program" to mean anything you
>> want - in this case potentially any random string of bytes.
>
>Why do you think this would change anything?  Isn't this the
>assumption under which debian-legal operates in general?  With a few
>practical exceptions, of course (license texts, public key
>certificates, etc.), but the general rule seems to be followed.

What?

I'm astounded by your argument here. Go look in a dictionary,
_please_. "Program" does not mean what you think it means. Re-defining
a common word like this is not a good route for earning
credibility. If you think DFSG#2 should cover all
programs/software/images/works/whatever, then change it so that it
_does_ say that.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Google-bait:
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Andreas Barth]

* Florian Weimer ([EMAIL PROTECTED]) [050728 16:19]:
> * Steve McIntyre:

> >>The interpretation I outlined is certainly not new.  It reflects the
> >>current practice, and I think we're in a pretty good position as far
> >>as compliance is concerned.  Even the notorious GNU FDL issue is not a
> >>real problem here (beyond the invariant section business) -- the GNU
> >>FDL requires open formats.

> > I'm arguing with your interpretation of "program" to mean anything you
> > want - in this case potentially any random string of bytes.
 
> Why do you think this would change anything?  Isn't this the
> assumption under which debian-legal operates in general?

Actually, it is not the assumption under which the DFSG operates in
general.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Steve McIntyre:

>>The interpretation I outlined is certainly not new.  It reflects the
>>current practice, and I think we're in a pretty good position as far
>>as compliance is concerned.  Even the notorious GNU FDL issue is not a
>>real problem here (beyond the invariant section business) -- the GNU
>>FDL requires open formats.
>
> I'm arguing with your interpretation of "program" to mean anything you
> want - in this case potentially any random string of bytes.

Why do you think this would change anything?  Isn't this the
assumption under which debian-legal operates in general?  With a few
practical exceptions, of course (license texts, public key
certificates, etc.), but the general rule seems to be followed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Steve McIntyre]

Florian Weimer wrote:
>* Andreas Barth:
>
>>> It's clear from the context (and previous discussion) that this has to
>>> be interpreted as "software".
>>
>> I disagree with that. As there were "editorial changes" that had as
>> declared goal to replace any such places with the "real meaning", and
>> this was not touched, it has to be obviously interpreted as program.
>
>After looking at the relevant GR again, I'm convinced that my first
>statement is indeed correct, and that the doubts I expressed in
>another message are unfounded.
>
>The GR did not change the wording of the DFSG at all.  However, it's
>clear that a significant shift took place in SC interpretation, from a
>foggy definition of "program" to a more dogmatic "everything we ship
>is software" approach.  Our interpretation of the DFSG must reflect
>this change.  The only way to do this is to interpret "progarm" in the
>broadest possible sense.

Please, no. We've already had long, tedious discussions about what
"software" means. Don't go trying to change the meaning of "program"
too. If you think that the places where we currently talk about
"program" are unclear and should say "software", then propose a GR to
get them changed. We ship lots of things that are NOT programs...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Welcome my son, welcome to the machine.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Steve McIntyre]

On Thu, Jul 28, 2005 at 04:08:09PM +0200, Florian Weimer wrote:
>* Steve McIntyre:
>
>> Please, no. We've already had long, tedious discussions about what
>> "software" means. Don't go trying to change the meaning of "program"
>> too. If you think that the places where we currently talk about
>> "program" are unclear and should say "software", then propose a GR to
>> get them changed. We ship lots of things that are NOT programs...
>
>Exactly, and we still require that these things are properly licensed
>under some DFSG-free license.
>
>The interpretation I outlined is certainly not new.  It reflects the
>current practice, and I think we're in a pretty good position as far
>as compliance is concerned.  Even the notorious GNU FDL issue is not a
>real problem here (beyond the invariant section business) -- the GNU
>FDL requires open formats.

I'm arguing with your interpretation of "program" to mean anything you
want - in this case potentially any random string of bytes. That most
certainly _is_ new, and is completely bogus. As I said, propose a GR
to change the wording s/program/software/ of DFSG#2 if you want that
meaning. Redefining/reinterpreting commonly-used words is a very good
way to alienate people...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"You can't barbecue lettuce!" -- Ellie Crane


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Steve McIntyre:

> Please, no. We've already had long, tedious discussions about what
> "software" means. Don't go trying to change the meaning of "program"
> too. If you think that the places where we currently talk about
> "program" are unclear and should say "software", then propose a GR to
> get them changed. We ship lots of things that are NOT programs...

Exactly, and we still require that these things are properly licensed
under some DFSG-free license.

The interpretation I outlined is certainly not new.  It reflects the
current practice, and I think we're in a pretty good position as far
as compliance is concerned.  Even the notorious GNU FDL issue is not a
real problem here (beyond the invariant section business) -- the GNU
FDL requires open formats.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Andreas Barth:

>> It's clear from the context (and previous discussion) that this has to
>> be interpreted as "software".
>
> I disagree with that. As there were "editorial changes" that had as
> declared goal to replace any such places with the "real meaning", and
> this was not touched, it has to be obviously interpreted as program.

After looking at the relevant GR again, I'm convinced that my first
statement is indeed correct, and that the doubts I expressed in
another message are unfounded.

The GR did not change the wording of the DFSG at all.  However, it's
clear that a significant shift took place in SC interpretation, from a
foggy definition of "program" to a more dogmatic "everything we ship
is software" approach.  Our interpretation of the DFSG must reflect
this change.  The only way to do this is to interpret "progarm" in the
broadest possible sense.

For practical reasons, we have to exclude license texts from that and
certain copyright banners in About boxes etc., but this does not
change the general direction of interpretation.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

[Andreas Barth]

* Raul Miller ([EMAIL PROTECTED]) [050727 18:45]:
> On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Uh, I don't?  I said that the other guidelines are *applicable* to
> > non-program works, and *should be applied* to non-program works -- not that,
> > as presently written, we are obliged to apply them to non-program works.
> 
> I'd prefer to approach this issue from a different direction.
> 
> The point behind the DFSG is that we need to be able to solve problems
> in the stuff we distribute.

Sorry, but I disagree. The point behind the DFSG is that our priorities
are our users and the free software community, according to our social contract.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

[Raul Miller]

On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Uh, I don't?  I said that the other guidelines are *applicable* to
> non-program works, and *should be applied* to non-program works -- not that,
> as presently written, we are obliged to apply them to non-program works.

I'd prefer to approach this issue from a different direction.

The point behind the DFSG is that we need to be able to solve problems
in the stuff we distribute.

Security fixes are probably the most important, but also important are
porting to
other architectures, making our packages reasonable or at least
plausible to some
significant set of our users, and so on.

The source code requirement is aimed at that issue.  And it can easily apply to
documents (for example, a document spit out by ghostscript is typically not in
its source form)

But... there's all sorts of opinions about what is and is not important, and as
currently written the DFSG doesn't let us assign priorities to things.
 This means
we have difficulty neglecting less important issues in favor of
dealing with more
important issues.

One possibility involves hypothetical situations (new platforms, undiscovered
buffer overruns, and so on).  If we allow ourselves to consider hypothetical
situations we can then ask ourselves -- when is this situation likely
to show up?
What would we have to do to fix this situation? and so on...

In that context, a DFSG violation which would prevent us from fixing a "not 
impossible" grave security bug could be treated as a grave problem.  Likewise,
a DFSG violation which could prevent us from fixing a "wishlist" bug could
be treated as a wishlist problem.

This is a somewhat crude idea -- different people will have different ideas of
what's possible, what's likely and so on.  But I think it's a better system than
what we've got.

The problems we seem to be talking about, at the moment, seem to be more
like "this arguable DFSG violation could prevent us from solving a wishlist
bug in this package", not "this issue which most everyone agrees is a DFSG 
violation could prevent us from solving a critical bug in this package".

Obviously, approaching DFSG issues in this fashion would be a change --
we'd be specifically acknowledging that some things are more important
than other things.  But I don't think this should be too scary, and I do think
that we need to be at least somewhat intelligent in how we approach DFSG
issues.

Thanks,

-- 
Raul

Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

[Steve Langasek]

On Wed, Jul 27, 2005 at 12:28:23AM +0200, Francesco Poli wrote:
> On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote:

> > I think that clauses 6, 7, and 8 are applicable to documentation and
> > data as well as to programs, and I think that they're rules that
> > Debian should follow for everything we distribute.

> > I think that clause 2 is *not* clearly applicable to things that
> > aren't programs.

> I fail to understand how you justify your reading of "program" as
> program in DFSG#2 while you read "program" as work in the other
> guidelines at the same time.

Uh, I don't?  I said that the other guidelines are *applicable* to
non-program works, and *should be applied* to non-program works -- not that,
as presently written, we are obliged to apply them to non-program works.

> IOW, why do you agree with me that the other guidelines must be applied
> to anything in Debian (excluding texts of licenses covering the works,
> as often reminded) and, at the same time, disagree with me on the scope
> of DFSG#2, stating that it applies to programs only.

Because I don't think it makes any *sense* for Debian to apply DFSG#2
as a hard requirement for data?

> Moreover, in the long discussions about the GFDL, the "what is
> software?" tangent came up many many times.
> Several people pointed out that there's no clear line to tell programs
> and non-programs apart: the distinction is blurred (many examples were
> proposed at the time: e.g. PostScript is a Turing-complete programming
> language, literate programming creates works that are both program and
> documentation, ...)

I think it's disingenuous to claim that all PS files are "programs" just
because PostScript is Turing-complete, when the corresponding "source" that
has been mechanically converted into PostScript is not a program at all.

I also think that the lack of a clear binary distinction between programs
and non-programs is not a hindrance here.  I'm not proposing that
non-programs be exempted from complying with the DFSG; I'm observing that
one clause of the DFSG isn't meaningful for non-programs as written, and
twisting it into something that *is* meaningful for non-programs is not
beneficial.  This doesn't mean giving a free pass to literate programming
(I've always felt that if we did have a separate set of guidelines for
documentation, things that are both program and documentation should be held
to *both* sets of guidelines); it does mean coming up with a more sensible
guideline than "this documentation/font is a program because it's
implemented in a Turing-complete language, therefore you must give us the
source for it... even though the 'source' in question isn't implemented in a
Turing-complete language".

> >  Aside from (or perhaps entwined with) the issue of
> > trying to reach a consensus on what constitutes "source" for all of
> > these things,

> which is not so difficult as you seem to imply, IMHO...

Sre, we've just been arguing about it on this list for two solid years
for no reason at all.

> > I think we need to consider what the practical aims are
> > that lead us to insist on the availability of source.

> Are we *again* going to talk about practical points of view? From a
> practical point of view, nVidia proprietary drivers seem to work well
> and make many people happy: are we going to ship them in main?
> I really hope we aren't!

Yes, I guess I should have known better than to suggest on debian-legal that
our standards should have some bearing on reality, shouldn't I?  Since
obviously any such suggestion is equivalent to asking for the inclusion of
the Win2K kernel in main.

> > The ones that strike me as most important are:  being able to
> > recompile the source code for porting (to a different architecture, a
> > different library ABI, etc); being able to fix bugs (and security bugs
> > in particular) in the program; and allowing our users to modify the
> > work to meet their needs.

> Please add
> * avoiding dependence on a single provider

This is only relevant if we accept that there's anything the author is
holding back that leads to a dependence.

> * allowing user to study how the work is created by looking at its
>   internals

Fair enough, though I don't think it applies in all cases and I don't
personally think that this is of prime importance for the works we're
talking about.

> [...]
> > It may be useful to be able to *convert* your data from
> > one form to another, but that's not the same thing as porting; and
> > there may be a particular form that's more convenient for use in
> > converting to other forms, but this may or may not be the "preferred
> > form for modification" which most people seem to be arguing should be
> > the definition of source, so insisting on source code here doesn't
> > ensure that we get this benefit.

> Could you show a concrete practical example in which the "preferred
> form for modification" is *not* the preferred form to start with for
> conversions to other format

Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

[Francesco Poli]

On Wed, 27 Jul 2005 00:28:23 +0200 Francesco Poli wrote:

[some hopefully useful contributions to the discussion, but with *wrong*
Mail-Followup-To:]

Please, ignore the wrong Mail-Followup-To: set in the my previous
message.
I forgot to disable it!  :-(
I really really apologize.

Sylpheed authors should really implement a decent Mail-Followup-To:
handling...  :-(


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp0IbIbxLOu5.pgp
Description: PGP signature

Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]

[Francesco Poli]

On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote:

> I think that clauses 6, 7, and 8 are applicable to documentation and
> data as well as to programs, and I think that they're rules that
> Debian should follow for everything we distribute.
> 
> I think that clause 2 is *not* clearly applicable to things that
> aren't programs.

I fail to understand how you justify your reading of "program" as
program in DFSG#2 while you read "program" as work in the other
guidelines at the same time.
IOW, why do you agree with me that the other guidelines must be applied
to anything in Debian (excluding texts of licenses covering the works,
as often reminded) and, at the same time, disagree with me on the scope
of DFSG#2, stating that it applies to programs only.

Moreover, in the long discussions about the GFDL, the "what is
software?" tangent came up many many times.
Several people pointed out that there's no clear line to tell programs
and non-programs apart: the distinction is blurred (many examples were
proposed at the time: e.g. PostScript is a Turing-complete programming
language, literate programming creates works that are both program and
documentation, ...)
Which criterion are you proposing to tell *when* DFSG#2 must be taken
into account?

>  Aside from (or perhaps entwined with) the issue of
> trying to reach a consensus on what constitutes "source" for all of
> these things,

which is not so difficult as you seem to imply, IMHO...

> I think we need to consider what the practical aims are
> that lead us to insist on the availability of source.

Are we *again* going to talk about practical points of view? From a
practical point of view, nVidia proprietary drivers seem to work well
and make many people happy: are we going to ship them in main?
I really hope we aren't!

> 
> The ones that strike me as most important are:  being able to
> recompile the source code for porting (to a different architecture, a
> different library ABI, etc); being able to fix bugs (and security bugs
> in particular) in the program; and allowing our users to modify the
> work to meet their needs.

Please add
* avoiding dependence on a single provider
* allowing user to study how the work is created by looking at its
  internals


> 
> Well, the first of these isn't applicable to data;

That's true.

[...]
> It may be useful to be able to *convert* your data from
> one form to another, but that's not the same thing as porting; and
> there may be a particular form that's more convenient for use in
> converting to other forms, but this may or may not be the "preferred
> form for modification" which most people seem to be arguing should be
> the definition of source, so insisting on source code here doesn't
> ensure that we get this benefit.

Could you show a concrete practical example in which the "preferred
form for modification" is *not* the preferred form to start with for
conversions to other formats?

> 
> Fixing bugs is important for data as well as for programs, of course;
> though it's much less likely that data or documentation would contain
> a security bug or other RC bug.

So you say that lacking the preconditions for fixing non-RC bugs is
fine...

> But more importantly, the presence or
> absence of true "source" in the case of data and documentation is
> simply not a good proxy for the question of whether we can fix bugs.
> Source v. binary is important for programs, because fixing bugs in the
> machine code for a typical program is several orders of magnitude more
> difficult than fixing the source and recompiling.  This is not the
> case for most data formats! Although there are some opaque
> documentation formats like PDF that are a concern, most data formats
> (especially images and video) are edited directly using binary
> editors;

With no source, how are you going to fix a bug due to the camera
position in a pov-ray generated image?

[...]
> And finally, giving our users the ability to modify data in the same
> manner that the author would is a nice idea, but they only actually
> get this if Debian is going to *distribute* all of those "sources".

That's how it works for programs too...

> Many of these are quite large (much larger than the resulting target
> data files), and there's far from universal agreement that Debian
> *should* distribute all of these pristine sources.

Correct me if I'm wrong: Linux kernel source packages are much larger
than the corresponding vmlinuz images...
Are we going to stop distributing kernel sources?

> I don't think it
> makes any sense to insist that our upstreams make available sources
> that we ourselves are unwilling to commit to distributing.

I think we *should* be willing to distribute source: that's one of the
key elements of free software!

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint 

Re: generated source files, GPL and DFSG

[Steve Langasek]

On Sat, Jul 23, 2005 at 01:01:07AM +0200, Florian Weimer wrote:
> * Steve Langasek:

> >> It's clear from the context (and previous discussion) that this has to
> >> be interpreted as "software".

> > No, it isn't.  Considering we went through all the effort of a GR to amend
> > the DFSG and this still says "program", not "software", I don't see how you
> > can claim it *has* to be read as "software".

> So you think that the DFSG clauses 2, 6, 7, 8 do not apply to
> documentation, only to executables?

> This is certainly an interesting position.  Whether it's a valid one
> is indeed harder to decide than I thought.

I think that clauses 6, 7, and 8 are applicable to documentation and data as
well as to programs, and I think that they're rules that Debian should
follow for everything we distribute.

I think that clause 2 is *not* clearly applicable to things that aren't
programs.  Aside from (or perhaps entwined with) the issue of trying to
reach a consensus on what constitutes "source" for all of these things, I
think we need to consider what the practical aims are that lead us to insist
on the availability of source.

The ones that strike me as most important are:  being able to recompile the
source code for porting (to a different architecture, a different library
ABI, etc); being able to fix bugs (and security bugs in particular) in the
program; and allowing our users to modify the work to meet their needs.

Well, the first of these isn't applicable to data; it's just not meaningful
to talk about "porting" of data (just as this is largely meaningless when
discussing programs written in interpreted languages).  It may be useful to
be able to *convert* your data from one form to another, but that's not the
same thing as porting; and there may be a particular form that's more
convenient for use in converting to other forms, but this may or may not be
the "preferred form for modification" which most people seem to be arguing
should be the definition of source, so insisting on source code here doesn't
ensure that we get this benefit.

Fixing bugs is important for data as well as for programs, of course; though
it's much less likely that data or documentation would contain a security
bug or other RC bug.  But more importantly, the presence or absence of
true "source" in the case of data and documentation is simply not a good
proxy for the question of whether we can fix bugs.  Source v. binary is
important for programs, because fixing bugs in the machine code for a
typical program is several orders of magnitude more difficult than fixing
the source and recompiling.  This is not the case for most data formats!
Although there are some opaque documentation formats like PDF that are a
concern, most data formats (especially images and video) are edited directly
using binary editors; and as for fonts, my personal experience is that
trying to edit them is a PITA regardless of whether you have a "source"
format available. :P

And finally, giving our users the ability to modify data in the same manner
that the author would is a nice idea, but they only actually get this if
Debian is going to *distribute* all of those "sources".  Many of these are
quite large (much larger than the resulting target data files), and there's
far from universal agreement that Debian *should* distribute all of these
pristine sources.  I don't think it makes any sense to insist that our
upstreams make available sources that we ourselves are unwilling to commit
to distributing.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Sun, 24 Jul 2005 03:17:59 -0400 Nathanael Nerode wrote:

> My gut instinct is "no, it's fine, put it in main," because the
> compiler is  not "required" by the system, since the system functions
> fine without  recompiling the graphics (and will continue to).  I may
> be wrong, though!

Huh?
Are you saying that a program can be shipped in main even if it's
written in a language with no DFSG-free compilers?!?

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpLd1bhZpRCW.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Nathanael Nerode]

Andreas Barth wrote:
> > Obviously e.g. fonts are no programms, even if they are in main.
Read TrueType "instructions" and say that again!  Some fonts are most 
certainly programs.

PDFs are arguably executables designed for a PDF interpreter.

But let's not get into that again right now.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:
> However, when I found that (some of) the graphics had a source from which 
they
> could be compiled, I concluded two things:
> - To satisfy the GPL, the source for those graphics needs to be distributed 
as
>   well, so it must be in the source package.
Probably correct.  Also necessary for the DFSG.

Possible exception:
The required *source* is the "preferred form for *modification*".  If you 
would normally want to modify the .xpm files directly, then there is no need 
to include the povray files.  If you would normally want to modify the povray 
files, you need to include them.

> - I don't know if it's actually written anywhere, but I thought everything
>   that has source and can be compiled should be compiled at package build
>   time.  This means the .h-files have to be regenerated (with pov-ray, in 
this
>   case).
Well, this is considered nice, but is not totally mandatory.  Consider the 
case of autoconf-generated "configure" scripts.  They do not have to be 
rebuilt at package build time.  It's considered "nice", but if technical 
reasons discourage it, you don't have to.

> Now that's where the problem starts: pov-ray is in non-free, so any package
> with a Build-depends: on it must be in contrib (if it is itself free).  
True... but you don't need to Build-depends:, as noted above.

The sole question is in the interpretation of the following clause of the 
Social Contract:
"We will never make the system require the use of a non-free component."

The package itself is free as long as the source is included, even if the 
compiler is unavailable, so it satisfies all the *other* requirements of the 
Social Contract.

Does including this package in "main", although certain parts of it cannot be 
recompiled without non-free software, violate that clause of the Social 
Contract?  I guess it depends on what it means by "make the system require".  
My gut instinct is "no, it's fine, put it in main," because the compiler is 
not "required" by the system, since the system functions fine without 
recompiling the graphics (and will continue to).  I may be wrong, though!

The main/contrib distinction is tricky to say the least.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[David Nusinow]

On Sat, Jul 23, 2005 at 09:50:56AM -0700, Ken Arromdee wrote:
> On Sat, 23 Jul 2005, David Nusinow wrote:
> > This is true, but not because the driver isn't commented. It's because the
> > specs for the card have not been released, and as such we don't know what
> > the magic numbers mean. The hardware specs are entirely external to the
> > source code for the driver itself, and as such it doesn't affect the
> > freeness of the driver.
> 
> If the guys at Nvidia maintain the driver by referring to a separate copy of
> the hardware specs and copying numbers from it into the driver when needed,
> then the hardware specs are external to the source code of the driver.
> 
> If the guys at Nvidia maintain the driver by maintaining a version of the
> code which has symbols in it, and give the driver to us by removing the
> symbols, then to the extent which the symbols provide information about the
> specs, the specs are *not* external to the source of the driver.

But understanding it is contingent on those specs. You have all the rights
to modify the code that is the nv driver as it is under a Free license.
Upstream also likely keeps the driver in revision control with its own set
of comments and metadata that they use to maintain the driver, but not
having access to that does not qualify the thing as non-free.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Jeff King]

On Sat, Jul 23, 2005 at 10:40:36AM +0100, Matthew Garrett wrote:

> Machine generated assembly is, in general, significantly less modifiable
> than hand-written assembly.

And code in which information that the original coder inserted has been
removed is less modifiable than code written without that information in
the first place.

Can give you a good reason why the two situations we described are
significantly different?

-Peff


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Ken Arromdee]

On Sat, 23 Jul 2005, David Nusinow wrote:
> This is true, but not because the driver isn't commented. It's because the
> specs for the card have not been released, and as such we don't know what
> the magic numbers mean. The hardware specs are entirely external to the
> source code for the driver itself, and as such it doesn't affect the
> freeness of the driver.

If the guys at Nvidia maintain the driver by referring to a separate copy of
the hardware specs and copying numbers from it into the driver when needed,
then the hardware specs are external to the source code of the driver.

If the guys at Nvidia maintain the driver by maintaining a version of the
code which has symbols in it, and give the driver to us by removing the
symbols, then to the extent which the symbols provide information about the
specs, the specs are *not* external to the source of the driver.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[David Nusinow]

On Fri, Jul 22, 2005 at 11:28:54PM -0700, Michael K. Edwards wrote:
> On 7/22/05, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > In other words, we'll take something as source that we know isn't,
> > because we like nVidia.  ...
> 
> Hey, I didn't say I liked the idea myself.  I'm just calling it like I
> see it.  I would say that the core functionality of the nv driver is
> not maintainable or improvable by anyone outside nVidia, but at least
> it can be recompiled to pick up changes in X.org data structure layout
> or whatever and there is some chance of point fixing it.  It's not
> entirely my idea of source code -- but then neither are the Emacs
> internals.

This is true, but not because the driver isn't commented. It's because the
specs for the card have not been released, and as such we don't know what
the magic numbers mean. The hardware specs are entirely external to the
source code for the driver itself, and as such it doesn't affect the
freeness of the driver.

On a more practical note, you're going to have a very difficult time
convincing me to move the nv driver to non-free. This not even borderline
case is the only thing that stands in the way of having every single nvidia
owner use the binary nvidia drivers which I can not support in *any way at
all*.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Fri, 22 Jul 2005 18:09:56 -0400 Glenn Maynard wrote:

> On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote:
[...]
> > I think it's not acceptable to yse pregenerated files to prevent
> > software from entering contrib.  (Look at all the Java programs, for
> > instance.)  If there's a povray dependency, the software cannot be
> > included in main.
> 
> If you mean "images generated from povray are non-free because they
> can't be built from source without a non-free component", I'd have to
> disagree on the grounds that the conclusion is so patently absurd, the
> premises must be flawed (whether or not I'm able to pinpoint that
> flaw).

I don't think Florian meant that povray-generated images are non-free.
I think he said that they are not eligible for inclusion in main and
belong in contrib (as long as they are under a free license and are
provided with source).

> 
> Looking at it more closely, nothing in DFSG#2 requires that the source
> be usable; only that it be source.  That is, if the source to a
> program is written in an expensive, proprietary language, it's still
> source, and satisfies DFSG#2.  That doesn't mean Debian has to accept
> it; meeting the DFSG is a prerequisite, but not a guarantee of
> inclusion, and Debian is free to refuse to include software for other
> reasons (such as "we can't build this source").  I just can't agree
> that a freely-licensed work, with source (such as an image with povray
> source) can be accurately branded non-free because the tools to build
> that source are non-free.

I agree with you, but suspect that Florian agrees too!  ;-)

P.S.: Florian, could you confirm or otherwise correct me?
  Rest assured it's not my intention to put words in your mouth, I
  simply noticed what I believe is a misunderstanding between you
  and Glenn, and wanted to point it out...

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpVDl6McpWm5.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Sat, 23 Jul 2005 07:29:19 -0400 Glenn Maynard wrote:

> You seem to be arguing that "preferred form for modification" is a
> poor definition of "source" based on the fact that it doesn't permit
> passing off obfuscated code (such as, perhaps, nVidia's) as "source",
> and that seems to me to be one of its strengths.

Agreed: that is a *feature* of the "preferred form for modification"
definition of source, not a *bug*!

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpayLCQSM0Vy.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Florian Weimer]

>> If upstreams sues you, the freedoms granted by the license texts don't
>> matter much.  A court case is a great inconvenience, even if the
>> defendant wins in the end.
>
> Are you missing the point deliberately?
>
> The question was: if we have two examples of source code; one stripped
> of comments by obfuscation and the second one written without comments,
> both released under the same Free Software license, how do you tell,
> which one is free and which one is not?

The first author's intent was to make the creation of derivative works
harder, irrespective of what the license says.  This makes the work
non-free (at least I'd rather refrain from using it).  In the second
case, the author may just be a suitable skilled developer (either he's
too bad or too good for writing commented source code).

> Jubal, eagerly awaiting the precious moment when we'll require the
> full internal documentation of any software released before
> considering it free.

In order to exercise my right to create derived works, I need to
understand some of the internal workings of the program.  From a
practical point of view, software freedom needs some degree of
maintainability.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Miros/law Baran]

23.07.2005 pisze Florian Weimer ([EMAIL PROTECTED]):

> > What difference does upstream intent make to the freedoms that our users 
> > receive?

> If upstreams sues you, the freedoms granted by the license texts don't
> matter much.  A court case is a great inconvenience, even if the
> defendant wins in the end.

Are you missing the point deliberately?

The question was: if we have two examples of source code; one stripped
of comments by obfuscation and the second one written without comments,
both released under the same Free Software license, how do you tell,
which one is free and which one is not?

Jubal, eagerly awaiting the precious moment when we'll require the full
internal documentation of any software released before considering it
free.

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] 

 Tact, n.:
 The unsaid part of what you're thinking.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Matthew Garrett:

> On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote:
>> * Matthew Garrett:
>> > How is one of these free and the other non-free?
>> 
>> In the end, you have to take upstream intent into account.  We already
>> do this when interpreting licenses (at least in one direction), so I
>> don't think this makes things worse.
>
> What difference does upstream intent make to the freedoms that our users 
> receive?

If upstreams sues you, the freedoms granted by the license texts don't
matter much.  A court case is a great inconvenience, even if the
defendant wins in the end.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Sat, 23 Jul 2005 01:01:07 +0200 Florian Weimer wrote:

> * Steve Langasek:
> 
> >> It's clear from the context (and previous discussion) that this has
> >> to be interpreted as "software".
> >
> > No, it isn't.  Considering we went through all the effort of a GR to
> > amend the DFSG and this still says "program", not "software", I
> > don't see how you can claim it *has* to be read as "software".
> 
> So you think that the DFSG clauses 2, 6, 7, 8 do not apply to
> documentation, only to executables?

I asked Steve basically the same question in
  Message-Id: <[EMAIL PROTECTED]>
  http://lists.debian.org/debian-legal/2005/03/msg00149.html
during the long nv driver thread (which unfortunately I do not have time
to reread now).

So far I got no answer...  :-(

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpdLJ2mHxnFc.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Francesco Poli]

On Thu, 21 Jul 2005 21:15:12 -0400 Glenn Maynard wrote:

> I think it would be massive negligence for the project to accept as
> source something which it knows has been obfuscated.  If that's the
> case, I'm rather disgusted.  It's hard to take a project seriously
> which claims to require source, but whistles and looks the other way
> when given something that is obviously not source, because it wants
> that particular piece of software more than it wants to stick to its
> founding principles.  If Debian is going to drop its principles and
> loosen the Social Contract, so be it, but don't try to hide it by
> pretending obfuscated code is source.

I really hope Debian is *not* going to drop its principles.

If there is evidence that this driver code is not directly modified by
its maintainer, but is instead generated by a filter (i.e. an
obfuscator) from a more comfortable form, then this form is the real
source code. If this is the case, we are not given the actual source to
this driver and we should seek clarification from upstream and ask for
the actual source.


P.S.: just a note to say that I agree with basically everything said so
far by Glenn Maynard in this sub-thread.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmyKk3PNfuJ.pgp
Description: PGP signature

Re: generated source files, GPL and DFSG

[Glenn Maynard]

On Sat, Jul 23, 2005 at 10:44:36AM +0100, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > One provided source, the other did not, and Debian considers having source
> > fundamental to having a free program.
> 
> "Because it is, damnit"?

No, because one provided source, and the other did not, and Debian
considers having source fundamental to having a free program.  If
you don't accept a simple reference to Debian's actual requirements
(DFSG#2) used to determine whether something is free or non-free
as a response to "how is one of these free and the other non-free",
then I don't know what you possibly will.

(In any case, we were trying to figure out what "source" means, not
what's more or less free.)

> If the ease of modification is equivalent in both cases, then I'd
> consider them to be equally free. If it's impractical for anyone to
> modify either, then I'd consider them non-free. "Free software" that
> provides no practical way of excercising its freedoms is not something
> that we should be supporting or holding up as an example to others.

The third sentence does not support the first two.  Indeed, software
that is poorly written, and is unmaintainable as a result, is not
something that should stand as an example, and shouldn't be in Debian;
but that has no relevance to whether or not it's source.

You skipped the more relevant question: Is disassembly of a compiled
program "source" to you, if the disassembly is as usable as hand-written
assembly?  I havn't seen explanations of how disassembly output, or any
forms of code obfuscation (eg. removing of comments or symbolic constants),
can possibly be seen as source code.  You say "it's just as free", but
we're discussing what "source" is, not what "free" is.

You seem to be arguing that "preferred form for modification" is a poor
definition of "source" based on the fact that it doesn't permit passing
off obfuscated code (such as, perhaps, nVidia's) as "source", and that
seems to me to be one of its strengths.

(That is, from my perspective, it's self-evident that obfuscated code
is not source, and "preferred form" gets this case right.  Maybe it's
self-evident to you that obfuscated code is source.  If that's the case,
we may be at an impasse, having fundamentally different notions of what
"source code" means.)

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Antti-Juhani Kaijanaho]

On 20050723T013237+0100, Matthew Garrett wrote:
> So if I write C with comments and then remove them that's not DFSG free,
> but if I fail to add them in the first place then it's fine for main?

This is not a universally applicable rule, but:

When a good programmer writes uncommented code, it's usually written in
a way that requires no comments for understanding it.

When a good programmer writes commented code, the comments are often
actually important for understanding the code (say, the code is
necessarily so hairy that one needs to have a high-level understanding
of it to be able to make sense of it; that understanding will be induced
by the comment).

In the second case, removing the comments will make the source code
unmaintainable, while in the first case, the commentless source code is
perfectly maintainable.

As to whether this affects DFSG freeness, I cannot say.
-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Andrew Suffield]

On Sat, Jul 23, 2005 at 12:22:34AM +0100, Matthew Garrett wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> > * Matthew Garrett:
> > 
> >> There's two main issues here.
> >>
> >> 1) Does everything in main have to include the preferred form of
> >> modification?
> >>
> >> I don't believe so, 
> > 
> > We had a GR that is usually interpreted in a manner which disagrees
> > with you.
> 
> We had a GR that stated that everything in main must include "source
> code".

Actually that's a myth. We have never had a GR on this subject.

We did have a *release manager* who stated this, at one point.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Andrew Suffield]

On Sat, Jul 23, 2005 at 11:24:12AM +0200, Andreas Barth wrote:
> * Glenn Maynard ([EMAIL PROTECTED]) [050723 11:15]:
> > (CC's trimmed.)
> > On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote:
> > > > It's clear from the context (and previous discussion) that this has to
> > > > be interpreted as "software".
> > > 
> > > I disagree with that. As there were "editorial changes" that had as
> > > declared goal to replace any such places with the "real meaning", and
> > > this was not touched, it has to be obviously interpreted as program.
> 
> > If you really want to deal in unconvincing semantic arguments, consider
> > that the clause says "the program", which indicates that it's assuming
> > the whole of the DFSG is only being applied to "programs".  Since
> > GR2004-003 established that the DFSG applies to everything in Debian,
> > "program" can only consistently be interpreted here as "everything in
> > Debian".
> 
> Why didn't the GR then change the wording to program?

Because this word is in the DFSG, not the SC. Please stop making up
ridiculous interpretations. 2004-03 was modifying the SC. It did not
modify the DFSG. That's all there is to see here.

And before anybody starts making up more daft ideas about why the DFSG
wasn't changed, it was for one reason and one reason alone:

Updating the SC took quite enough of my time, I didn't want to do the
DFSG as well right then.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Andrew Suffield]

On Fri, Jul 22, 2005 at 03:47:41PM -0700, Steve Langasek wrote:
> On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote:
> > * Andreas Barth:
> > 
> > > Actually, the DFSG says:
> > > | 2. Source Code
> > > |
> > > | The program must include source code, and must allow distribution in
> > > | source code as well as compiled form.
> > >
> > > Obviously e.g. fonts are no programms, even if they are in main.
> 
> > It's clear from the context (and previous discussion) that this has to
> > be interpreted as "software".
> 
> No, it isn't.  Considering we went through all the effort of a GR to amend
> the DFSG and this still says "program", not "software", I don't see how you
> can claim it *has* to be read as "software".  (And there are fewer instances
> of the word "software" in the DFSG after the revision than there were
> before, anyway...)

The DFSG was never amended. The text has not changed.

This is purely because I didn't want to lump two complex revisions
together, and it carries no implications about the intended
meaning.

The relevant change in 2004-03 was to eliminate all uses of the word
"software" from the SC (except as part of the compound noun "free
software"), on the basis that it had always meant "everything" but
some people had difficulty understanding this and we got into
pointless debates because of it.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: generated source files, GPL and DFSG

[Matthew Garrett]

On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote:
> * Matthew Garrett:
> > How is one of these free and the other non-free?
> 
> In the end, you have to take upstream intent into account.  We already
> do this when interpreting licenses (at least in one direction), so I
> don't think this makes things worse.

What difference does upstream intent make to the freedoms that our users 
receive?

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Florian Weimer]

* Matthew Garrett:

> So say we have two drivers for a piece of hardware. One is written
> without comments. One was originally commented, but the comments have
> been removed. Both provide the same amount of information about how they
> work. Both are released under the same license. Both provide exactly the
> same freedoms to our users.
>
> How is one of these free and the other non-free?

In the end, you have to take upstream intent into account.  We already
do this when interpreting licenses (at least in one direction), so I
don't think this makes things worse.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Matthew Garrett]

Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:
>> So say we have two drivers for a piece of hardware. One is written
>> without comments. One was originally commented, but the comments have
>> been removed. Both provide the same amount of information about how they
>> work. Both are released under the same license. Both provide exactly the
>> same freedoms to our users.
>> 
>> How is one of these free and the other non-free?
> 
> One provided source, the other did not, and Debian considers having source
> fundamental to having a free program.

"Because it is, damnit"?

> Take it a step further, and say we have two drivers: one written in heavily-
> optimized, uncommented assembly, and one written in C, compiled with
> optimizations and disassembled.  They look pretty much the same; as you say,
> both provide the "same freedoms to our users".  Is disassembly output of a
> compiled program "source" to you?  Is one free and the other non-free?

If the ease of modification is equivalent in both cases, then I'd
consider them to be equally free. If it's impractical for anyone to
modify either, then I'd consider them non-free. "Free software" that
provides no practical way of excercising its freedoms is not something
that we should be supporting or holding up as an example to others.
-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: generated source files, GPL and DFSG

[Matthew Garrett]

Jeff King <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:
> 
>> So say we have two drivers for a piece of hardware. One is written
>> without comments. One was originally commented, but the comments have
>> been removed. Both provide the same amount of information about how they
>> work. Both are released under the same license. Both provide exactly the
>> same freedoms to our users.
>> 
>> How is one of these free and the other non-free?
> 
> Let's say I write a program in C code and compile it to assembly
> language, which I distribute. Somebody else writes an equivalent program
> directly in assembly language and distributes it. The distributed
> products contain the same amount of information about how they work.
> 
> How is one of these free and the other non-free?

Machine generated assembly is, in general, significantly less modifiable
than hand-written assembly.

-- 
Matthew Garrett | [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]