[dev] Horde library license headers (notices from SUSE Legal) - please advise

Jan Schneider jan at horde.org
Mon Aug 29 22:11:57 UTC 2011


Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

>>>>> When I more-or-less took over maintaining Ansel, the Exifer code was
>>>>> already incorporated into Ansel. The original code was released under
>>>>> the GPL (but is no longer maintained by the original author - it was
>>>>> adopted by zenphoto.org, still under the GPL). This is why the notice
>>>>> appears in the Ansel CREDITS doc. This should probably be moved
>>>>> somewhere more appropriate - maybe
>>>>> http://wiki.horde.org/Doc/Dev/CopyrightLicense ?
>>>>>
>>>>> Likewise, when I started maintaining Horde_Image, it was already
>>>>> released under the LGPL. For Horde 4, I moved the Exifer code to
>>>>> Horde_Image, where I thought it really belonged, but failed to notice
>>>>> the licensing discrepancy.
>>>>>
>>>>> Personally, I don't like the LGPL, but as I said above, Horde_Image
>>>>> was already licensed that way when I started work on it. So, suffice
>>>>> to say, I wouldn't mind if, going forward, it is released as GPL.
>>>>> Though I have to admit I don't know enough about licensing changes to
>>>>> know if this is possible.
>>>>>
>>>>> OTOH, The Exifer code in question is only one of a few possible
>>>>> drivers for working with EXIF data, so theoretically, one could not
>>>>> include it if it is being used in a way that violates the GPL
>>>>> licensing. OTOOH, the orginal author did give us permission to
>>>>> incorporate it into Horde - though he is no longer the maintainer.
>>>>
>>>> I think as long as the authors of the Horde_Image code agree, there's
>>>> nothing stopping you from licensing it as GPL. On the other hand, if the
>>>> library is LGPL and uses GPL code, this should also be no problem by
>>>> itself. Users just need to know that GPL parts are included.
>>>
>>> At the very least, I would like this to be released under either LGPL
>>> 2.1 or GPL 2. My guess is that these links are just outdated, i.e.,
>>> they were never updated to point to the older license when the newer
>>> version 3 licenses were released. I don't recall any discussion as a
>>> group on moving to any of the version 3 gnu licenses. There are other
>>> examples of this in our code, mostly in older libraries.
>>>
>>> We should decide on this as part of the process of updating the
>>> copyright/license headers to point to a local copy of the license
>>> used. I believe that was another thread we were discussing, correct?
>>
>> Yes, these are three separate issues:
>
> Ok. Well, to add my votes then:
>
>>
>> * Shipping license files at all (I think jan has voted for it and it would
>> help me, too)
>
> +1. Shipping license files OR linking to locally hosted versions are  
> both fine with me. If it helps downstream packagers, then shipping  
> them makes sense.
>
>
>> * Ambiguous links and codes for GPL and LGPL versions in files and metadata
>> * outdated versions of the GPL2/LPGL-2.1 files shipped with H3 files
>>
>> In fact I only know of Horde_Ldap as explicitly labeled LGPL-3.0.  
>> The rest is
>> just defaulting to the most recent GPL/LGPL link (though some are fixed by
>> now).
>
>> If there is a decision in any direction I'd volunteer some time to get at
>> least framework/* and the released apps straight. I guess it's  
>> biting me more
>> than most others involved.
>
> My vote would be to make any code not explicitly labeled version 3  
> to be released as version 2. Even for version 3 released code, I'd  
> investigate why the decision was made to make it 3. In the case of  
> Horde_Ldap, there are lots of authors listed, so it might not have  
> been our decision(?).

Horde_Ldap is special because it's a port from Net_LDAP2.

A few packages that are ported from Ruby/Python might have license  
requirements too. Chuck should be able to tell, because all those  
package were created by him or Maintainable.

For all other packages it's safe to assume that there was *not* an  
intentional decision made for version 3 license or  
"always-the-most-recent-version" license and they should be explicitly  
linked to version 2 licenses.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list