Ben Finney <ben+deb...@benfinney.id.au> writes: > Ole Streicher <oleb...@debian.org> writes: >> However, it contains one line >> /*globals $, jQuery,define,_fnExternApiFunc,[...] >> which is ~1400 characters long and may be automatically inserted. > > 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.
This is the case for the CVS/RCS $ Id: $ line, which is actually generated by committing the edited file to an RCS (,v) file (which is /different/ from the actual file). >> 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. I meant ambigous, sorry. In this case (as in the case of the CVS/RCS Id line), it is not helping, since some people may prefer not to edit this line at all: I f.e. would just ignore the line in the Javascript source, since it does not have a functional influence, and I do not care about the line at all. Others would like to keep the consistency, as I would like to do in the case of the CVS/RCS Id. Who is right then? >> 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? Not in all cases. One use case would be to bring the file in sync with the current developments of the original file. For this, I would prefer patches instead of just the changed file. > 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. The example is not about whether the changes were made manually or automatically, but about what is preferred to work with. And there are use cases which would require to have the patches separated (being them manually generated or not), so by the GPL definition the patched file is not a 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. Anyway, I have a use case for the derived work where I would prefer to have the modifications in form of patches -- which makes the derived work itself a non-source (since for this use case it is not the preferred form of modification). >> 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 question here is not about what is legal, but about what we accept in Debian. If a file is licenses by BSD, it does not matter whether it complies to a specific "source" definition to obey this copyright. Best regards Ole
