false positive, but a workaround...

Joel Sherrill joel.sherrill at oarcorp.com
Wed Jun 24 17:43:47 UTC 2015 


On 6/24/2015 12:23 PM, Gedare Bloom wrote:
> On Wed, Jun 24, 2015 at 12:07 PM, Ed Sutter
> <ed.sutter at alcatel-lucent.com> wrote:
>> On 6/24/2015 12:00 PM, Joel Sherrill wrote:
>>>
>>> On 6/24/2015 10:51 AM, Ed Sutter wrote:
>>>>
>>>> On 6/24/2015 11:48 AM, Gedare Bloom wrote:
>>>>>
>>>>> On Wed, Jun 24, 2015 at 11:44 AM, Ed Sutter
>>>>> <ed.sutter at alcatel-lucent.com> wrote:
>>>>>>
>>>>>> On 6/24/2015 10:57 AM, Joel Sherrill wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 6/24/2015 9:40 AM, Ed Sutter wrote:
>>>>>>>>
>>>>>>>> On 6/24/2015 10:41 AM, Jarielle Catbagan wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Jun 24, 2015 at 6:10 AM, Ed Sutter
>>>>>>>>> <ed.sutter at alcatel-lucent.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Jarielle,
>>>>>>>>>> Well, it took almost 5 hours to build the tools last night.
>>>>>>>>>> Obviously I
>>>>>>>>>> need
>>>>>>>>>> to upgrade the machine I have
>>>>>>>>>> this stuff running on at home!
>>>>>>>>>>
>>>>>>>>>> Anyway, this AM I was able to walk through what I thought I had
>>>>>>>>>> done in
>>>>>>>>>> work
>>>>>>>>>> yesterday, and unfortunately due
>>>>>>>>>> to the fact that I am working in two different locations on two
>>>>>>>>>> different
>>>>>>>>>> machines (very very inefficient, but I'm
>>>>>>>>>> stuck in this mode at the moment); I fooled myself yesterday
>>>>>>>>>> thinking I
>>>>>>>>>> had
>>>>>>>>>> stubbed out the __ctype_ptr__
>>>>>>>>>> declarations from docmd.c...  Unfortunately, I didn't :-(, so what
>>>>>>>>>> I
>>>>>>>>>> thought
>>>>>>>>>> built clean didn't.
>>>>>>>>>>
>>>>>>>>>> Anyway, I want to get you over this hump quickly 'cause this isn't
>>>>>>>>>> what
>>>>>>>>>> I'd
>>>>>>>>>> like you to be working on.  I really
>>>>>>>>>> want you to concentrate on beaglebone-specific stuff. That's the
>>>>>>>>>> important
>>>>>>>>>> stuff.  Today I brought my beaglebone
>>>>>>>>>> board to the office, and I've got it working clean now using a
>>>>>>>>>> local
>>>>>>>>>> set of
>>>>>>>>>> ctype.h and ctypetbl.c files as I had in
>>>>>>>>>> umon1.19.  For now this is temporary, but it may turn out to be the
>>>>>>>>>> most
>>>>>>>>>> efficient way to get around this.
>>>>>>>>>
>>>>>>>>> These files would conflict with the licenses, am I right? Would a
>>>>>>>>> permanent solution be to implement a new local ctype.h?
>>>>>>>>
>>>>>>>> Yep, that's exactly what I'm looking in to.  :-)
>>>>>>>> Just wanted to get you rolling meanwhile...
>>>>>>>
>>>>>>> All code in newlib has appropriate licenses. It would be easier to
>>>>>>> selectively pull in files from there. We just need to be careful
>>>>>>> to ensure we know versions so updates can occur. But that's true
>>>>>>> for every place you could grab from.
>>>>>>>
>>>>>>> New software has new bugs.
>>>>>>>
>>>>>>> Do you happen to have a master list of what methods you used
>>>>>>> in the original source base?
>>>>>>
>>>>>> Back when I originally gave Amar the tarball, I stripped out all that I
>>>>>> thought was questionable for RTEMS.
>>>>>>
>>>>>> The two blocks of code that are not mine are zlib and glib.
>>>>>> zlib: I got this from Mark Adler decades ago (umon/main/zlib/README).
>>>>>> glib: subset of libc code i pulled in from a freebsd github
>>>>>> (umon/main/glib/getglib)
>>>>>>
>>>>> zlib is fine we include it's source in RTEMS too.
>>>>>
>>>>> I don't know about glib, but if it is in freebsd / has BSD headers it
>>>>> should be ok.
>>>>
>>>> Regarding the current ctype problem, I was going to incorporate a
>>>> modified version of this file:
>>>> http://fxr.watson.org/fxr/source/sys/ctype.h
>>>> Is that legal for RTEMS?
>>>
>>> Sure. Just avoid any BSD license which requires author attribution.
>>
>> So things like this:
>> http://www.menie.org/georges/embedded/crc16.c
> This is fine. It requires non-attribution which is OK.
>
>> and this:
>> http://read.pudn.com/downloads10/sourcecode/math/41641/EE.C__.htm
>> are not acceptable for RTEMS, correct?
> Yeah this is bad.

I don't like unique coder-written license statements like this.
I am pretty sure his intent was just to let people use it and
not remove his name. But the wording is vague enough where
"give credit" could mean to show his name in a boot message.
That's attribution like the old BSD license required and we
try to avoid that.

And I am confused over how I could put that in commercial code
but not charge for this file in that commercial code.  I can't
figure out what that means in explicit compliance terms.

Sorry to pick on this one but it is a good example of why folks
should stick with known OSI-approved licenses that have clear
requirements for conformance. A specific project doesn't have
to agree to those requirements but they are clear.

And from an open source project perspective, the code base should
present a uniform view of compliance requirements. In this case,
if we are confused on how to comply, then the every end user is
going to be handed the uncertainty.

The RTEMS Project "rule" is simply to avoid passing along uncertainty
and opportunities for unintentional compliance problems.

>>> And try to get it all from a consistent version like FreeBSD 10.
>>>
>>> And I agree with keeping it all in simple portable C without cpu-specific
>>> versions is the way to go.
>>>
>>>
>>>
>>>>>
>>>>>> I have not updated them since original incorporation into uMon.
>>>>>> If necessary, I suppose I could update the glib files to be sourced
>>>>>> from
>>>>>> newlib (lemme know).
>>>>>>
>>>>>> Aside from a few other files that Cogent and a few other uMon users
>>>>>> contributed,
>>>>>> I wrote the rest.
>>>>>>
>>>>>>>>>> So, attached to this are three files:
>>>>>>>>>> ctypetbl.c:  put this under main/glib
>>>>>>>>>> ctype.h:      put this under main/common
>>>>>>>>>> mydiffs:     small list of diffs based on the tree after installing
>>>>>>>>>> your
>>>>>>>>>> initial set of 24 patches.
>>>>>>>>>>                         most of these changes you probably have, the
>>>>>>>>>> important
>>>>>>>>>> one is in main/make/common.make so that ctypetbl.c is built.
>>>>>>>>>>
>>>>>>>>>> If you can incorporate these changes into a tree that starts with
>>>>>>>>>> the
>>>>>>>>>> master
>>>>>>>>>> and has your initial 24 patches applied,
>>>>>>>>>> you should be good to go.  I know I should be using git to email
>>>>>>>>>> you
>>>>>>>>>> patches, but I'm still trying to figure out how to
>>>>>>>>>> do that and I don't want you to be delayed by that.
>>>>>>>>>>
>>>>>>>>>> Does this make sense to you?
>>>>>>>>>
>>>>>>>>> Yes.  Ok, I'll incorporate those files and I believe you are right
>>>>>>>>> that everything should be all set.
>>>>>>>>>
>>>>>>>>>> Ed
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> umon-devel mailing list
>>>>>>>>>> umon-devel at rtems.org
>>>>>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>>>>
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> umon-devel mailing list
>>>>>> umon-devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>
>>>> _______________________________________________
>>>> umon-devel mailing list
>>>> umon-devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>
>>>
>>>
>>
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

More information about the umon-devel mailing list