Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
On Tue, Aug 11, 2009 at 9:56 PM, Romain Beauxis<toots@rastageeks.org> wrote:
> Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit :
>> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy<plessy@debian.org> wrote:
>> > Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
>> >> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy<plessy@debian.org> wrote:
>> >> > The dh_make template for debian/copyright induces many developers to
>> >> > put their packaging work under the GPL, and I have already seen
>> >> > packages whose license is otherwise BSD-ish with such patches. If the
>> >> > maintainer suddenly goes MIA and the patch is non-trivial, then in
>> >> > theory if we want to respect what is written, we are stuck with a
>> >> > GPL'ed patch. Therefore, we have an optional License field to make
>> >> > things crystal clear if necessary.
>> >>
>> >> Sounds like dh_make needs a bug report about the default packagaging
>> >> license, could you file one?
>> >
>> > Dear all,
>> >
>> > we just had a case in the Debian Med packaging team where the upstream
>> > author of software licensed under terms similar to the BSD license got
>> > upset to see the Debian packaging licenced under the GPL, and posted a
>> > reminder that GPLed contributions to his software will not be accepted.
>>
>> Yes, this is precisely why the pkg-perl team usually goes with "same
>> terms as Perl itself" (Artistic | GPL) and whatever the upstream
>> licensing terms are (usually Artistic | GPL but sometimes BSD).
>>
>> So for example if upstream is BSD-licensed, then I'd personally put
>> something like:
>> Artistic | GPL | BSD
>> for the debian/* files
>>
>> My reasoning is that the upstream can get stuff like patches back into
>> their software (the BSD) provision but also allows anyone that can use
>> Perl to use the patch (Artistic | GPL). Further, if upstream decides
>> later to change to the "same as Perl" license (it is probably the most
>> popular license on CPAN), it is okay for them to do so (with our
>> patches).
>>
>> In the case of Debian-Med (being an outsider and not knowing what the
>> team works with), I'd say explicitly licensing your debian/* files
>> under the same license as upstream would be appropriate, or perhaps a
>> combination of upstream | GPL licensing. This is clearly a discussion
>> we all need to have within teams/package groups/etc -- namely, what do
>> we want our debian/* files to be licensed under.
>
> And also what exactly is covered by the license claim. For instance, in the
> case of patches contained in debian/, I have some doubts about the license
> that applies.
>
> Usually, when one wants to propose a patch to a project, it has to do it under
> the original licence. That's particularly the case if the patch consists, for
> instance, of the diff of a commit from the current developpement code of the
> same upstream project...
That does apply if you are proposing a patch for direct inclusion into
the project, though not even necessarily. I think that in that case
it's usually just assumed that you are providing code under the same
license. With a patch you're writing original code so you should have
the right to license it as you please, but you still need for the
patch to comply with the original license so that it can be included
without forcing upstream to change their license.
In any case, some superset of upstream + whatever other licenses you
want should be OK, since the upstream can integrate your changes by
licensing the code under their license. You still technically hold the
copyright to the diff but it usually doesn't matter, and authors often
assume copyright of your work unless it's a rather sizable patch,
which I think is what we want in the end.
Anyway, if the patch is applied upstream it's usually removed from
debian/patches/* so this point is sort of moot, right? As long as the
upstream is allowed to integrate the patch
>
> Hence, are patches in debian/ covered by the license claimed for the project
> upstream, or for the debian packaging ?
I'm of course not a lawyer, but my assumption is that code written by
someone is owned by that person, so it's covered by the Debian
packager/packaging team.
>
>
> Romain
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: