This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add Blackfin support in newlib


Jeff Johnston wrote:
Hi Joel,

Just to clarify. I had discussed this ahead of time with Jie and I am ok with it. They (Analog Devices) requested to use the LGPL instead. This is fine when segregated into bfin machine-specific directories only. There is already an LGPL license in COPYING.NEWLIB that applies when building x86-linux. It will be updated to apply when building for BlackFin.


I am ignoring Linux and Cygwin because both have their own full collection of GPL and
LGPL code that the user must be aware of and adhere to the license terms. Plus, both
have dynamic linking and the LGPL is satisfied under terms of 6b. So Linux is not the
issue here.


Once you move off of Linux and Cygwin, most newlib applications are embedded
and statically linked. Up to this point, all embedded ports of newlib have placed no restrictions
on the end user's application. The Blackfin port will place restrictions that other ports do not have.


A bfin-elf compiled program linked with this LGPL code will be a combined or derivative
work according to the LGPL. I think Section 6 is the one we would fall under. Since we are
not dynamically linked (6b), the end user's application would have to provide source in
a way that is compliant with 6a, 6c, 6d, or 6e.


Did Analog Devices really intend to apply this requirement on people fielding
Blackfin applications using newlib (from LGPL section 6) where the work is the
end user's application linked with this code. Here is the kicker phrase from the LGPL
that they must meet.


"distribute that work under terms of your choice, provided that the terms permit modification
of the work for the customer's own use and reverse engineering for debugging such
modifications."


So all bfin-elf/newlib compiled applications would have to be distributed in a form allowing
the customer to modify and debug them. Do you hear those embedded applications developers
screaming about letting customers relink their software? I wouldn't want to ride in the car with
that ABS control system. :)


If they want to stick with a GPL variant, I suggest doing what others run-time libraries have
done and add an exception paragraph that they don't require the user to meet section 6 of
the LGPL.


From a 30K feet view, why would you want bfin-elf to have different end user requirements
than other *-elf ports? Even if I didn't have a problem with this case, I can't help but believe
that the inconsistency is going to lead to users unwittingly violating the license.


This is an issue near and dear to my heart as it is one we have wrestled with many times
in the over 15 years that RTEMS has existed. Sorry if this sounds like a rant. :)


--joel
-- Jeff J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]