-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build Flags #7
Comments
This is well within scope. Background point: The tooling I'm using here---Common Form---has a plenty good solution for conditional templating. But I don't think that's the right approach. There is no one set of immutable terms to do all support deals. Switching terms on and off is necessary. But I don't think we should be switching terms on and off with software, and spitting out multiple variations. I think we should do the switching in the legal terms. All of the terms you mentioned currently do that kind of switching:
I envision that most deals on these terms will never involve making a copy of the legal terms themselves. Folks will make copies of order form templates that reference these terms by version, published on indieopensource.com, and sign that order form. Why that approach, rather that a Creative Commons style menu? A few reasons. First, there are several provisions that folks may want to switch off. That's recipe for a combinatorial explosion. We would inevitably end up with far more variations than CC offers. Second, support deals involve far more "configuration" than standardized copyright licenses. Since folks looking at this project are likely to know open source, compare to open source licenses. Standard licenses split between template-style forms, like MIT and BSD, where you're expected to fill in a copyright notice within the license text, and fixed forms, like GPL and Apache, which expect you to put that information elsewhere, as in header comments. Lawyers tend to prefer fixed forms for exactly the reason you brought up: Less chance of mangling. But we need to know who's giving the licenses. We have to fill that bit in. These support terms expect an order form with lots more blanks filled in. Since we're already doing a separate document for details, we can reuse that order form for "configuration": turning terms on or off. In some areas, the terms can do that automatically. The current terms switch some parts on or off depending on whether the Developer is an individual or solo firm, or a company. #1 improves and refines that approach. For other switchable provisions, the legal terms rely on the order form to switch them on or off. That's the case with the three provisions you listed. |
I apologize if this is out-of-scope, but one challenge I have is sometimes I need to remove a clause (or add one back in) at the request of a client. The worry I have is that I could end up screwing up the contract, especially when it involves numbering and sections that reference other sections, or removing a required clause, or some other cascading effects.
Example sections I probably would not want in my base contract:
But I may want to include such language for a larger deal. So being able to add / remove clauses without breaking the legal document is a huge plus.
My dream would be something like the Creative Commons where there are a few different permutations of the contact that I can choose with a few checkboxes (support-contract, support-contract-credits, support-contract-credits-dedicated-escalation). I am not sure if this is feasible or how complex it makes things, but could be very useful.
The text was updated successfully, but these errors were encountered: