Source files
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: Source files
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
Re: Source files
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
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
Expat + exception = DFSG-compatible?
Hi everyone, I'm seeking second opinion regarding mutation of the Expat license that can be found in [1]. In particular, author added the following clause: The Software shall not be used nor made available to TESTTailor or any individual or organization related or operated by Adarsh Mehta from Germany; some people just don't deserve free work to be made available to them. Do we consider this as DFSG compatible license? IMHO it is a DFSG-compatible license because added clause is not a restriction for field of endeavour but a termination clause similar to GPL ones except that is is explicitly added to the license in order to blacklist a known offender. Any thoughts? Thanks. [1]: https://github.com/martin-denizet/redmine_login_audit#license -- Cheers, Dmitry Smirnov. --- The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought. -- John F Kennedy signature.asc Description: This is a digitally signed message part.
