[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: copyright precision



Quoting Andrey Rahmatullin (2016-08-16 07:59:09)
> On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote:
>>> So yes, copyright files are hard and unfun but why should we 
>>> continue to write them the way we do if we are not legally bound to 
>>> do so?
>>
>> Same reason that we should continue to care about ability to install 
>> multiple major versions of a library concurrently, and that daemons 
>> are not only linked correctly but also sensibly configured and 
>> started by default.
>>
>> Not because we are legally bound to do so, but because we want to do 
>> our job as distributors properly.  We appreciate good quality 
>> packaging!
> It's at least worth a discussion whether nitpicking at d/copyright is 
> really helping the package quality at all, and if it's worth it.

Certainly.


# Bugfixing upstream licensing

Some upstreams had misunderstood some details of what are legally 
required of them, and appreciate our pointing out when we spot it as 
part of our documenting it.

Some upstreams thought they communicated their licensing intent, and 
appreciate our reporting back when we do not understand their message, 
or that in our view their message is incoherent² or clashes with the 
intent of some of _their_ upstreams³.

¹ E.g. GPL (without version)

² E.g. some parts GPL-2 (not GPL-2+) and some GPL-3

³ E.g. OpenSSL vs. GPL (without OpenSSL exception).


# Bugfixing our licensing

Some linking within our own distribution have particular licensing 
needs, and our fellow package maintainers are then helped in their 
ensuring that by (not only reading _all_ involved source code, but also) 
cross-checking with the documentation done for each existing package.


# Use of Debian

Some downstreams have particular licensing needs, and are then helped in 
their ensuring those needs are properly met for the packages they choose 
to include.


# Setting (not only following) standards

Tracking copyright and licensing info is tiresome: It is manual work.

Ideally copyright and licensing info is expressed machine-readable at 
the source - i.e. by each upstream, and tools rely on that - i.e. "make 
doc" would imply "make credit" using copyright statements as source for 
e.g. AUTHORS file, and "make install" would imply "make legal" using 
licensing info also of linked libraries as source of a validation).

Some upstreams have adopted our debian/copyright format.  Some use other 
machine-readable formats.  But very few so far.  Why?  Our core business 
as distribution is to fuse together extreme amounts of projects, so 
obviously we feel the pain of tracking copyright and licensing info far 
stronger than each individual upstream project.

Debian invented and is bound by the Debian Free Software Guidelines.  
Those do not try identify the least we *must* do legally - they define 
what we *want* Free software to be.

Debian is famous for the DFSG, for covering many architectures and 
several kernels, for handling multiple concurrently installed 
architectures, for its long-term support, for handling multiple 
concurrently installed versions of same libraries, etc. etc.  All of 
that is hard work at first where upstream projects have little 
recognition ot the benefit of supporting it, but has gained interest and 
is becoming easier as upstreams adopt the structures we (and others) 
propose.

Please let's continue to lead the way: Because proper copyright and 
licensing is a crucial and integral part of Free software, and because 
Debian want that addressed technically sound rather than manually.


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: