On Mon, 11 Jul 2016 11:00:20 -0400
Marvin Renich <mrvn@renich.org> wrote:
> * Ian Jackson <ijackson@chiark.greenend.org.uk> [160711 08:59]:
> > Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092:
> > Bug#817092: this browserified"):
> > > 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.
>
> I agree, we should use upstream's form. But there is a distinct
> difference between free software and the free software community. The
> primary purpose of free software is to provide freedoms to the
> individual recipient of the software. When there are also
> requirements to "do it my way" (where "my" refers to upstream), the
> software is no longer free.
What is the point of making changes which upstream would otherwise
accept by deliberately making those changes in a way that causes
upstream more work to accept them?
> One fundamental purpose of the free software community is to ensure
> that free software thrives. To this end, the recipient SHOULD (as in
> the RFC meaning of SHOULD) make changes available to upstream and do
> so in a way that upstream likes. But changing that SHOULD to a MUST
> changes the software from free to non-free. Now you have (perhaps
> severely) restricted the recipient's freedom to make changes.
The recipient needs to understand their own place within the community
and that making changes in a way that makes it easy for others to
include those changes - including the upstream - is part of the point
of being able to modify the software in the first place.
The freedom to modify does not infer that the modification is made in
isolation. Collaboration involves upstream and free software without
collaboration is a useful thought-exercise for evaluation of licences
but has no practical benefit to the community.
Modification without collaboration merely generates infinite churn.
> Perhaps the term "communal software" better describes software that
> requires modifications to be in a form acceptable to upstream. You
> can use this software, but if you want to modify it, you must become
> part of the community and give patches in a form that the community
> likes.
You can modify and distribute with changes however you like but Debian
has a clear role in encouraging collaboration with upstream. Part of
that requires that we don't make such collaboration unnecessarily
difficult - for anyone involved.
> By your definition, a complete fork of a piece of software would still
> be required to use upstream's preferred form.
The new upstream, yes. It makes no sense to obfuscate changes or make
it artificially hard to integrate your changes such that other people
can benefit directly from the next upstream release. If possible, (i.e.
if it's not one of the reasons for the fork), then the modification
would bring most benefit to the community by being in a format which
both the fork and the original upstream can use.
Is anyone going to go around all the various modifications and
integrate them *manually* into a new release? Imagine how much more
pointless that becomes when these use different formats for the same
patch! Modifications are not made in isolation, everyone making
modifications needs to consider how to make the modification in a way
that makes it easy to share that modification with the community and
the community includes upstream. For maximal benefit, contributions
need to go upstream and Debian cares passionately about giving maximum
benefit to the entire community from all of our changes.
> Again, it is a difference between the recipient exercising his/her
> freedoms based on the software being free, and being a good citizen
> within the free software community. Saying that you must be a good
> citizen to exercise the grants of the free software license goes
> against the principle of free software.
That is obviously absurd. You need to be a good citizen so that your
changes will bring maximal benefit to the community. Being awkward
makes it harder to contribute your changes back to everyone else. In
turn, it makes it less likely that others will contribute to your needs.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgp8gc79uyHZC.pgp
Description: OpenPGP digital signature