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

Re: Copyright License Proposal





On Tue, Jun 7, 2011 at 1:56 AM, gregor herrmann <gregoa@debian.org> wrote:
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.

This is the thing that really gets me. Does Debian really want human time spent on every last bit? This may seem noble but it really doesn't scale.

I'm not saying that you shouldn't strive for perfection, but computers are better at perfection than humans. Humans are better at programming than computers. So why isn't the effort spent in analyzing the code that checks the code, rather than analyzing every package that goes in, which is flawed at so many levels.
 
- Ingy

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


Reply to: