Re: Authorship, Licensing, Copyright...

[Bron G. <br...@ne...>]

On Tue, Jul 18, 2000 at 11:50:15PM -0500, Mike808 wrote:
> How do we deal with new modules as code 'breaks up' from the original
> XSLT.pm in terms of authorship and copyright holders?

I think an "all authors who've contributed" list over the entire thing.

Separate files and perl modules doesn't mean separate "product" level 
stuff.

> I am assuming that we are unanimous in licensing under the Perl Artistic
> License?

Artistic/GPL combination seems to be the most common, though possibly
LGPL depending on feeling here.  It needs to be usable without having to
open entire applications from the market-share point of view.  I just
received an newsletter from Developer.com saying that Microsoft is
pushing itself as the XML/Unicode platform, and I place competing with
this above GPL purity on my priority list.

> I'll look into if there's a precedent for transferring our copyrights
> to the 'SourceForge XML::XSLT Project Team' in a mode similar to the
> Apache copyrights and licensing. Or to Geert and Egon? Or to each
> his own? Is tab conversion a 'copyrightable' activity? Crap. I just
> knew it that Shakespeare was right ... my head hurts...
> 
> We should lay out our guidelines for required notices amongst ourselves
> and enforce it for all files before we have to retro-fit too much.
> I'm not saying it has to be complicated, just consistent and start
> doing this sooner rather than later.

Yep, certainly.. on the -devel list probably.

> So far, the leading '#' pre-amble seems OK, but I'd like to put
> the proper attribution to the team now that it's mangled pretty good
> by all of us. I *really* think we need the CVS keyword post-amble
> (minus the LOG keyword - I agree with Mark) and all POD going
> after the __END__ statement. I also like the =begin internal_doc
> or =begin ignore type of POD notation for lopping off big chunks of 
> code or internal documentation without having to prefix each line
> with a '#'. Just my twopence.

There's very much two schools of thought here - but once we start splitting
functionality into separate files, we'll need to either put all the docs
in one or do messy include stuff (I'm not sure how POD handles that)

-- 
Bron ( learning Docbook atm, whee )