Re: Source files
Ángel González <keisial@gmail.com> writes:
> On 15/10/15 00:50, Riley Baird wrote:
>> On Wed, 14 Oct 2015 23:47:02 +0200
>> Francesco Poli<invernomuto@paranoici.org> 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
Reply to: