Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: this browserified
* 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.
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.
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.
By your definition, a complete fork of a piece of software would still
be required to use upstream's preferred form. Even though the new fork
has a new upstream, changing the preferred form would be a violation of
the license terms, so the fork would not be allowed if the new upstream
preferred a different form.
> > 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.
>
> > 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.
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.
...Marvin
Reply to: