can we include dosfs?

[Ben Gras]

All,

On Mon, Jun 20, 2016 at 12:50 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
> At various points in time I've used both of these.
> Don't recall any significant issues with either, but then I personally
> didn't use them
> much, I just did the ports for other users.  Also, there's a JFFS
> implementation
> that I wrote from scratch (just referring to JFFS docs).  Again, I didn't
> use that
> much either; primary user there as I recall was Bill Gatliff (many moons
> ago).
>
> Not sure what "CLI" you're talking about, but if its something I wrote,
> you're
> welcome to use any of it.

i mean e.g. this interface of umon to dosfs (just a googled link, sorry):
http://users.ece.utexas.edu/%7Emcdermot/arch/projects_fall_09/Team_07/umon-1.17/umon_main/target/common/fatfs.c

I was asking because of the Lucent copyright. Has it also been
Apache-relicensed?

> Again, I apologize for my "off-line" state...
> Too much stuff going on in and out of work to do much here.
> Ed
>
> On Jun 19, 2016 8:51 PM, "Ben Gras" <beng at shrike-systems.com> wrote:
>>
>> On Mon, Jun 20, 2016 at 4:33 AM, Chris Johns <chrisj at rtems.org> wrote:
>> > On 20/06/2016 12:24, Ben Gras wrote:
>> >>
>> >> I'm looking at building umon from RSB, to replace uboot, the next step
>> >> to mainlining all the beagle bsp support.
>> >
>> >
>> > Great.
>> >
>> >> It seems umon doesn't read FAT filesystems. Does anyone see any
>> >> license objection to including
>> >> dosfs.c (http://www.zws.com/products/dosfs/) as seems to have happened
>> >> with the original umon?
>> >
>> >
>> > How does that implementation compare with
>> > http://elm-chan.org/fsw/ff/00index_e.html? This is used by Xilinx in the
>> > first stage bootloader.
>>
>> They look similar enough. They both rely on some low-level device
>> access functions
>> to be provided by the user, which is fine. The license isn't terribly
>> clear I think:
>>
>> / FatFs module is a free software that opened under license policy of
>> / following conditions.
>> /
>> / Copyright (C) 2016, ChaN, all right reserved.
>> /
>> / 1. Redistributions of source code must retain the above copyright
>> notice,
>> /    this condition and the following disclaimer.
>> /
>> / This software is provided by the copyright holder and contributors "AS
>> IS"
>> / and any warranties related to this software are DISCLAIMED.
>> / The copyright owner or contributors be NOT LIABLE for any damages caused
>> / by use of this software.
>>
>> Do you think we can include it?
>
> Looks like MIT more or less to me. So no license issues that I see.
>
> Review the one Chris suggested though.
>
>> The dosfs license is, though unfortunately not any standard license,
>> clearer with
>> the no-strings-attached language, and I know it has been hooked up to
>> umon before,
>> so that seems lower-risk to me at the moment.
>
> What's the license say?
>
>> > I also have a JFFS bootloader implementation that can be added so umon
>> > can
>> > be booted from a JFFS2.
>> >
>> >> Can we then include the original umon CLI interface or is that a
>> >> license issue? If so I can re-implement it.
>> >
>> >
>> > I do not know and yes it would be nice to use what is available.
>>
>> Let's see what Ed says about including the CLI code. It is e.g.:
>>
>>
>> http://users.ece.utexas.edu/~mcdermot/arch/projects_fall_09/Team_07/umon-1.17/umon_main/target/common/fatfs.c
>
> +1
>
>>
>> > Chris
>> > _______________________________________________
>> > 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