csound manual

Jonas Smedegaard dr at jones.dk
Wed Jun 30 19:54:34 UTC 2010


On Wed, Jun 30, 2010 at 03:04:32PM -0400, Felipe Sateler wrote:
>On Wed, Jun 30, 2010 at 14:57, Jonas Smedegaard <dr at 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 <dr at 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-legal at .
>>
>>
>> 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".

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).


>>>> 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?


Kind regards,

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100630/1cf9c20a/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list