[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-source Javascript files in upstream source



Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com> writes:

> 2014-04-26 07:51 Ben Finney:
> > If it's in the Debian source package, it is distributed as part of
> > Debian.

(I'm assuming, from the lack of response to this point, that this is
uncontroversial.)

> What's your position on 'configure' scripts for which we don't know if
> they are generated from the .ac? (Is there a good method to even test
> this?). Are they also missing the source?

I don't have a special position on those; also, I'm not much of an
expert on ‘configure’ and its generated files.

My general position is: If it's in the Debian source package, it is
thereby part of Debian; as part of Debian, the Debian Social Contract
promises every recipient that the corresponding source must be in
Debian; for that promise to be sound, we need to have independent
verification. If we dismiss the need for that verification, then we are
not serious about that promise.

> >What part are you saying is “not a universally held view”, and how do
> >you reconcile that with the Debian Social Contract?
>
> My understanding is that SC and DFSG, similarly to the definition of
> Free Software by FSF and other efforts, were devised to promote user
> freedom when using and modifying software, etc.

Yes. Every Debian source package is software; every Debian recipient has
a promise of freedom in that software, to modify it and redistribute the
result. If we ship a non-source file without being able to verifiably
demonstrate the corresponding source to that file is in Debian, we
shouldn't pretend to make that promise.

> If the consequence of following SC and DFS *Guidelines* (SC#1 refer to
> it) does not further these goals, it is an exercise in futility, and
> thus not worth doing in my opinion.

I'hope you're in agreement that a Debian source package is software, and
every recipient of that package deserves all the freedoms promised in
the Social Contract.

> Interpreting SC or DFSG (or any law or guideline, for that matter)
> without thinking of the utility, the costs or the consequences, does
> not seem very wise to me.

If the consequence is to dismiss a promise of freedom to Debian
recipients, I think that's an unbearable cost.

> "source-is-missing" is not important if we (or the users) don't need,
> or even use or want, the source or the derived file.

It's not for you, or me, or anyone else, to decide which part of the
freedoms we've promised to Debian recipients are unimportant to those
recipients. It's for them to decide — unilaterally, without consulting
us to see whether we still feel like honouring our promise.

> And if they want to use/modify it, they can easily get it

Can they get the corresponding source? Or are you saying it's
unimportant to get the *corresponding* source for a bundled non-source
file, but sufficient to offer some other source that no-one has
determined is the corresponding source for the file in question?

> and in fact it is *better* if they get it from JQuery upstream (or our
> canonical Debian package) than from the upstream project that ships it
> (more recent fixes, etc).

That's assuming the bundled file *is* functionally identical. How its
that determined? Do you agree it's important to determine that, given
the promises that the corresponding source is in Debian for every part
of Debian?

And, if it is a non-source file that we *know* is functionally identical
to something we already ship in Debian, why would we bundled in the
source package, risking divergent copies?

> Every person with knowledge about how to modify the minified JQuery,
> or to ask some other person to do it for them, will know (the minified
> file tells them) where to get the preferred form of modification,

I don't know what “preferred form of modification” means. I assume you
mean “preferred form of the work for modifying it”.

As such, I think your assertion is suspect and likely false, as
discussed above.

> And having minified+unminified would be just another case of embedded
> 3rd party libs.

Yes, a case which should be eradicated as inviting unwanted and
untracked divergent copies.

-- 
 \        “You can't have everything; where would you put it?” —Steven |
  `\                                                            Wright |
_o__)                                                                  |
Ben Finney


Reply to: