7

Over the years I've created a bunch of Java utility and helper libraries which I just attach to new projects. Then, when I deliver code to my clients, I send all the code except for the libraries themselves (not JARs but source code files).

A client complained that he could not compile the project as some libraries were missing. I tried explaining him about my own libraries, but he was not satisfied.

How do you handle such situations? I am still apporting changes to these libraries often and I cannot compile JARs each time I start working on some new project. How to overcome this issue - not to share private libraries (personal intellectual property) and have happy clients?

Improve this question
11
  • 1
    You need to secure these in some way. Using a licensing agreement is the simplest non code way, as even if you use some mechanism in code it can be circumvented. If they passed on your code without your permission then this is a breach of contract. Lawyers are expensive, but simply telling them that they shouldn't do that will help.
    – ChrisF ♦
    Apr 3, 2012 at 9:20
  • 2
    @deviDave: Did you get paid for the months you were working on those libraries? If you did then I don't see that you have much to complain about if the customer finds another use for them.
    – pdr
    Apr 3, 2012 at 9:29
  • 1
    @pdr I haven't been paid for them :) as they are always made after the project is over. They represent actions that I often repeat and which I put into libraries.
    – deviDave
    Apr 3, 2012 at 10:05
  • 6
    Did you tell your clients up front that you will give them the source code but it won't compile? In their mind they paid you for a complete solution.
    – JeffO
    Apr 3, 2012 at 11:49
  • 5
    Don't get many repeat customers, eh?
    – Wonko the Sane
    Apr 3, 2012 at 12:37

5 Answers 5

Reset to default
17

First, this is mainly about the contract you have with the client. If you have a contract which includes delivering of the source code, your client can expect source code they can compile by himself. If you refuse to do this, you break the contract - and it does not matter if the missing source in lib A or lib B or lib "Utility". From the client's point of view, there is no difference between those parts.

If you have specificially excluded some libs in your contract (and your client inattentively signed that), then you may rightfully refuse to deliver your source for that libs, but don't expect to keep the client in the future.

If you want to avoid that situation in the future, separate your utility library clearly in your contract and try to sell / license it to your customers as a closed-source-product, together with the sources of the main product your are creating for them. That will imply proper versioning and configuration management of your utitlity lib, of course.

Improve this answer
23

If the contract expects source code to be delivered, then the source code you give them should compile.

Not giving them the libraries to do this is ridiculous.

If the code in your libraries is generic helper type code, then there is nothing wrong with giving them the binaries and some license agreement with them.

If the libraries contain something specific to how the system is built then the customer will be within their right to expect to receive that code as well. They may need to modify it at some point for example.

Improve this answer
0
3

You probably have to version your proprietary library and make (your own internal) releases. Then when you start a new project, you just use your latest released library in that project, and upgrade to a new version whenever needed.

Then you can send the source to your client, including the jar of your library in the version that you have tested the project with.

Improve this answer
3
  • Then I cannot protect anyone from using them, right? I started making personal libraries after my client shared my logic with another team. They are now using my parsers which I developed for months.
    – deviDave
    Apr 3, 2012 at 9:17
  • You can protect your source-code by distributing only jars (perhaps even obfuscated ones.) Protecting the usage of the jars you distribute is done via licenses, you own the library and you set the terms on which your client can use the library. At this point you probably needs to involve a lawyer though.
    – Bjarke Freund-Hansen
    Apr 3, 2012 at 11:07
  • @deviDave Either you give these library away for free (except for the copyright), which doesn't cost you anything but lets you offer much better value than your competitors do. Or you don't, and you'll never get repeat customers and destroy your reputation.
    – gnasher729
    Apr 22, 2023 at 16:46
2

If client is indeed concerned only about code being compilable, consider making and passing them "stubs" that don't do work but implement interfaces needed for code to compile:

public class MyClass {
    public void myMethod() {
        throw unsupported();
    }
    private UnsupportedOperationException unsupported() {
        return new UnsupportedOperationException(
                "stub code intended to use only in compilation");
    }
}
Improve this answer
5
  • 2
    This answer makes no sense. They want to make changes to the program THEY purchased, otherwise why are they trying to compile it, they already have a version that is compiled. Worst answer EVER!
    – Ramhound
    Apr 3, 2012 at 16:22
  • @Ramhound well I for one can easily imagine client willing to do just basic compile check for the code they've got - this has been the case in one of my past projects.
    – gnat
    Apr 3, 2012 at 17:20
  • @gnat: Of what possible use is code that compiles but doesn't work?
    – Keith Thompson
    Apr 3, 2012 at 19:14
  • @KeithThompson in my case, main delivery was executable code; source code was supplementary
    – gnat
    Apr 4, 2012 at 4:47
  • @Ramhound consider expanding familiarity with different kinds of software product packaging - as of now it looks rather limited
    – gnat
    Apr 4, 2012 at 16:50
1

To add to what bjarkef wrote, you should have an automated build process, so that your libraries are built automatically.

You should label the stable releases of your libraries source code and binaries (jars).

When you distribute a product based on your libraries or on 3rd party libraries you should include the binaries (jars) of all the libraries you tested it against within your release.

There are certain open source projects that do not distribute their 3rd party dependencies along with their distribution, however, this is a very bad practice.

Your client is correct to insist on receiving products that are complete and not to start looking for the correct version of all your dependencies.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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