Sure, I don't have a problem with that. I don't think(?) you can
copyright a database schema anyway, but if you could that seems pretty
dumb to me :). Any bits you can pick up from the paper is fair game
as well - the GPL part applies to the source code (as you mentioned)
and the test cases.
You may want to investigate other alternatives to the database schema
though - some things to consider:
- Tup uses a create_list and modify_list (and with variants,
config_list) to store which files have changed. You may only need a
modify_list, or this could even be combined into the node table with
an extra column designating the state (changed / unchanged)
- Tup uses a 'style' column in the link table so that it can keep
track of links supplied by the user (in the Tupfile) vs links created
by running the command. Depending on your design, this may not be
applicable.
It's easier to change this stuff up front than it is later, so it is
worth spending some time on. Though, tup has been through 14 different
database schemas, so I guess it's not that hard to change...
Also, it sounds like you are planning to incorporate the build system
with the compiler/linker? If so, you may want to consider these
bigger-picture questions:
- Will you want to support other external tools? (eg: scripts that
generate source code, 3rd party programs, anything else that isn't the
Solaris compiler/linker)
- If so, will they be built into the tool as well?
- If they aren't built into the tool, why is the compiler/linker
different? Ie: What do you hope to gain by combining them that isn't
served by a more general purpose tool?
Anyway, I wish you luck! Feel free to post back here when you get
something for people to try out :)
-Mike