There are a lot of issues floating around here. First, administrivia. Ian originally said:
| I hereby propose an amendment to the Debian Developers' Reference, | s5.5 `Interim Releases' If this topic under discussion is a proposed correction to the devel-ref, we should refile the bug accordingly. I would be delighted to determine best practice and document them in the devel-ref. As for policy compliance issues, they should probably become Policy, which carries more weight than the developer's reference. Next, is the issue of License Compliance. Unfortunately, there are a lot of varieties here, since there are many different situations for patches by porters and different licenses being used in 'main'. We ought to assume that any package in main requires that changes to the upstream source require that full source be available, either in the form of a source tarball or tarball plus patches. Let's try to identify the archive states which can occur in which we might be in trouble right now. Please correct me if I am incorrect. As I said before, I'm not yet a porter, I'm just trying to understand so I can document it properly in the developer's reference. I'm going to take m68k as my port location. Given, there are more than one of these. a) binary version 1.1-1 in i386 binary version 1.1-1 in m68k source version is 1.1, patches are 1.1-1 b) binary version 1.1-1 in i386 binary version 1.0-1 in m68k source version is 1.1, patches are 1.1-1 c) binary version 1.1-1 in i386 porter NMU binary version 1.1-1.1 in m68k, binary upload only source version is 1.1, patches are 1.1-1 (?) d) binary version 1.1-1 in i386 porter NMU binary version 1.1-1.1 in m68k, binary + source upload source version is 1.1, patches are 1.1-1.1 (?) Now, I think that states (b) - (d) are where the potential problems are. Moreover, I think states (c) and (d) have sub-divisions, as far as licensing is concerned. If the patches are to 'debian/*' files only, I think it's safe to say that we are not in trouble, licensing-wise, since we are simply breaking our *own* license (i.e., the package maintainer's license), and it's unlikely that the package maintainer is going to sue the porter or not have access to the diffs. However, states (c) and (d) are problematic, licensing-wise, when the patches are to the upstream source, not just to our stuff. And state (b) is also a license violation, since we're shipping binaries w/o the correlated source. Ian, does this express your objections? .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/>
