On Sat, Aug 10, 2002 at 02:48:35PM +0200, Lars Hellström wrote: > You're avoiding the question. You didn't ask one (except for one which you admitted was off-topic). > >Therefore, I reject your analysis. > > Saying so perhaps makes you feel better, but it doesn't make the analysis > go away. Correct; your analysis remains erroneous regardless of whether I agree with it or not. > >DFSG 4 refers to names of works and version numbers for humans. > > You're repeating your claim, but you do not give any new support for it. The onus of proof is on you to establish that DFSG 4 doesn't mean what it says. > For a shared library, it is more useful to think about "development branch > names" and version numbers subordinate to a development branch. For all software that purports to be licensed compatible with the DFSG, it is most useful to think about "names" and "version numbers" in terms of their most obvious and straightforward meanings within the context of the DFSG. > Suppose that a particular shared library mechanism encourages > libraries to declare what development branch they belong to, and that > this information is made available to programs that link themselves to > these libraries -- perhaps via a function that can be called before > the library is linked, or perhaps > as a variable/constant that only becomes available after linking. Encouraging is fine. The DFSG has no opinion about non-contingent or non-binding parts of licenses. > Is it then your interpretation of DFSG:4 that a license which requires > modified variants of the library to use a new branch name in this > declaration is non-free? Yes. Code must be allowed to advertise compatibility with a thing regardless of whether someone feels it's actually compatible or not. > I think it would be a pity if it was, because there are good reasons > why programs should have available such information about the > libraries to which they link. A program that links to an "encryption" > shared library should have the ability to detect that the library it > found was from the "superficial" development branch and therefore > reject to run unless the user started it with a switch to accept this > development branch. A stricter program might even reject the "main" > branch of "encryption", and by default only accept using the > "paranoid" branch (which is only half as fast, but takes care to work > around a glitch, only affecting 5% of the messages sent, in the format > that would otherwise allow the NSA to break the encryption in a day). > In particular the case when the main branch of development is rejected > is important, because main branches have a tendency to get reinstalled > when one doesn't expect it. Good arguments for standardized practices, perhaps. Bad arguments for licensing restrictions. The DFSG rejects the notion that copyright holders be permitted to dictate all aspects of your system's operation. -- G. Branden Robinson | When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. branden@debian.org | -- Robert Anton Wilson http://people.debian.org/~branden/ |
Attachment:
pgph3DfsrCQ2e.pgp
Description: PGP signature