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

[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

[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

[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

[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

[Á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

[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

[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

[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