Can I use tup's SQL schema in my BSD licensed project?

34 views
Skip to first unread message

Alex

unread,
May 23, 2012, 3:39:21 PM5/23/12
to tup-users
Hi! I've been checking out tup and I really like the design. I want to
build my own proof-of-concept build system and I came across tup while
looking for inspiration. I love the design (and the whitepaper was
extremely informative) and I was hoping I could reuse the SQL schema
in my project. I want to use the 2 clause BSD license because the GPL
is incompatible with Solaris' libld (rather than invoking the compiler
and linker, I want to build a tool which effectively *is* the compiler
and linker).

Would this be okay? I don't want to reuse any tup's code (though it
looks good!), JUST the database schema.

Thanks!

Mike Shal

unread,
May 24, 2012, 10:24:23 AM5/24/12
to tup-...@googlegroups.com
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
Reply all
Reply to author
Forward
0 new messages