On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich <mrvn@renich.org> wrote: > * Ben Hutchings <ben@decadent.org.uk> [150902 10:12]: > > My preferred form is a git repository of code written in C, Python, > > or some other language I know. That doesn't mean that a tarball of > > Haskell code is non-free! > No, "A preferred form" is what upstream uses. The DFSG does not use > the term "THE preferred form", and I believe that was wise. There > can be multiple "preferred forms" for some software, and all are, in > my opinion, acceptable by the DFSG. The real question is whether it > is reasonable to expect someone who wishes to modify the software to > consider the form "source". Minified isn't source for modification, that much is as far as we've got on consensus in this thread. However, lintian has had checks on minified without unminified JS available for some time and embedding upstreams can follow that, so there is source for modification which the embedding upstream would be able to use but, likely as not, the original JS upstream would not. Equally, fixing the unminified source likely also means patching the embedding upstream templates to use the updated unminified JS as the .min.js cannot be built in the same way as the original JS upstream. There are other minifiers available but those could introduce subtle new bugs. Debian could mandate that embedding upstreams do not include .min.js at all and I could live with that. It doesn't fix the problem that Debian lacks a sane way of maintainers keeping javascript packages up to date with javascript upstreams in ways that embedding upstreams can actually use. The result of that is making software in Debian worse by having more unminified embedded copies at different versions across lots of packages, exponentially more security issues and more JS packages out of date relative to the JS upstream. That would not be good. Embedding software is a bad idea - Debian needs a way of keeping javascript packages up to date with JS upstreams so that other upstreams don't need to embed (minified or non-minified) JS in the first place and everyone has a source for modification in a single place, not spread across a dozen large packages that simply add in some JS to make one small (but important) bit of code work. > This whole thread is about how Debian can conform to some points of > the DSC (e.g. points 4 and 2) by providing packages containing > minified JS, and still conform to the DFSG, and whether that means > some packages that are currently in main need to be moved to contrib > or non-free. The point of contention is not "should we package this > software for the benefit of our users" but whether the packages are > allowed in main, which is strictly based on whether or not they > conform to the DFSG. It's not about contrib or main, that is roughly equivalent to thinking that every DFSG problem looks like a nail because all you have available is a large hammer instead of solving the problem inside main. It is about getting the tools to convert the source for modification (unminified JS) which is included in packages in main which embed JS into a minified JS that doesn't make the security problems worse by introducing it's own bugs by not building the .min.js in the same way as the JS upstream. It's also about implementing a method which allows JS maintainers to keep up to date with JS upstreams so that embedding upstreams don't have to do any of this in the first place. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpuGLMbuBHKv.pgp
Description: OpenPGP digital signature