Forum OpenACS Q&A: Template contract for OpenACS projects

Actually, when negotiating a contract for a commercial OpenACS project a substantial part of the provisions (terms) in it is general in character, while the rest deals with matters that are project or party specific. A great deal of time is wasted if the parties have to (re)negotiate the general part of the contract, instead of just the particular part. In fact, the business parties signing the contract aren't best suited to specify the standards of behavior that all OpenACS projects should meet. These standards are upheld by the community, and should be formulated by the community.

I've written a draft template contract for OpenACS projects that, after community feedback, we hope to be able to utilize when negotiating our own projects. The dotLRN boards (EB and TAB) have already seen it, and toned down the unrealistic visions of there ever forming a consensus among financers around a universal standard contract. Still, nobody's arguing against the idea of having a contract template around for the benefit of those parties who don't already have a standard contract of their own, and who want to be sure that their project is conducted according to community standards.

Please read through the draft and see if it contains any misconceptions or bad formulations. Modeled on the contracts used in the military industry, I've tried to keep the contract informative yet brief. Right now the draft is published in ETP form, for the sake of easy editing. Should anyone be interested in the resulting contract template, it will be available as a Word document (.doc) or some other format allowing the filling in of the particular project specifications. The pretty version comes with a front page where the contracting parties are specified.

Thanks for beginning this thread. This is important and I hope to that in the coming weeks and months we will progress in this direction. As you note, we need to move to the generic piece that we can all agree on and then add contract language that's institution specific. Again, I commend for you starting the process.

Al

- I find the following statement a little too strong:

"However, the copyright holder (enjoying guardianship, if not ownership, of the open source code) is obliged to maintain the code in the OpenACS environment."

as it might be taken to mean legal obligation. Also, there is no clearly defined ownership sctructure for OpenACS software, at least not tied to any sort of obligation. Contributors and companies come and go but the code lives on.

- "Under no circumstances will a new package be accepted as an OpenACS package until it has documentation."

This statement is simply not true today and never has been AFAIK. It may be an ideal worthy of aspiring to but it's not a claim we should make presently. Can you soften this sentence a little?

- "The universal aspect of an OpenACS project business relationship is that the COMPANY provides highly specialized code development services (not products) paid by the CLIENT."

I'm not sure what you mean by "highly specialized" but I'm not convinced this is a universal aspect of what we do. Rather, the emphasis is on generic code that is useful to many parties. Examples of such projects include I18N, workflow, and time logger.

- Your section about business relationship layes down sound principles about communication confidentiality etc. However, none of this is strictly speaking related to OpenACS. I guess I am not comfortable with the idea of bundling a web platform like OpenACS with a certain business practice not to mention trying to enforce such a practice. You can recommend or even dictate business rules to your clients, but don't do so under the name of OpenACS - I find it confusing.

- "When the project starts the CLIENT shall make a public announcement of this in the community forum on the OpenACS website.".

This is really an excellent guideline that I wish all projects would follow! If community involvement was bigger we could reach much higher levels of reuse and synergy. Again though, I would soften the language and say "should" instead of "shall", "are encouraged" instead of are "obliged" etc.

- "The COMPANY shall post an initial RFC to the forum, and from then on weekly or biweekly status reports, continuously (intermittently) commit the development code to the development branch of the OpenACS CVS tree, and in general refer development issues to the open forum, where community members can offer answers, suggestions, comments, and other feedback."

Once again, I couldn't agree more with the spirit of these sentences. However, as general guidelines, I think there is a too high level of detail here. The frequence of reports and which branch is used may need to vary from project to preject.

The general problem I have with your documents is its lack of cohesion stemming from it trying to cover at least three somewhat unrelated things - the GPL licence, sound business pratices of a consulting company, and desired behaviour within the OpenACS software project (how we want the community to function). Also, I would like the document to have a more positive encouraging tone rather than the dictating tone of a legal text. I guess the purpose of the document is somewhat unclear to me.

Ok, that's enough random rambling from me 😊 I hope I don't come across as overly critical as I really want to applaud your efforts and I hope that my feedback gives you some new perspective and ideas for improvement.

Just a quick note before I forget. I think the best place to funnel efforts of outlining the community process is our dusty how to contribute page. This page is one of my favorites as it goes to the essence of what the community is about - contribution and sharing. It's linked after a bold text right off the OpenACS homepage so people are not totally unlikely to read it. How about adding a section called something like "I am using OpenACS for a project" or "I'm running an OpenACS consulting Company". I think that would be excellent.

Behaviour in the OpenACS community cannot possibly be part of a *legal* contract betweeen an OpenACS company and a client. Not only is it legally not feasible but it would also violate the spirit of the GPL (freedom).

The interesting distinction between the GPL and some of the legally binding (potentially) rules that you are proposing is that the GPL adds to the cliets freedom whereas your rules do the exact opposite.

A major challenge (maybe *the* major challenge) that any OpenACS-based businesses face is that of attracting new clients, to a large extent this usually involves convincing them of the merits of open source. Now, a client that doesn't believe in Open Source, and doesn't believe in sharing source code and/or ideas with the community, is very unlikely to enter into any such contract that you are proposing. On the other hand, clients who do belive in those ideas, or can be convinced by us that they are beneficial to them, will follow recommendations that we give them without any need for legal enforcement. So either way, legality in this area achieves nothing, whereas selling people on the benefits of open source along with sound recommendations can achieve a lot. We don't want to be in a situation where clients are obliged to comply with open source behaviour. Instead they must participate out of their own free will because they realize that this is beneficial to them. Think of examples such as MIT, Heidelberg, and Greenpeace and you must realize that this is true.

First, the content of the future statement of the community standards is not decided upon yet, so how potential clients might react to my particular initial draft (which I don't think much of myself) doesn't say much about their attitude towards the actual thing.

Second, what we are trying to produce is a statement that refers to such projects that result in code going into the OpenACS toolkit, so any other type of projects (however commercially important to you) are quite irrelevant in this connection.

Third, no potential client in such a project will be compelled to sign any business contract containing the readymade statement, but they are free to do so if they find it to be a handy service in their quest for good relations with the OpenACS community.

From this we conclude, with a sigh of relief, that there is absolutely no need for us to worry about how potential clients that are hostile to the open source ideal would react if forced to agree to the exact statements in my initial draft. This is not even a possible scenario.

This leaves us discussing such OpenACS-friendly clients as MIT, Heidelberg, and Greenpeace. You seem to be supposing that mature institutions like these, in their business relations with professional developers, feel uncomfortable adhering to explicit rules, and that they would rather keep agreements informal - and thus uncontrollable and unenforceable. Perhaps you suggest they are most content when they can just seal a deal with loose promises and a firm handshake.

If you were to study the contracts that Collaboraid have signed with these institutions, I'm convinced you'd find that they are full of (legal) terms and provisions stating what you were supposed to perform in order to make your clients happy. And I'm also convinced that if you hadn't performed so darn well, these loveable institutions would have pointed to the contract to show you that the job performed didn't meet the professional standard that was agreed upon. It would be their right and their responsibility to do so.

The underlying tone in your posts is a surprisingly anarchistic (or naive) one: that explicit rules represent a failure and shouldn't have to exist among friends. The GPL states explicit rules, but because its spirit is that of "freedom" you disregard the fact that it is as dictating as any other legal contract. It seems that you don't like the idea of being tied to the mast. Yet those who let themselves be tied to the mast - or demand to be, like Odysseus (Ulysses) in Homer's Odyssey - do so to free themselves from harm.

When business parties negotiate and sign legal contracts or agreements between them this is not because they are stiff and boring and don't like to be friendly with the people they work with, but because they like to stay friendly with them when conflicts appear. Professionalism is not something people escape to when they can't establish friendly relationships with others, but something they embrace because it improves the work process as well as its results.

Forgive me, I feel really patronizing explaining this to you. As part of a true quality company you surely know this, so I don't see why you choose to suppose that a legal statement that is not only a contract with the company performing the work but also with the community accepting the work is something that would repel clients. Indeed, it would provide the best guarantee that the project is conducted in a professional way that enforces the good relationship with the community no matter what company the client turns to. A quality seal.

Staffan,

You write:

In principle, the contracts for commercial OpenACS projects are now completely confidential matters between two parties: company and client. In practice, however, these parties have no greater wish than to conduct their projects in a manner that is in line with the informal but strict standards within the community.

What are the strict standards of the community? Are they not based on engineering and social/communication standards?

A business contract is the explicit definition of a relationship between parties (business and client).

The relationship between individual participants and an open-source community is based on gift cultural values (shared philanthropy), economic cultural values (shared self-interests, trade) and individual concepts, willingness and ability to participate within the community. The cultural diversity of this international community brings other factors. The interelationship of the community is only limited by the explicitly defined publishing license. Regional common or explicit law may also shape it.

Mixing the two kinds of relationships places additional limits on the possibilities at best. Any attempt to refine the scope of the contract between individual participants and the community will inevitably conflict with individual participation and contribution of some. Not to mention that the legal binding of including the open-source community as a party is not enforceable, and could nulify the validity of the contract.

By comparing a basic contract of an open-source project with a proprietary project, it should be clear that the relationship remains between the two parties. Period.

The contract is not transferable to the community, nor can the community be held responsible for any obligations of any individual participant within the community.

A joint-venture could be arranged between multiple parties, but that still doesn't translate to the community.

In effect, the community is an abundant resource from which one can harvest from and give to without obligation of indebtness (though particpation is much much appreciated).

Recall the GPL:

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Sections "0" and the NO Warranty Clauses 11 and 12 provide more details. This implies that there is no liability to the community (and copyright holders) for any mis-use by any legal entity that choses to use it.

Perhaps the basic contract could focus on defining a business relationship between a business using open-source software and their clients?

You state that the "terms between businesses and clients are confidential", but most of the terms do begin with a generic behavioral, nonlegal template of sorts. Consider that there is little practical legal recourse between international business relationships; They must be fostered on a social level to work. Relying on the binding of legal contractual terms should be avoided if at all possible. Still, a generic contract could be made for standard practices between a company and it's clients within a region.

Doesn't a business relationship depend on the nature of the business? There are a variety of business models using the OpenACS community resources. The contracts vary significantly. Above, I suggested one way you could foster business relationships to include open-source resources while not limiting your market to those who already know about and accept open-source methods and values. As Malte mentioned previously, you might want to contact a lawyer to be sure to cover the applicability of any contract law to your business model.

Really, it seems this thread is about goals and guidelines for those who want to extend the OpenACS toolkit --regardless of any business contract or status of any legal entity, be it nonprofit, for profit, or simply for OpenACS.

Torben, if you've gotten that idea it's because you've paid no attention to what I've said, and paid all attention to what Peter's said. By simply reading my initial post - including the third paragraph, which you and Peter seem to have missed - you should be able to realize what this thread is (or was) about: kindly offering a template contract for OpenACS projects (defined as such commercial projects that are aimed at altering the toolkit) that may be used by business parties who don't already have a better contract template around and who want to be sure that their contracted terms don't conflict with the community interests.

The point of having a template, model, or typical example of any sort of thing is that it provides a service to people who are going to produce some specific variant of this general type of thing. So a contract template provides a service to people who are going to produce a contract. If the contract template doesn't suit their needs, they can just say thanks but no thanks and produce a contract from scratch or from another template. The template is just an example.

Saying that the mere existence of a contract template providing a service to those who are in the situation of commercially producing code for the OpenACS toolkit will limit the market to such projects is like saying that just because a tool exists we're forced to use it. I've been diplomatic enough to call this idea naive. In fact, we could (hypothetically) produce a contract template stating that commercial use of OpenACS is prohibited or any other kind of madness, and this would not limit our market or freedom in any way. The only effect such a template would have is no effect at all, because nobody would sign a contract based on it.

And even if some parties would find it in their interest to sign a contract like that, this would have no effect on the OpenACS community and the rest of the world who didn't sign the contract. The fact that a contract only determines the behavior of those who independently and willingly agree to it is so fundamental to law that it goes without saying (thought I). So, "comparing a basic contract of an open-source project with a proprietary project" should not have to be necessary to make it clear that "the relationship remains between the two parties".

Naively, I hoped it was possible to produce a contract template that more than one set of company/client find to be a useful example for more than one project of the same sort. Others who were equally interested in corresponding contract templates for other sorts of projects could do the same, I figured. I have given up on this idea. The obstacle in the way of succeeding with such a task is the widespread notion that attempting to pull a stunt like that means you're a dictator and not a community servant and that "template" is Swedish for "Quran".

I'm very happy if we have managed to create guidelines for work on extending the toolkit. This was not the initial goal with this thread, however.

My idea was to facilitate and require that every such project has a project page on openacs.org that at minimum has status updates in a blogger and a list of the people involved and some kind of roadmap/task list. For an illustration of what I had in mind, see the I18N project page:

http://www.collaboraid.biz/extranet/i18n/

I will be posting shortly to summarize ideas that were discussed during the OpenACS governance meeting in Copenhagen. The governance that we choose will influence your guidelines to some extent. We are leaning towards a governance structure similar to that of the Tcl/Tk project uses. That topic deserves its own thread.

Staffan,
I have updated the OpenACS Contribute page with instructions to the same effect that you suggested. My wording is different and I'm not covering everything that you suggested. Please let me know what you think.

Thanks!