[consulting] Contract protection clause

[Carl Wiedemann]

Jeff's suggestion is probably the easiest way down this path. In general,
your work is a work for hire, and the deliverables are owned by the client.

There are, however, some circumstances of being involved in Open Source you
may wish to consider. It's unlikely Drupal would be of the quality it is
today without the support of companies sponsoring development of contributed
modules on drupal.org, and thus transferring the ownership of these modules.
Your client is leveraging Drupal, and thus "standing on the shoulders of
giants," so to speak. If the client demands that *all* code remain under
their explicit ownership, the long-term upkeep and richness of the code is
starved of the benefits of being released to the Drupal community for new
feature ideas, contributions, bug fixes, etc.

Suppose some of the code you were developing was available on drupal.org;
would your client be interested in using it? Likely so. What if the module
had a bug or could use a new feature? Would you patch the module, fostering
collaboration and new ideas and enthusiasm from others? Perhaps.

So, you might address the entire issue by considering what deliverables are
best served by being property of the client (design, graphics, branding,
custom APIs), and which are best served by being property of you, the
developer (possible contrib). Something to consider.

In the end, you may find no headway with this, and will have to abide the
client's demands. Then again, the whole point may be moot since not every
scrap of Drupal code is appropriate or useful for release. But having some
leverage at the forefront will give you some flexibility throughout the
relationship.


On Wed, Mar 23, 2011 at 9:55 AM, <jeff at ayendesigns.com> wrote:

>  I have three clauses in my standard contract that address this. One is to
> define the licensing of elements (graphics, code, etc.).  The second, below,
> intellectual property...you would add to that list. The third is about
> confidential information and the protection of it.
>
>
>  Each party shall retain ownership of the Intellectual Property that they
> possess upon the signing of this contract. In the case of PROVIDER, this
> includes, but is not limited to, functions, methods, libraries, techniques,
> standards and general know-how with regards to software development, subject
> matter, and web site development.
>
>
>
>  On 03/23/2011 11:51 AM, Joe Murray wrote:
>
> You might try a non-competiton clause, where the focus is not on working
> with named competitors. You have to watch for GPL violations in the terms of
> your contract. It is theoretically possible to avoid GPL violations by doing
> code that only writes to APIs rather than modifies other code that is
> integral to the project, or by using data (ie configurations in the
> database). Of course, this is not legal advice, and you should consult a
> lawyer.
>
> Joe Murray, PhD
> President, JMA Consulting
> joe.murray at jmaconsulting.biz
> skype JosephPMurray twitter JoeMurray
> 416.466.1281
>
> Message: 4
>
>> Date: Wed, 23 Mar 2011 08:44:23 -0700
>> From: Bob Morse <bob at morsemedia.net>
>> Subject: [consulting] Contract protection clause
>> To: consulting at drupal.org
>> Message-ID: <33DA2428-972C-4A75-AE33-97BACA672CB9 at morsemedia.net>
>> Content-Type: text/plain; charset=us-ascii
>>
>> We have a client who is concerned with protecting his new Drupal website
>> we will be developing. He is asking for a clause in the contract that
>> somehow states we will not turn around and sell his site with a new design
>> slapped on top to a competitor. I'm not sure how to separate out, ahead of
>> time, what would be very common elements and what would be unique based on
>> the internal processes of a competing business.
>>
>> How might I write something that assures the client we won't resell the
>> unique aspects of his web application without also writing something that
>> prevents us from making a website for another company that uses many of the
>> same elements but with the details being unique to that company's internal
>> process and interactions with clients?
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>> End of consulting Digest, Vol 62, Issue 16
>> ******************************************
>>
>
>
> _______________________________________________
> consulting mailing listconsulting at drupal.orghttp://lists.drupal.org/mailman/listinfo/consulting
>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20110323/61e003b6/attachment-0001.html