6

For various reasons I need to supply "proof" my company's lawyer that I implemented a feature by a certain date. I have used source control since the late 90s and even the oldest databases are still working. I also have the all the old setups. Our release notes are not always as clear as they could be and most of them are not dated but organized by revision number.

I figure rather than guessing I as other software developer if they know what is typically provided in this situation given what I have. I am particularly confused when a feature is spread among several source files. One feature we need to document is not just dependent on an algorithm but the UI as well and there a half-dozen files that were modified to this.

Update By Completed, the feature was tested and released to the customer and it worked. And listed in the release notes. Also I already handed the lawyer the release dates, and the release notes (when they existed). However that was not sufficient. I need to show how I got dates. I got them out of my source control databases (Sourceforge, Subversion, Mercurical) so how to I put data that in my source control in a form that a non-technical layman can understand.

Note: If you wondering why we have multiple database it is because the software in question been in continuous development since the late eighties.

Improve this question
8
  • 3
    Please don't post exactly the same question on multiple sites.
    – ChrisF ♦
    Aug 10, 2011 at 12:49
  • 1
    Are you working against or with your lawyer? E.g. do you have to help the lawyer against a client (to get the client to pay), or do you have to get your company to pay you? Or both?
    – Paŭlo Ebermann
    Aug 10, 2011 at 12:53
  • 3
    @ChrisF I I over to here after it been suggested that I do so. And I was not aware that Stack Exchange can do this as part of a close option
    – RS Conley
    Aug 10, 2011 at 13:46
  • 2
    @RS Conley - It may be easier to debunk their claims. Check any logs that show that the feature was used and the data collected by it.
    – SoylentGray
    Aug 10, 2011 at 15:50
  • 5
    I'm voting to close this question as off-topic because it asks for very specific legal advice that we cannot provide. Please read What types of legal questions are on-topic here? and When is a software licensing question on topic?
    – durron597
    Jul 2, 2015 at 18:48

10 Answers 10

Reset to default
12

It's a legal question so you need to define your terms clearly, otherwise the answer is, as with every legal question, "it depends".

The first thing you need to define is what "feature" he's talking about. I'm guessing that whatever it is has evolved over time so you need to agree what the minimum functionality that comprises the "feature" in question is. It may well be that the feature (or at least the bits the lawyer cares about) were complete far sooner (or later) than you think. I suspect you'll need to talk him through it's life cycle and changes that were made until he can establish the feature set that is relevant.

Second, what do you mean by "complete"? Off the top of my head I can think of three definitions:

a) Code complete - that is the developer has coded it all in a roughly working form, carried out some basic testing and checked it into source control. This works well as a definition as source control gives you not just a date but the ability to produce an exact copy of what existed at this point in time.

b) Tested - the point at which someone else has verified that it works. I think this is probably the least likely as testing is usually just an internal process and I doubt would have much significance legally.

c) Released - the point at which it was made available to users. Potentially significant as it may be the point at which others might have been able to find out about it and copy it.

I'm guessing that the lawyer will go with (a) because it will be the earliest of the three and that's probably what he's looking for.

If that's the case you're looking for the earliest version in source control where all the functionality agreed as significant was available and working - that would be algorythms, UI, the lot.

While this may not comprise strict "proof", as this is a civil case it's likely to be sufficient unless there is a good reason to doubt it. In a civil case the burden isn't "reasonable doubt" as in a criminal case, it's far lower. That means if you produce reasonable evidence as to something, they'd have to produce something to bring it into question or it will likely be accepted.

If it's (b) or (c) the measurement is obvious but probably harder to establish as it will rely on documentation and e-mails which won't be as well ordered as source control but it's probably provable with enough leg work.

Ideally of course you produce evidence of all three - each one strengthening the previous one. After all, your release date is far more credible if you can show a test sign-off shortly before that and code complete before that.

But first things - speak to him and get a strict definition of terms.

Improve this answer
3
  • 1
    +1 for precision. Also, I am unsure as to the validity of a vcs log for proof. It may be sufficient internally, but if a lawyer is involved, it seems to me you'll need external witnesses.
    – Matthieu M.
    Aug 10, 2011 at 16:32
  • 1
    Well stated. Well-defined criteria are everything when dealing with strict logic in the legal world.
    – Roy Tinker
    Aug 10, 2011 at 17:05
  • @Matthieu - Amended to cover this. It's almost certainly a civil case where case the standard of "proof" is lower. If you can produce a source control archive showing these dates, it would likely fall on the other party to produce contrary evidence (either that the archive was inaccurate or something to contradict it), rather than you having to prove you were right to the standard required in a criminal case.
    – Jon Hopkins
    Aug 10, 2011 at 20:24
7

Since you're using source control, why not check out a version of the code from on or before the deadline date, build and run it, and demonstrate that the feature works?

Improve this answer
3
  • Yes, I could, but did you do that in response to a lawyer's request for documentation?
    – RS Conley
    Aug 10, 2011 at 13:48
  • 1
    @RS Documentation in this situation could be screenshots of the app showing the feature, taken for example with camtasia to show the version in the app's about form and then demos the feature. Documentation isn't necessarily always paperwork...
    – Marjan Venema
    Aug 10, 2011 at 17:27
  • Depends on whether the lawyer is willing to accept it as proof, which isn't something we can answer for you. Ask the lawyer. :-)
    – Wyzard
    Aug 11, 2011 at 1:35
5

Do you have any email that indicates that the client or end users had, at some point, successfully used that feature?

If not, maybe if you have a QA process, there might be a QA engineer who would have made notes at some time and "checked off" a feature as implemented, that could sign an affidavit.

Improve this answer
3
  • Yes we have documentations that people used the feature after the date. The problem is other than my say so and showing the release notes. How I can take my source control data and hand it to the lawyer in a form that makes sense to a non-technical layman?
    – RS Conley
    Aug 10, 2011 at 13:52
  • 3
    @RS Conley: You can't. It's called "code" for a reason. It doesn't make much sense to laypeople. What you could try, though, is an expert witness: getting someone with a similar skillset as you to examine the code and testify that it's correct.
    – Mason Wheeler
    Aug 10, 2011 at 13:57
  • 1
    If you had documentation where a human, technical or otherwise says in writing something like "I used this feature, and it works like I expected...", or "I tested this feature, and here is some feedback..." seems to me that that it would constitute as 'proof' to a non technical lawyer.
    – aceinthehole
    Aug 10, 2011 at 14:08
2

If this is part of compliance, someone makes a request/becomes the owner of a feature and then they sign-off for approval. There is documentation and the associated code, but it is tough to provide proof of a feature with code only. This may work if you're being audited by another programmer.

Going back, look at your code and any written correspondence you can find to indicate owner approval. An email trail may be a bigger benefit.

Improve this answer
2

This question isnt particularly clear. But if you want 'proof' that a feature worked, you probably need the customer to sign off that said feature was delivered and functioned correctly. Otherwise the functionality cant really be said to have been delivered and that it worked.

Improve this answer
2

You work off a contract that states that the feature is completed when the client signs off on the acceptance tests for the feature. When the client signs off, it constitutes legal acceptance that the feature is completed.

If there is a problem with time frames, or the client is dragging his feet on signing off the features, there should be something in the contract that specifically allows you to sign off the feature yourself by demonstrating that the feature works in accordance with the stated feature requirements.

It goes without saying that the requirements need to be clear and unambiguous.

Improve this answer
1

Given that you've used source control. I would expect that the simplest solution would be to find the checkin(s) that implemented the feature.

These should be dated and should be proof enough. However, I'm not a lawyer so I don't know whether computer logs count as sufficient proof.

If you have any other documentation - requirements specifications etc. these should be dated and will help.

Improve this answer
1

If your software is somehow made public (like provided to other company, released in a site, etc) you could give that information, that the feature was public available in that release, which was made public in a site / was delivered to some customer in some date.

Improve this answer
1

We are in a similar situation as a contractor. To satisfy the client's request we produce a document that details the implementation of the project or enhancement. This is usually a collection of screen shots. This is bundled up with source code diffs for the specific change. The client is billed based upon a review of the package.

The client requires paper. Emails and source code itself is not acceptable. We have a big room filled with the documentation in case we get audited for the work we have done. Sounds like government work? You bet it does!

Improve this answer
0

I'd say that a feature was implemented on the date the final (prior to bug fixes) was released. If the algorithm was built on 3/3/2001, but the UI wasn't finished until 10/26/2001; the the feature would be implemented on 10/26/2001. That date is the implementation date regardless of bug fixes that happened afterwards.

The bottom line: The implementation date isn't the date the code was checked in, it is the date when code was frozen for release.

I hope I didn't misunderstand your question, and I hope this helps.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.