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?

Francesco
  • 1,426
  • 14
  • 22
deviDave
  • 2,933
  • 5
  • 26
  • 30
  • Can't you send the libraries "pre compiled" (not sure of the Java terminology for this)? – ChrisF Apr 03 '12 at 09:02
  • @ChrisF 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 03 '12 at 09:17
  • 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 03 '12 at 09:20
  • @ChrisF This does not work in the world of outsourcing :) – deviDave Apr 03 '12 at 09:23
  • 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 03 '12 at 09:29
  • did you consider making and passing to client "stubs" that don't do work but implement interfaces needed for code to compile? If client is indeed concerned _only_ about code being compilable, this should work. – gnat Apr 03 '12 at 09:44
  • 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 03 '12 at 10:05
  • @deviDave you're welcome. Suggestion copied [from comments into an answer](http://programmers.stackexchange.com/a/142759/31260) – gnat Apr 03 '12 at 11:37
  • 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 03 '12 at 11:49
  • 5
    Don't get many repeat customers, eh? – Wonko the Sane Apr 03 '12 at 12:37
  • If you give me code that doesn't even build, you wouldn't get a penny off me. – gnasher729 Apr 22 '23 at 15:03

5 Answers5

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.

ozz
  • 8,322
  • 2
  • 29
  • 62
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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
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.

Bjarke Freund-Hansen
  • 1,176
  • 1
  • 11
  • 18
  • 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 03 '12 at 09: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 03 '12 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 '23 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");
    }
}
gnat
  • 21,442
  • 29
  • 112
  • 288
  • 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 03 '12 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 03 '12 at 17:20
  • @gnat: Of what possible use is code that compiles but doesn't work? – Keith Thompson Apr 03 '12 at 19:14
  • @KeithThompson in my case, main delivery was executable code; source code was supplementary – gnat Apr 04 '12 at 04:47
  • @Ramhound consider expanding familiarity with different kinds of software product packaging - as of now [it looks rather limited](http://programmers.stackexchange.com/questions/142734/do-i-have-to-deliver-my-utility-and-helper-code-to-clients/142759#comment269549_142759) – gnat Apr 04 '12 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.

Danny Varod
  • 1,148
  • 6
  • 14