Re: Bug#995722: Not running tests because tests miss source code is not useful
Julien Puydt <julien.puydt@gmail.com> writes:
> There was the case years ago of the smarteiffel compiler. It was supposed
> to be open source, but upstream only released C code. And that was bad,
> because it wasn't what *they* worked with: they had eiffel sources, and the
> C code was preprocessed and didn't allow/permit bootstrapping. It took some
This is a good example, because it shows how "source code" is defined by
what upstream development uses, not merely by users being able to compile
the released code.
But the situation here seems to be the opposite: The minified javascript
*is* what *they* (upstream developers) work with. They don't have a secret
unpublished build system to generate the minification from unpublished
sources. Presumably, if they need to update it, they would replace it with a
new minified file obtained from a newer release of that project. Or as has
been mentioned, the test might be testing a problem against that very
specific version of the javascript minification, in which case it will never
be changed at all - as that would instead be the addition of a separate
testcase.
Thus, the minified file *is* the preferred (by the upstream developers) form
of the work for making modifications to it. Which is how source code is
defined in the GPL, for example. It seems wrong to me to define "source
code" as something that the upstream development does not use and which
doesn't actually exist anywhere.
As an extreme example, some people prefer Rust to C, but that does not mean
that a C program must be re-written in Rust to satisfy the "preferred form
of work" condition for source code.
This still leaves the Vendoring problem. Even if we consider the minified
javascript "source" in the context of the upstream development, it obviously
isn't source in the context of the original javascript library project. If
the javascript library is GPL, for example, it will require the availability
of the correct version of the source code along with the minification.
I think there is a subtle but important distinction here:
1. A program not being free because it is missing what upstream developers
consider "source" (as in the smarteiffel example).
2. A program being unsuitable for debian because it is developed in a way
that effectively requires Vendoring of sources of dependencies.
- Kristian.
Reply to: