7 Jan
2009
7 Jan
'09
8:13 p.m.
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(a)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(a)videotron.ca
To: ros-dev(a)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(a)reactos.org>wrote;wrote:
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin
<aleksey(a)reactos.org> wrote:
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
------------------------------
Discutez sur Messenger où que vous soyez ! Mettez Messenger sur votre
mobile ! <http://www.messengersurvotremobile.com/>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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