Hi Dalibor,

thanks, very good comments.


I may have again asked for quite a theoretical problem here. If there is a
disaegreement with a client over what was agreed I consider ourselves
dropping the ball considerably as well, but I want to safeguard myself
against the few people that habitually disagree with suppliers.

I guess, if they don't pay I want to be able to write off the money at
least. That is mentally a bit easier, if they can't use it then!



Thanks again for your comments,

Jochen


On Mon, Jul 27, 2009 at 2:23 PM, Dalibor Andzakovic <
[email protected]> wrote:

>  Hi Jochen,
>
>
>
> The way I read your problem would be that yes you do need to keep the code
> on your staging server unless
>
> 1)      The client has explicitly asked for maintenance and has agreed to
> fund the development.
>
> 2)      You’re deploying the changes as a part of routine maintenance as
> agreed with the client
>
>
>
> What this boils down to is your agreement with your client. Say you’ve been
> contracted to developed a site for a client. You’ve recommended to base said
> site on $CMS_FRAMEWORK which is licensed under OSS license and they’ve
> agreed (and even let you open source the plugins you’ve developed as a part
> of the project). Project delivered on time and under budget (rare I know)
> and client is happy (frequent occurrence if you know what you’re doing).
> Further down the line there is a serious bug found in your $CMS_FRAMEWORK
> and client’s site should be upgraded.
>
> There are couple of options now:
>
> 1)      Explain to the client that there’s been a patch for the
> $SERIOS_ISSUE, explain the risks/reasons for the patch and let the client
> make the decision. If they agree proceed with the work if not let it be.
>
> 2)      Patch the code as part of agreed maintenance (look up MS patch
> Tuesday)
>
> 3)      Patch the code and let the client know that you’ve done some free
> maintenance to score some brownie points (marketing types call this a loss
> leader). *Make sure you don’t disrupt their operation*
>
>
>
> Did I mention that it’s comes down to the agreement with the client?
>
>
>
> IANAL, YMMW etc...
>
>
>
> Dali
>
>
>
> PS if it’s not in writing it’s not agreed
>
>
>
> *From:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Jochen Daum
> *Sent:* Monday, 27 July 2009 10:48 a.m.
> *To:* PHPUG
> *Subject:* [phpug] [OT] legal: retain ownership of code until paid and
> open source licence
>
>
>
> Hi all,
>
>
> I'm looking for experiences with the following problem:
>
> we're  distributing most of our code under open source licences to clients
> and I wonder if anyone has had experiences with the following scenario:
>
> - Project get developed and delivered under open source licence to client
> on clients server
> - Later, a round of maintenance is developed and rolled out to the clients
> staging server.
> - Clients disputes nature of maintenance request and withholds payment
>
> Now, normally we have a clause in our contract that we withhold the licence
> of source code until it is paid. I found a similar clause in Egressive's
> contract here:
> http://www.phpug.org.nz/index.php/Business_Terms_and_Conditions and our
> own contract has pretty much an identical clause:
>
> "3.1 The Supplier, subject to payment in full of all owing, grants the
> Purchaser a non-exclusive licence in respect of all pre-existing material of
> the Supplier, which comprises the Agreement Type upon completion of The
> Project , ..."
>
> But after completion of the maintenance we would have distributed open
> source code already?
>
> Do I need to keep code on my own staging server at all times to get around
> this?
>
> Kind Regards,
>
> Jochen Daum
>
> Chief Automation Officer
> Automatem Ltd
>
> Phone: 09 630 3425
> Mobile: 021 567 853
> Email: [email protected]
> Skype: jochendaum
> Website: www.automatem.co.nz
> http://twitter.com/automatem
> http://www.xing.com/go/invite/3425509.181107
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
-~----------~----~----~----~------~----~------~--~---

Reply via email to