[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



I agree with Adam's analysis below, except that IMO the debian/* files
are just as much part of the source code, and there's no exception for
them.  See the quote from the GPL that I posted yesterday, about
`scripts which control compilation and installation of the
executable'.

Adam P. Harris writes ("Bug#27906: SUMMARY of Bug#27906: [PROPOSED] Binary-only NMU's "):
...
> 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?


Reply to: