[I CC: this to the eCos list, because the licensing issue is frequently
raised there, too. --R]
Charles Manning wrote:
> On Sunday 26 October 2008 01:36:26 Emmanuel Blot wrote:
>>> Sounds great, thanks! (Or if you have no time to clean it up, I'll be
>>> glad to see it anyway.)
>> Here it is:
>> http://moaningmarmot.blogspot.com/2008/10/yaffs2-for-ecos.html
>
>
> Hello all.
>
> I am very pleased to see an eCos port, but I would like to raise the licensing
> issue.
>
> eCos is released under the eCos license which has some similarities to GPL,
> but has an important exception, that you may also link in
> proprietary "application code".
[snip]
> YAFFS GPL licensing does not provide this exception
>
> YAFFS is released under GPL or is available under alternate licensing from
> Aleph One.
[snip]
> If I have misunderstood something, then please help to clarify.
Of course I can only speak for myself, but I wanted to be license-aware
in my approach. My intention is the following:
1) make a wrapper layer between the eCos file system package and YAFFS
2) make a wrapper layer between YAFFS and the eCos NAND Flash package
both based solely on published API information by YAFFS.
As far as I understand, these two wrapper layers would probably not be
GPL'd, in the sense that they do not copy any YAFFS code. When I am done
writing, these two wrapper layers are fed back to eCos. They can be GPL
+ eCos exception, if my reasoning above is OK.
If users want to use YAFFS on eCos, they separately download the YAFFS
code from Aleph One, and compile the direct/ stuff to be included in
their eCos application. It is most certainly not my intention to feed
any GPL'd YAFFS code to eCos -- the eCos people won't hear of it, for
starters.
If the users' project is GPL, fine. If their project is not GPL, then
they will need to approach Aleph One for a commercial licence. In short,
they will follow the YAFFS model. (For the record: our project is GPL.)
Is this approach satisfactory?
Thanks,
Rutger Hofman
VU Amsterdam
(text/plain)