On Wed, Jun 30, 2010 at 15:54, Jonas Smedegaard <d...@jones.dk> wrote:
> On Wed, Jun 30, 2010 at 03:04:32PM -0400, Felipe Sateler wrote:
>> On Wed, Jun 30, 2010 at 14:57, Jonas Smedegaard <d...@jones.dk> wrote:
>>> On Wed, Jun 30, 2010 at 02:11:39PM -0400, Felipe Sateler wrote:
>>>> On Wed, Jun 30, 2010 at 14:01, Jonas Smedegaard <d...@jones.dk> wrote:
>>>>> If all contributions not originating from MIT have been tracked using
>>>>> CVS at SourceForge, it should be possible to get a list of account names
>>>>> from there, to at least know how many unknown contributors we are talking
>>>>> about.  If this is a large task, it might make sense to first ask
>>>>> debian-devel if such info is legally relevant or not.
>>>> I have a list of commiters, and that list is contained in the list I
>>>> have in my local copy of debian/copyright. However, a large number of
>>>> contributions are made without commit access (for example, I might write to
>>>> the mailing list proposing some wording for a certain opcode). Some of them
>>>> have a "thanks to" note, but I think not all of them do.
>>> Well, I believe it was you who insisted on treating all contributors as
>>> copyright holders. ;-)
>>> What makes sense to me is that we only deal with explicitly claimed
>>> copyright holders and their properly licensed code.  Yes, at least in the
>>> danish jurisdiction there is an implicit ownership as well, but what I
>>> suggest (and I believe that is the common approach in Debian) is to ignore
>>> implicit ownership - and if that means some of the code lack an owner who
>>> licensed the code to us then too bad: then we choose to not redistribute
>>> that piece of code.
>>> ...something along that I would expect you to get as response too if/when
>>> asking debian-le...@.
>>> Problem here - if I understand you correctly - is that we have noone
>>> claiming to be a copyright holder generally for the CSound manual.
>>> What makes most sense to me is actually to tell upstream that we cannot
>>> redistribute their manual without them explicitly stating a) who are the
>>> copyright holders (which might not be the same as those who wrote it - some
>>> contributors might have chosen to transfer ownership) and b) how each and
>>> every one of those copyright holders have licensed their contributions.
>> If this was common practice in debian, we would be left without the linux
>> kernel.
> No.  "common practice" means "what is most often done", not "what is always
> done".

Can you cite examples of "common practice"? I cited the linux kernel
because its the most obvious one.

> Oh, and I do not mean to say that upstream must explicitly list each and
> every copyright holder.  Some claim that "this team holds copyright, with
> this license."  I just meant (in that last sentence above) to cover the
> possible case of "ah, well, most files are licensed like this, so we simply
> assume that the rest are licensed similarly, even if the copyright holders
> are someone else).

Hmm, there is no explicit copyright claim... I'll see what upstream
says to that.

>>>>> Do we have access to any documents upstream which supports the claim
>>>>> that all contributions have been made under the GFDL?
>>>> I don't think so. However, if the code is released under a certain
>>>> license, and I contribute a patch, I think it is implicit that the code is
>>>> licensed under the same license as the project.
>>> I believe that to be a false assumption.
>> I believe common practice in debian has been to trust upstream when it
>> comes to licensing. We cannot provide a full auditory of the code's
>> licensing status, not without investing inordinate amounts of time and
>> effort, and possibly even money.
> I agree.
> And I see no conflict between this and what I described above.  I suspect
> that you do, since you mention it here.  Care to elaborate?

If upstream tells me the work is GFDL'ed, then I have no reason to
believe some parts of it are not GFDL, unless explicitly stated. What
we are doing here is precisely debating whether the manual is in fact


Felipe Sateler

pkg-multimedia-maintainers mailing list

Reply via email to