Re: Source files
❦ 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
Á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
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
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
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.
