X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-7.0 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Date: Fri, 04 May 2012 09:38:47 +0400
From: Fedin Pavel <p DOT fedin AT samsung DOT com>
Subject: Licensing questions (was: [bug] elf.h incomplete)
In-reply-to: <20120503152458.GB22355@ednor.casa.cgf.cx>
To: cygwin AT cygwin DOT com
Message-id: <4FA36B67.6080305@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0) Gecko/20120206 Thunderbird/10.0
References: <4FA281E3 DOT 4020008 AT samsung DOT com> <CA+sc5mnHw0CuSzaPiAV4ALQVEKs6_Nc20JrEvu-r121nZU3REg AT mail DOT gmail DOT com> <4FA2870D DOT 1030604 AT samsung DOT com> <4FA28961 DOT 2010407 AT cs DOT utoronto DOT ca> <4FA28F35 DOT 6060000 AT samsung DOT com> <4FA29070 DOT 1060300 AT gmail DOT com> <20120503152458 DOT GB22355 AT ednor DOT casa DOT cgf DOT cx>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 03.05.2012 19:24, Christopher Faylor wrote:
> Right.  I've noticed the incompleteness of elf.h from time to time too but
> extending it would be tedious since you can't just cut/paste from a GPLv*
> file.  Maybe one of the BSDs has something more complete these days?
  By the way, interesting question. It raises up from time to time here 
and there, but noone gives the answer...
  Is there any strict definition of "derived work"?
  The problem is: we have some #define in GPLed code. And i want to make 
some non-GPLed code interoperable. Consequently, i need the same 
#define. Exactly the our case. Of course i could copy-paste the code, 
and it would definitely be "derived work". But what if i don't 
copy-paste this code, but retype it by hands? Still a copy? Well, add 
some more cleanup. Take a piece of paper, write down all names and 
values. Drink lots of whiskey (wine, vodka) to erase own memory ;-) Next 
day take this paper and write own include. Is it still "derived work" ?
  But, after all, we still have only names and values, nothing more, and 
no matter how we made our version. Does "using the same name" 
automatically mean "derived work"? But in this case IMHO this as a 
nonsense. There's even an anecdote about Microsoft having to opensource 
all their stuff because their code uses GPLed "i++" fragment. Well, 
copyright infringement applies here as well, based on the reverse claim. :)
  So - where are limits of "derived work" ? And should this meaning be 
applied to public visible (like includes, APIs, etc) stuff at all ? 
Because if the answer is yes, this effectively forbids existence of 
alternate solutions to anything at all.
  After all, such reimplementations fall into "fair use" category.

  P.S. I would do it and submit a patch, but here at Samsung any code 
submitted upstream requires review and approval, in order to prevent 
classified information leak. This is of course possible, but this would 
be long way for such a trivial thing. You (Cygwin team) would fix it 
yourself faster.

-- 
  Kind regards
  Pavel Fedin
  Expert engineer, Samsung Moscow research center


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple