You need to rewrite it to fulfill all the licensing requirements.

Many things in FASTFAT aren't needed for us yet, so in theory (IANAL), even stripping out those parts and keeping the rest of the driver intact would be ok -- based on my knowledge that copyright law states that you need to copy > 70% for it to be considered "the same work", anything less than that and it's okay (again, IANAL).

So my opinion (IANAL!!!) is that if you use the WDK FASTFAT driver as a reference source, and write (on your own, not copy pasting) the same interfaces/function names/data types/structures (which are, by definition, not copyrightable), and then write your own code (use a different layout, optimize the functions, use other variables/similar code logic, etc) and additionally, only implement, for now, say half the driver, you'd be 100% legal, at least in the US and other countries that signed the WIPO I think it's called.

Best regards,
Alex Ionescu


2009/1/7 Pierre SCHWEITZER <heis_spiter@hotmail.com>
Hi,
how far can we use it? It must be under Microsoft copyright. Moreover, it must be quite complete, so it would not be a rewrite, just an importation.
P. Schweitzer

Date: Wed, 7 Jan 2009 13:50:39 -0500
From: ionucu@videotron.ca
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers


The WDK ships with a working windows 2003 fat driver... rewrite it based on that one.

Best regards,
Alex Ionescu


On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin <aleksey@reactos.org> wrote:
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:

> On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin
> <aleksey@reactos.org> wrote:
>>        Hello,
>> I recently spent some time experimenting with various Cc rewrites we
>> have in our tree, and before that I extensively tested our fastfat
>> driver in a real NT environment (MS Windows 2003).
>>
>> The conclusion of the above work is that our fastfat driver either
>> needs serious bugfixing, or a rewrite is needed. It corrupts
>> directory tables in a real NT, leads to unusual behaviour of cc-
>> rewrite branch, and may have side effects on arty's newcc.
>>
>> Before this is done (bugfixing or rewriting, developing and testing
>> against a Windows 2003 at least, not ReactOS), it's meaningless to
>> continue any other work on Cc and related Mm parts.
>>
>>
>> WBR,
>> Aleksey Bragin.
>
> Let's make a plan!  I want a proper branch for the cc rewrites.  I'd
> like to have a live branch, not this half branch, half patch form that
> cc_rewrite is in now.  Perhaps this would be a good place for the
> working fastfat to be dropped when finished.
>
> I have time and resources that I could put towards this goal.  Let's
> get fastfat working on 2k3, then drop it into a new cc branch and get
> it working..
>
> <Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
>
> WD

Live branch needs constant merging. Have a look at amd64 bringup
branch: most of commits are merges. That mm.patch is an ugly way of
keeping the branch always uptodate...

Anyway, I have made some fixes to the branch, so if someone wants to
test, I would need to commit my changes.

As for the fastfat, I think the problems is in synchronization
somewhere, not in a pool corruption, passing invalid parameters,
misusing Cc API, or anything like that - I fixed that already.

Another idea was to take ext2fsd by Matt Wu, which is supposed to
work, and convert it to a fat32/16/12 driver.


_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


Discutez sur Messenger oł que vous soyez ! Mettez Messenger sur votre mobile !

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev