-=| Jonathan Yu, Mon, Mar 21, 2011 at 09:00:23PM -0400 |=- > I have prepared the following patch to policy.pod. Please review and > submit comments as appropriate: Comments follow. Sorry for the harsh tone, it comes from the lack of sufficient English skills on my side. > +=head1 Copyright and License Information > + > +One of Debian's core values is the notion of "free, as in freedom" -- indeed, > +the L<Debian Social Contract|http://debian.org/social_contract> speaks of > +Debian's mandate to remain 100% free and give back to the free software > +community. Does this needs to be here? Seems like a re-iteration of a fact that should already be well known. > +The Debian Perl Group B<strongly prefers> free software. In order to constitute Ditto. We are part of Debian, so we obviously follow the Debian policy on this. > +Be licensed under terms compatible with the L<Debian Free Software > Guidelines| > +http://debian.org/social_contract#guidelines> (DFSG). Ditto. > +Provide applicable year(s) of copyright This is certainly not a "must". A missing year of copyright does not prevent us from distributin the software or excersising any of the other freedoms. Yes, it is a very nice thing to have, so that one can tell when the copyright expires, but not a strict requirement. > +This information, collected for each and every file in a package, > is provided > +to our users through a machine-parseable file called b<debian/copyright>, as > +defined in L<DEP5|http://dep.debian.net/deps/dep5/>. Again, repeats policy. > +=head2 Team-Maintained Software > + > +Often, large software projects are maintained by numerous members of a team. > +Historically, Perl software has been developed quite informally, without > +anything resembling the L<Contributor License Agreement| > +http://en.wikipedia.org/wiki/Contributor_License_Agreement>s (CLA) seen > +frequently in large corporate-sponsored open source projects. > + > +Among other things, these agreements simplify copyright information by > +ensuring that all contributions are assigned to a single copyright holder, > +often the sponsoring organization. Stop right there. This sounds like Debian (Perl Group) encourages copyright assignment. I personally have strong feelings against this. I want the copyright on any contributions I make to stay mine. I don't won't to give it up to some larger "project" that may be bought in the future by a large coproration, not necessarily friendly to free software. (MySQL -> Sun -> Oracle?) I would certainly recommend against copyright assignment. Whether this causes hassles to downstream packagers is irrelevant. Giving up control because of convenience is stupid. Just to show that I am prepared to "sip my soup", take a look at the copyright file of firebird2.5 packages that I have prepared. (http://packages.debian.org/changelogs/pool/main/f/firebird2.5/current/copyright) (BTW, good luck converting this to DEP5 :D) > +=head3 Synchronizing copyright information > + > +In many cases, members should manually synchronize copyright information > +for major projects. It is recommended that this information be maintained > +as part of L<copyright.pod> in order to provide a single source of common > +contributor contact information. > + > +Unfortunately, despite the added workload, there is no other way we can > +guarantee that our users receive appropriate machine-readable copyright > +information along with the packages they install. In general, the practice > +of referring to copyright information in other packages is discouraged. Updating copyright information is easy. Examine the diff when upgrading the upstream sources and be patient. Relying on external sources seems like a easy workaround that may lead to wrong results. If the package is new, examine each and every file, be patient and take notes. Slow? Yes. Correct? Certainly. > +=head3 Dependent packages > + > +Where a team maintains some packages that depend on a single "parent" > +package (for example, a project with a main package as well as plugins), > +it is possible to refer to information in the "parent" package. > + > +For example, the C<Catalyst> project provides utilities and plugins that > +depend on the B<libcatalyst-perl> package. Consider this copyright clause > +as provided in C<Catalyst::Devel>'s B<debian/copyright> file: > + > + Files: * > + Copyright: 2006-2009, various contributors to the Catalyst project > + License: Artistic or GPL-1+ > + X-Comment: for a full list of copyright holders, please see copyright > + information for the libcatalyst-perl package. This violates the Debian policy. > +In this case, it is permissible to refer to the B<libcatalyst-perl> > +package, since it must be available on the system in question. No. I can download the package off the web (without any dependencies). Failure to mention copyright holders in such a package would mean license breach (at least for GPL).
Attachment:
signature.asc
Description: Digital signature