[brudgers]

[IANAL]

I come from a field, AEC, which in the US uses a lot of standard contracts. The AIA contracts, though not the only option, are very common and have been developed over the course of 100 years.

The architecture series start with B. These are, in my opinion, a good model for a software consulting project because:

+ Neither party really knows the full scope of the work when the contract is let. As my mentor Ronn Ginn told me, two people sit down and sign onto something about which neither has much of a clue. This of course emphasizes that an agreement is really a matter of trust not which court to go to.

+ Client objectives change during the process. The contract reflects it.

+ Intellectual property rights are clear. The architect retains the copyright. The client is granted license to use it for the purpose of the project. The license is predicated on payment.

+ Terminating the contract for convenience is a distinct possibility. The contract acknowledges that.

+ One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.

+ Both parties are likely to contract with others during the course of the project [architect with consultants, owner with builders]. The contract acknowledges that and one of the reasons for using standard contracts is because they all fit together. But that's too much to hope for here. The idea of acknowledging the possibility of other contracts and taking them into account is what matters.

The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects.

Having written a lot of proposals and contracts over the years, I've learned that selecting clients matters more than what's in the contract. Red flags really are red flags.

Good luck.

[Radim]

I don't know what these acronyms mean, but I'd hate NOT being assigned full intellectual property rights, as a client hiring a freelancer.

Is that really common in your field? What's your field's price tag between doing full IP assignment vs. a license-only?

[brudgers]

   AEC = Architecture, Engineering, Construction
   AIA = American Institute of Architects

Architectural services are...well services, not products. It's not as if there is a copyright on a phone conversation or a drive to the project site, and it is not as if those things are incorporated into any artifact, e.g. a sketch for a new shed.

Assigning copyright in the US AEC industry carries additional complexity since architects and many of their consultants are licensed professionals and therefore are professionally liable for their designs. Part of the responsibility that comes with licensure is maintaining professional control of the design. By assigning copyright the architect and their consultants might maintain liability for its execution in contexts of which they are unaware, e.g. where soil conditions or sesmic loads differ from those on the site for which the building was designed. Legally architects cannot reassign their professional responsibility...that's what makes it professional.

An analogy in software might be Software as Service in particular and licensing in general. The Software industry already has retention of copyright as the common mode of agreement.

Going further, full assignment of copyright to the client just turns the problem around. If I assign the copyright to the design to a client, I need to obtain a license back in order to use similar parts and pieces in other projects, e.g. a detail for a door jamb or the profile and reinforcing of a footing or more directly the "drawings" that show them. Likewise a software engineer needs to be able to reuse foreach foo in bar without consulting a lawyer.

While there are exceptions, it's simply easier to negotiate a useful set of licenses without transfer of copyright than to include that in the negotiation. Functionally, if the client can do anything with the work except reassign copyright the vast majority of cases are well served.

The price of full assignment? The question correlates to a Kremlin on May Day with Brezhnev in the reviewing stand parade of red flags. Screening clients is critical.

[reboog711]

AEC usually means Architecture, Engineering, Construction.

I usually take it to mean the process of building buildings and making sure they won't fall down, but that may be oversimplified from someone who actually works in that industry.

[sethrin]

Work for hire does not generally apply to freelancers. Please see here for details: http://www.copylaw.com/new_articles/wfh.html

[k__]

If you create basic CRUD apps it is probably not so common.

But for anything more advanced it would be wise to have the option of using the software in other projects to save time and money.

[brudgers]

The option for reuse applies to both parties. Someone has to license use from the copyright holder with or without a transfer. In the case of software, the transfer is just an additional complication, by which I mean that the copyright to a Rails app is complicated by the license stack of Rails and the backend and other pieces. There's lots of pieces that the programmer doesn't hold copyright and therefore cannot assign it.

[Radim]

Indeed, but that sentence applies equally to either side of the contract!

Which is why I wonder what the "accepted standard" & "cost of giving up IP" is. I assume it varies greatly across domains -- OP's is "web development".

[pbnjay]

> + One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.

I love this one. Anyone have ideas on how to apply this to software development? I really hate it when clients say "I want X" and I have to take an inordinate amount of time telling them why X is a very bad idea both in terms of effort and value. Generally this is during scoping so I have no way of billing for the time.

[pekk]

The consensus seems to be "telling them why something is a bad idea at length is part of the job" and "doing it the stupid way at additional cost, because they insisted, is part of the job."

But I think we can go too far emphasizing pleasing the client sometimes. I don't think it's so rare to see genuine conflicts of interest, like squeezing for unreasonable deadlines and scopes, where the problem can't really be solved by just charging more.

If a client makes overly aggressive demands and won't listen when you take the time to tell them politely what you can do, is it better to be exploited mercilessly and risk breach of contract, or to cut your losses, swallow your pride and find another way to pay the rent?

[brudgers]

The best way to convince a client they are making a mistake is to do it the way they asked and do it the way you think is better and then show them both. Sometimes the client sees their error. Other times it turns out that the client has an unarticulated need that gets teased out and the final design incorporates both the ideas of the designer and the unarticulated need.

It's important to realize, that often the client is more experienced with their requirements, i.e. the business domain. And their understanding may be sophisticated in ways that are contrary to the naive take of an outsider.

[brudgers]

Be professional. Part of that means knowing how to produce reasonable estimates. That requires having a plausible roadmap at the start.

In some ways, software will always be harder because the artifact in a construction project is the building not "the blueprints". If the design is dragged out, the building doesn't get built.

On the other hand, the way an architect handles "I want X" is by showing them that it is a bad idea. Showing means providing a design that incorporates "X" and one without. The assumption that everything will be done multiple times before it is right, and indeed that doing it multiple times makes it better, is what separates architecture from engineering in AEC.

Understanding that doing things multiple times is just part of the job and that falling in love with one's own ideas is a bad habit can be learned. It ain't easy. But in the end, the architect walks away and the client lives in the building. Software is similar in that way.

[danbmil99]

what you call "scoping", beyond high-level goals (< 1 hr to explain) you should refer to as "development of detailed requirements and specifications", and should be charged for by the hour just like coding.

Your ability to tease out what really needs to be done from a customer's hand-waving wishlist of vague features is a key component of what you are being hired for. That skill is worth more in general than straight coding, and should be compensated accordingly.