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

Re: Copyright License Proposal



On Tue, 07 Jun 2011 01:14:52 +1000, Ingy dot Net wrote:

> > I suspect you did not write the code below the inc/ subdir, right?
> Funny you should ask. Much of it, yes. I am the original creator of
> Module::Install. But that doesn't matter in principle. It might only matter
> in that I can help change the policy such that using Module::Install does
> not impose any copyright complications on its users. How do I make that so
> for Debian?

AFAICS, you can't; TTBOMK M::I is copyrighted
    2002-2011, Adam Kennedy <adamk@cpan.org>
    2002-2011, Audrey Tang <autrijus@autrijus.org>
    2002-2011, Brian Ingerson <ingy@cpan.org>
so we have to include these three lines in debian/copyright for each
package which includes (parts of) M::I in inc/.

What might help (not M::I related) -- as already mentioned by
Dominique -- is to extend the META spec to include more detailed
copyright/license information about all files in a distribution, that
can be used when creating a draft of debian/copyright.
 
> My primary aim here is to make it natural for CPAN authors to see their work
> all the way through to Debian or any other distribution system. I think it
> is stuffed that things are so complicated that a code author can't easily
> get his code into Debian and any other distribution. Then again, I live in
> the future.

Hm.
Whatever fancy tools we have (on the CPAN or on the Debian side)
won't change the fact that it needs a human DD to actually
check/build and upload the package to the Debian archive.

Some thoughts from my downstream point of view:
- The actual packaging usually doesn't take long with dh-make-perl
  and a sharp eye. Of course dh-make-perl could be improved to save
  us from some small manual steps.
- When it takes more time then because there's something "unusual":
  + missing/unclear copyright/license
  + tests needing network access or writing to $HOME or assuming the
    existence of .svn or something
  + tests or build system not cleaning up after themselves
  + interactive tests or build systems
  + typos in the POD
  + ...
- Most third-party debs (be they created automatically or by some
  well-meaning upstream people) I've seen so far where not really
  ready for upload to the Debian archive; the problem is that Debian
  policy changes and there are quite some subtle details that need
  care.

Which leads me to the same conclusion I've already mentioned: If CPAN
authors want to get their code into Debian (yeah! I really appreciate
when they care about Debian) the way to go is IMO not them creating
.debs but making sure that their distributions are easily
packageable.


Cheers,
gregor

-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-    NP: J.J. Cale: Hard Times

Attachment: signature.asc
Description: Digital signature


Reply to: