Re: [rails-business] Digest for rails-business@googlegroups.com - 5 Messages in 1 Topic

[Dan Pickett]

I highly recommend checking out Obie's perspective on this - I actually added a clause about Type A and Type B deliverables and it's worked out quite well. Clients ask for a bit of clarification from time to time, but the policy has worked well.

some good notes from his talk - http://casperfabricius.com/site/wp-content/uploads/2009/05/talk-obie.txt

There's a video somewhere but I can't seem to find it quickly.

On Fri, Apr 2, 2010 at 5:44 AM, <rails-busin...@googlegroups.com> wrote:

  Today's Topic Summary

Group: http://groups.google.com/group/rails-business/topics

• Licensing of copyright and reusable code [5 Updates]

 Topic: Licensing of copyright and reusable code

Evan Dorn <ev...@lrdesign.com> Mar 31 06:58PM -0700 ^

 
How do you, in your business, handle the licensing and copyright of
work you develop on contract for a client?
 
The presumption of most contracts is that your work is work-for-hire,
and the client owns the entire product and the copyright over it.
Certainly most clients would not be happy if you tried to keep
copyright over the work you did for them.
 
At the same time, developers reuse code. It doesn't make sense to
write the 23rd shopping cart you implement from scratch, and if you
did, you'd have to charge a lot more from your services. Moreover,
it's simply not possible for a client to own the entire product: Rails
itself is a critical part of the product, and you don't own it so you
can't transfer ownership to the client. Most Rails products use a
dozen or more plugins and gems, each of which contains its own license
and copyright.
 
How do your contracts approach this morass of ownership questions?


 

Philip Hallstrom <phi...@pjkh.com> Apr 01 01:09PM -0700 ^

 
> dozen or more plugins and gems, each of which contains its own license
> and copyright.
 
> How do your contracts approach this morass of ownership questions?
 
I've probably been fairly lucky in this as my clients have all been
quite reasonable. I make the same points that by leveraging open
source they are getting a huge amount of code for free. I go onto say
that it's "nice" to be able to contribute back to those projects so
that others can benefit.
 
I make a point of saying that I won't contribute anything that is
specific to their business (ie. the netflix rating algorithm), but
that if there is something that isn't a business secret, gives no
benefit to their competitors, that may be contributed back.
 
So far, clients have liked this approach.
 
-philip


 

Josh Goebel <drea...@gmail.com> Apr 01 04:12PM -0400 ^

 
Ditto. Work with reasonable clients and they don't really care so
much about such things as long as you're only contributing
"utility-ish" code rather than business secret code.
 
Thanks,
Josh
 
 
--
Josh Goebel
 
............
Pastie
http://pastie.org
http://blog.pastie.org


 

Philip Hallstrom <phi...@pjkh.com> Apr 01 01:19PM -0700 ^

 
One more thing (puts on black turtle neck)....
 
Educate your clients as you go. When they request a "we want to be
able have comments" and you do it by using one of the many "acts as
commentable" plugins out there, make a point of mentioning that using
that saved them a ton of time. When they then want to rate those
comments and you use one of the rating plugins, mention that.
 
Sure it doesn't help up front, but in the long run it helps a lot.
 
On Apr 1, 2010, at 1:12 PM, Josh Goebel wrote:
 


 

Eric Davis <eda...@littlestreamsoftware.com> Apr 01 05:30PM -0700 ^

 
Josh Goebel wrote:
 
> Ditto. Work with reasonable clients and they don't really care so
> much about such things as long as you're only contributing
> "utility-ish" code rather than business secret code.
 
Same here, most clients don't care about the utilities. Though it helps
that most of the code I work on already falls under the GPL2.
 
I have used the "we can either build this from scratch and take 100
hours or modify this OSS version in 5 hours" line before. Usually the
"proprietary" part of their application shrinks once they start
comparing the cost/benefit.
 
In the very extreme case, I've built an OSS version of what they wanted
and then kept their business-specific implementation private (e.g.
monkey patch at runtime).
 
--
Eric Davis
Little Stream Software
Redmine Custom Development and Support Services
http://www.LittleStreamSoftware.com


 

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails meets the business world" group.
To post to this group, send email to rails-b...@googlegroups.com.
To unsubscribe from this group, send email to rails-busines...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-business?hl=en.

--
=========================
Dan Pickett
Principal
Enlight Solutions, Inc
http://EnlightSolutions.com

http://www.twitter.com/dpickett

[Eric Davis]

Dan Pickett wrote:

> I highly recommend checking out Obie's perspective on this - I
> actually added a clause about Type A and Type B deliverables and it's
> worked out quite well. Clients ask for a bit of clarification from
> time to time, but the policy has worked well.

My MSA uses these terms:

* Client materials - things the client owns that I need to use (e.g.
graphics, existing codebase)
* Work product - what I'm delivering to the client.
* General purpose libraries
* Third party materials

Each of these can have it's own licensing and copyright assignment in
the Statement of Work (e.g. Client owns Client materials and Work
product, Little Stream Software owns General purpose libraries and
releases under MIT). So far it's been pretty flexible once the Client
and I agree on what part of the project falls where.