Bug#27906: SUMMARY of Bug#27906: [PROPOSED] Binary-only NMU's

[apharris@burrito.onshore.com (Adam P. Harris)]

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. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>