Re: Copyright and License Guidelines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mar 22, 2011, at 09:17, Damyan Ivanov wrote:
> -=| 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.
There is no question that if you're working in Debian with the Debian-Perl team
that you ought to know the DFSG and other Debian policies. It might not be well
known if you are not familiar with Debian, or if you're only familiar with a Debian
derivative.
Stating this policy clearly in pod, even if it is redundant, is good as long as it doesn't
stray from the DFSG or try to reword already established Debian policies on copyright
and licensing.
>
>> +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.
Are there legal implications if you do not have the year of the copyright attribution?
Is the copyright assignment weaker if it lacks a date?
>> +=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)
My impression is that this section of the policy is trying to explain why it is useful to have
copyright attribution. I hope it is not saying that the Debian (Perl Group) is trying to
assign copyright, but rather that copyright attribution is quite useful in Free Software.
In fact, the GPL depends on copyright and I suspect that the Artistic License does as
well. Which would mean that the standard perl module licensing terms would not be effective
if there is no copyright attribution. (If I understand correctly.) This in fact is often a
problem with perl modules, they lack copyright information and that makes the licensing
harder to determine.
Perhaps the policy ought to be rewritten not to encourage copyright attribution but rather
to encourage the use of copyright and focus on why the policy finds copyright useful. This
way it might be less of a proscription and more of an explanation.
>> +=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.
I think there is no viable alternative aside from correctness. I don't see how we can distribute
software without confidence in copyright.
>> +=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).
Regards,
Jeremiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQIcBAEBAgAGBQJNiG5WAAoJEPoEpn8G2KIrwq0P/iE5BpP+Jh85OSVIamMMtGuE
PL9K6Lffy2rV60h93QWORrokBucE9s6WimQHwY6k5TosSqVhkZhlZFAlE3VsnPO/
r7AhzY8sx4ZOpJtJkjx+QdyA3NipYgHcTUKAU5jcGmhe1QLWoZ5f7XGp8Ut4DSZv
RTexqb3D1uXAe5isOXt4b4mein/tp3z4ApGQbk/hiYEn5UnAB4t1Ni4P+Djc6Bxa
QyvXwV1NCH8MjCZ5wPHiUT3ui3/ig5KIp8rpYhg9Dg+vdGgHOOBvmYHZdGLTA+j7
EZnoxwCRmif3fkizmrQeWanw3NDThazrbY+q6jHDZHr7aaj/cCd9zcp0Y/SPciMh
gR42F0SGRFQ3oaqSdTgqj5CioCxJ9WhWoq8ZDDjilG3Ri7wbDuyjEXxE1ZxFOzj/
ZJ6teN3ErEHEb1mbkN/MIXNA9AG1GilvCs5OsNhYoVlimCEkmcVqtGWmCExl/Npm
uO3AOg5LaHPed7lD/zqTgBaY0RC87k3CPSFONor95xcL9yBBUiOeRkIfDutxktCx
b59j6ifDxYryLY9bjoc1Vg7JPKRKOGJot1YZcBg2vnq/sXXO7gqXTShMkRiurNZ0
YYWOsaoRbcmDn0dLHkaVmxebzefLNGdACNNNBVjjKM0dy6G9Mep7/ghlvKu7b+QL
M3+qXyTDTeIwvexL5Tw6
=HFyY
-----END PGP SIGNATURE-----
Reply to: