* Ian Jackson <ijack...@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