Re: Possible GPL violation in package distribution

Stephen> All .debs suffer from the same "bug." None of them have Stephen> debian/rules in them, but many have scripts which are Stephen> surely source code. The GPL doesn't say that just Stephen> because you provide some sources in a particular medium Stephen> you have to provide them all that way. Dres> I'm not sure what you are saying here. There's no requirement in the GPL v2 that sources must be distributed the same way as binaries, just that they be available on a "medium commonly used for distributing software". In our case, that's CVS. We happen to deliver some of the sources that are especially useful with the "binary" package, but not the distro building scaffolding. As I read the GPL we're technically "over and above" the requirement, since CVS covers us under 3(b) as long as we have an appropriate README, we don't even need to distribute .els. The comments about Debian are just an analogy. My point is that Debian is as anal about legalities as anybody; if Debian does it, it's probably pretty close to compliance (although you won't know until somebody sues). As I read the GPL, it is not an attempt to prescribe that developers must make it _easy_ for the braindead to use redistributed software sources. It is intended to proscribe them from making it _hard_ for people of very moderate competence to use redistributed sources. The prescriptive clause 3 is intended to provide a minimum standard. Note that the comments about scripts and stuff are not part of the GPL as a contract; they are a descriptive gloss intended to help a court interpret the intentions of the contracting parties. In the case of XEmacs packages, lack of a Makefile doesn't make it hard (in an absolute sense) or errorprone to use .els (except in cases like VM, where we do provide the Makefile). OTOH, the Debian project with their debhelper, kernel-package, etc, and even Red Hat with the SRPMs are to be commended for providing the value-added service of making it easy (relatively) to rebuild packages from source. Stephen> To the extent that the clean environment affects the Stephen> build, the user would have to check out the same version Stephen> of XEmacs, build it the same way, and check out all the Stephen> packages (in compilation, a (require ...) basically Stephen> includes the macros in the required file, and they get Stephen> inlined). Nobody in free software provides that level of Stephen> replicability, I don't see why we should be burdened with Stephen> it. Dres> No one ever argued this. Bringing it up is a waste of time. The post you included didn't complain about inability to build a working .elc, it complained about being unable to get all the command lines etc right. Either the person is nearly completely ignorant of how Emacs Lisp development is done (which is no sin, but then their problems with rebuilding are not GPL problems, they are documentation bugs), or they are demanding a rather fine degree of replicability, or ...? What is your interpretation? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."