Re: Source files
Am 13.10.2015 um 22:23 schrieb Walter Landry: > Ole Streicherwrote: >> 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
On 14.10.2015 10:35, Bastien Roucaries wrote: Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streichera é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
Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streichera é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
> 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
On Wed, 14 Oct 2015 23:47:02 +0200 Francesco Poliwrote: > 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
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 Bairdwrites: > 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
On 15/10/15 00:50, Riley Baird wrote: On Wed, 14 Oct 2015 23:47:02 +0200 Francesco Poliwrote: 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
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
On Thu, 15 Oct 2015 10:26:47 +1100 Ben Finneywrote: > 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
Riley Bairdwrites: > 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