On Mon, 26 Feb 2007 12:49:43 +0100 Florian Weimer wrote: > * Francesco Poli: > > > Clause 4(a) states, in part: > > > > | If You create a Collective Work, upon notice from any > > | Licensor You must, to the extent practicable, remove from > > | the Collective Work any credit as required by clause 4(c), > > | as requested. If You create a Derivative Work, upon notice > > | from any Licensor You must, to the extent practicable, > > | remove from the Derivative Work any credit as required by > > | clause 4(c), as requested. > > > > This is unchanged with respect to the previous drafts: I'm not yet > > convinced that this clause meets the DFSG. > > Isn't it a no-op in most jurisdictions, just repeating rights authors > have got anyway? IANAL, and hence I cannot really comment on what is required by law in many jurisdictions, but I don't think it's a no-op... Anyway, even assuming it's a no-op in most jurisdictions, this clause is extending the issue to the other jurisdictions and to the future (when some jurisdiction could drop such restriction from their copyright law...). > > And I hope we would honor such requests in the indicated way, > independently of what the legal requirements are. As a matter of courtesy, I would do many things, if kindly requested to do so. But I don't want to be *legally required* to do them, when they are non-free restrictions. For instance, if I file a bugreport against a Debian package, the maintainer could ask me to check whether the bug is still reproducible on a more recent version. It actually happened to me more than once. Whenever I managed to find the time, I backported the new version to Debian stable and did the test. I was happy to help. But if the license *required* me to test newer versions of the work whenever requested by the Licensor, I would consider this as a non-free restriction! I hope many other people think likewise. > > > It's worth noting that CC licenses have a mandatory version-upgrade > > mechanism and also a mandatory jurisdiction-change mechanism. > > Now a mandatory relicensing-to-other-yet-unspecified-licenses > > mechanism has been added, thus making the situation even worse, as I > > explained above. > > > > When I say "mandatory", I mean mandatory for the licensor, in the > > sense that a licensor cannot choose to *not* grant this option to > > licensees. > > You can always add a statement to the contrary. I don't think I can. Clause 4(a) and 4(b) state, in part: | You may not offer or impose any terms on the Work that restrict | the terms of this License or the ability of a recipient of the | Work to exercise of the rights granted to that recipient under | the terms of the License. | You may not offer or impose any terms on the Derivative Works | that restrict the terms of the Applicable License or the ability | of a recipient of the Work to exercise the rights granted to | that recipient under the terms of the Applicable License; [...] > > Clause 4(c) states, in part: > > > > | in the case of a Derivative Work or Collective Work, at a > > | minimum such credit will appear, if a credit for all > > | contributing authors of the Derivative Work or Collective > > | Work appears, then as part of these credits and in a manner > > | at least as prominent as the credits for the other > > | contributing authors. > > > > This is unchanged with respect to the previous drafts: credit must > > be "at least as prominent as the credits for the other contributing > > authors". Even if the licensor's contribution is not comparable to > > others. I still think that this restriction is excessive and fails > > to meet the DFSG. > > I disagree. This is only a problem if you think credits are > ego-boosters. I cannot fully understand what you mean. I think that requiring excessive credit is a non-free restriction and that crediting in proportion to the contribution (rather than necessarily in a manner equal to every other credit) should be possible. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpiHh5oBqvIh.pgp
Description: PGP signature