On Mon, 11 Jul 2016 13:58:39 +0100
Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092:
> Bug#817092: this browserified"):
> > * Jonas Smedegaard <dr@jones.dk> [160711 07:08]:
> > > Quoting Pirate Praveen (2016-07-11 10:30:59)
> > > > On Sun, 10 Jul 2016 19:41:17 +0200 Jonas Smedegaard
> > > > <dr@jones.dk> wrote:
> > > > > The requirement of source format of redistributed code is not
> > > > > about it being possible/easy to edit by those receiving it¹,
> > > > > but about it being in the format preferred by _upstream_ to
> > > > > edit - e.g. for passing patches upstream.
> >
> > I have to disagree with this. The requirement for "preferred form of
> > modification" was explicitly to allow the recipient of the software
> > the freedom and ability to modify the software, not to force a
> > particular workflow (e.g. upstream's workflow) on the recipient, or
> > require the recipient to send patches back to upstream (which fails
> > the dissident test).
>
> But, we need the freedom and ability to modify the software
> collectively, not just individually. That *does* mean we should be
> able to share our changes with other downstreams of the same upstream,
> and with the upstream itself.
>
> Furthermore, as a matter of being good free software citizens, we
> ought to try to send our patches to upstream.
>
> > My interpretation of "preferred form" is _any_ (explicitly not
> > "the") form which a significant percentage of persons who have
> > experience modifying that kind of software would agree that the
> > given form is as easy to modify as any other form, modulo some
> > level of personal preference. Using upstream's preferred form is
> > not required in order to satisfy the license's preferred form.
>
> I am, in general, unconvinced by these arguments. In practice if
> upstream choose to modify things in form X, and do not accept
> modifications presented as changes to form Y, then I am unconvinced by
> arguments that form Y is "an also preferred form" for modification, or
> some such.
Agreed. It's rare that an upstream accepts patches for the same content
in multiple formats - if only to eliminate duplication in VCS. If there
is a 100% lossless conversion to and fro, it just adds work to accept
both and if such a converter is not available, it makes no sense at
all. It's not about the percentage of people with experience of that
kind of software, it's about how that software actually gets updated and
maintained and that must include how that particular upstream handles
the upstream code. Not using the form preferred by upstream is actively
unhelpful to the community, of which upstream are a part.
If we assume that upstream is active, then carrying changes in Debian
forever, just because someone decided to use a format which was their
preference when upstream want contributions in a different format makes
absolutely no sense. Someone will eventually need to do the work to
convert the patch, meaning that the preferred form of modification is
clearly that which upstream are most willing to accept.
> > Free software encourages, but does not require, giving back to the
> > free software community. Free software _does_ require giving the
> > recipient equal footing to modify the software.
>
> Your analysis takes no account of the fundamentally collaborative and
> collective nature of free software development.
If the work is under a copyleft licence, there absolutely is a
requirement to give back when distributing with the modification (as
Debian does). Publishing those changes in ways that do not match how
upstream would accept those changes for inclusion into a future release
may follow the letter of the licence but it certainly is not being a
good community citizen.
It can be enough hassle for upstream when patches don't apply, let alone
when the effect of the patch has to first be converted to a different
format. Debian needs to encourage things that make collaboration easy,
upstream and downstream.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgpqiQOb1YKnx.pgp
Description: OpenPGP digital signature