Re: Free FAT16 Filesystem



Dave,

I can walk from this without losing a thing. I'm not that important. This is
now because of the thousands of people that have missed out without there
being an honourable reason.

Dave, I made every effort 3 weeks ago to have you understand that if you
were to get greedy, that this is where we would end up.

> and this is he first time someone has tried to lock my tools out of the
results.

That's just not true. My license terms read "It is released free of charge
for any purpose, including both commercial and non-commercial uses." I have
already explained to you that there is only the single impediment that
restricts you or anyone else from adapting and using the code to promote his
or her own software tools, and that is that its as yet un-releasable. You
withdrew permission.

> I did make the error of assuming he was using my tools, as it was not
indicated
> otherwise.

No, that's not true. You have had 30 days in which you chose to plead
ignorant. I have sent you countless e-mails describing precisely my
activities and intentions. You agreed without reservation, so the work was
performed.

What is clear to me is your motivation. You now have in your possession a
piece of code that is highly marketable, and you appear to have chosen to
preserve a market for it by eliminating its competition. Better than that,
you seem to believe that you have manipulated someone into performing the
value adding process for you.

> Unfortunately he has chosen to close that door.

No, that's also deceitful. The only thing preventing me from releasing the
code free of charge for any purpose is that YOU have withdrawn the FAT12
code contribution's permission. Now you appear to want me to do the rest of
the hard work to adapt it so that you can sell more compilers, and then shut
the door to preserve a greedy market strategy once more.

Dave, you have stated to me that use of the MDCFS code in the development of
the FAT16 code would have no economic impact "since MDCFS is not a revenue
source for me". It is now up to you to be true to your word. Prove me wrong
and let me release the code I worked so hard on for everyone to use.
Otherwise, we will all be watching your website to see just how long it
takes you to prove what I have suggested absolutely true.

Regards,
Murray R. Van Luyn.


"Dave Dunfield" <Dave.Dunfield@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:QcQJe.862$Dd.2598@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Jon,
>
> >Your desire that the modifications of your code be at least compatible
> >with your compiler are quite reasonable. But since this has been
> >aired now in public I've a couple of questions which I believe are
> >fair to ask. (I'm in an ornery mood, this morning? Perhaps.)
>
> >No need to answer them, if you feel that an extended discussion here
> >is inappropriate -- in that case, these will just lay on the table, as
> >it were:
>
> I agree that this should be put to rest, however in the light of recent
> activities, I will provide brief responses:
>
> >(1) Who was the professional in this situation, Dave? I accept that
> >Murray did not mention Keil in his correspondence to you. But why
> >didn't you ask? It seems to me, an outsider of this relationship,
> >that if something like this slips between the cracks, so to speak,
> >then the fact that it did lays more to your error than his. His
> >standard of care is less than yours, I believe. Of course, regardless
> >of this question, I do think your position is a reasonable one. I'm
> >just wondering how _you_ let this slip through without being asked.
>
> For several reasons:
>
> The inital contact came from the support channel on my web site, and
> the individual identified himself as one of my customers - I did make
> the error of assuming he was using my tools, as it was not indicated
> otherwise.
>
> The original MDCFS.C is very generic, not targeted to a particular
> processor, and barely targeted at my tools (the disk read/write
> examples given in the distribution are inline Micro-C/86 assembly,
> but otherwise the program is fairly standard). It seemed reasonable
> that he would keep it that way.
>
> And frankly, it never occured to me ... I've granted use of bits of my
> source code to hundreds of people (most anyone who asks), >
> But your point is well taken, I will indeed be more dilligent in the
future.
>
>
> >(2) Let's say that Murray had, instead, developed a single set of
> >source code from your FAT12 MDCFS code that was able to be compiled on
> >both your compiler AND under Keil's, as well. In other words, it used
> >#if type statements to allow it to compiler for either product. Would
> >this then still remain a problem for you? In other words, would you
> >_require_ that the result of Murray's efforts _also_ be incompatible
> >with your competition? Because if that is the case, it seems to me to
> >place an even greater emphasis on my first question.
>
> I would not have a problem with that, in fact in correspondance with him
> this morning, I suggested that either a) he could release it in a generic
> form similar to the original code, or b) I would help him if required to
make
> it compatible with both toolsets. Unfortunately he has chosen to close
that
> door.
>
>
> >I think the letter you presented was very clear and given that you had
> >no idea that it was being ported to Keil as well as being enhanced,
> >quite understandable. I'm just not sure why you let this one get so
> >far away from your interest without ever asking a question that
> >probably should have been asked. You are the professional one, held
> >to the higher standard, in this partnership -- from my otherwise
> >ignorant perspective.
>
> Up until yesterday, it was all very friendly and I wasn't worried about
it.
> When I realized he had locked out my tools, I asked for it to be removed,
> figuring that we would probably work something out later ...
>
> Regarding your original question "Who was the professional in this
situation?",
> I can only say to please take a look at the comments that he has posted
about
> me on his web site and draw your own conclusion.
>
> This is as far as this should go in a public forum - if anyone wishes
futther
> clairification of my position, please contact me privately.
>
> Regards,
>
> Dave
>
> --
> Dunfield Development Systems http://www.dunfield.com
> Low cost software development tools for embedded systems
> Software/firmware development services Fax:613-256-5821
>


.



Relevant Pages

  • compiler and metadata, request opinions...
    ... a lot of the upper/middle compiler machinery is still lacking (such as ... embed the metadata directly into the object modules (the reason being that ... request for a particular piece of information is embedded in a symbol (sort ... it will be loaded into an in-memory version of the database. ...
    (comp.compilers)
  • misc: compiler and metadata...
    ... a lot of the upper/middle compiler machinery is still lacking (such as ... embed the metadata directly into the object modules (the reason being that ... request for a particular piece of information is embedded in a symbol (sort ... it will be loaded into an in-memory version of the database. ...
    (comp.lang.misc)
  • Re: OT Myths of Creationism
    ... Dave McNulla wrote: ... and 2) there is no scientific explanation of the 'start' ... evangelicals and scientists modernize their thoughts on a regular ... let me try some reason one more time and leave ...
    (alt.sports.basketball.nba.la-lakers)
  • Re: For Buzz; The Answer
    ... You realized that my purpose of government being *protecting the ... it's become what Dave is. ... sunuvabitch," nor have you given any reason for government. ... Well, maybe not stupid, just a fool. ...
    (misc.news.internet.discuss)
  • Re: "Sorting" assignment
    ... issue on some ancient compiler doesn't make a lot of sense. ... to his on a few commonly used platforms and compilers, ...  Be sure and call the swap ... reason to find algorithms which operate independent of it. ...
    (comp.programming)