[Box Backup-dev] Licensing issues

[Ben Summers]

We never came to a conclusion about this, but now is the time to  
decide it once and for all.

I propose that the project stays with the BSD license (possibly even  
dropping the advertising clause). This is for my own self-interest,  
as I would like to be able to pull back changes for my own use.


In this case, I will contribute the following code to the project:

* Generic database interface, with drivers for sqlite, MySQL and  
Postgres: abstracts differences in APIs and SQL, makes queries a  
couple of lines of code. Autogeneration of query objects can be used  
to make type safe and nicely named results in your own.

* SMTP client: might be handy for sending alerts without hacking  
around with scripts.

* Web app framework: perl and C++ combine to generate standalone HTTP  
server web apps. All the boring stuff is done for you, leaving just  
the business logic. Templating and i18n done nicely. A bit of a  
"first go proof of concept" -- I would really want to make a lot of  
changes -- but good enough for doing commercial web sites and lovely  
for writing web apps which talk to Box * components.

These components would need autoconfing, but it should be little more  
than just changing the #defines (if any). They all basically rely on  
the lower level libraries, which have all been done nicely.


In addition, Charles L is keen to work on the Win32 side of things,  
but would need to contribute some code from his libraries to do this  
effectively. From my discussions with him, I think he requires a BSD  
license for much the same reason as I do. Hopefully he'll follow up  
with details.


As a compromise between those who want to use the GPL to protect  
themselves from people ripping off their code, I would be happy for  
the basic libraries to be BSD, but the Box Backup engine to become  
GPL. (To clarify, I mean the code in lib/backup*, bin/bb*). This will  
require a bit of work to separate out, but not a huge amount as the  
framework supports building stuff outside the main tree. Although the  
release packaging will have to be redone a bit to combine everything  
together.


I don't mean to impose my view onto anyone. I do realise that this  
latest release wouldn't have happened without all the other  
developers, and I would very much like to see the project continued  
by us all as a team. I just feel that unless something is laid down  
like this, we're just going to discuss it and never come up with  
anything.

I am more than happy to discuss this offlist with anyone, but would  
like conclusions to be posted here on -dev, and resolved quickly.

Many thanks,

Ben