Does it matter to you that a software is "available source" but not "open source"

Question

You probably know the list of open source licenses officially approved by the OSI. Most notably I guess would be the GPL, MIT, [insert your favorite license here].

I recently ran into a project which although was open source (the creator made all source code available), was not officially open source under one of those official licenses.

• It released the source, but made no promise to release the source in the future.

• It allowed modification suggestions, but made no promises to accept patches and disallowed external distribution of externally-patched versions.

• It allowed the use of the software in commercial or paid projects, but disallowed the sale of the software itself.

I suppose it could be called "available source" not open source as we like to think of it.

I can see why the management team of a company wouldn't want to do business with this software. They can't fork it, they can't sell it, they can't create their own version of the software and distribute it or sell it.

But would it matter to you as part of a software engineering team who's just using this software? I can still get my work done with it, I can use it in a project for which I'm paid (but I can't sell the software itself, which I'm not in the business of doing anyway), and I can make changes to the code to make it behave differently for my needs (but I can't make those modifications public), and if I do want those modifications officially made available to others, the approval is up to the project itself and they choose whether to incorporate them in an official release or not.

So we know that a company that wants to base its business on this "available source" software can't do that, but as someone from the software engineering team, would those differences matter to you or do they seem less relevant?

Curious what others think of this.

Answer 1

For projects which would have had to develop from scratch the functionality provided by this software, it's a definite convenience not to do so.

But whether a comparable open source package would be better depends on other factors:

• will it be used to provide some service or bundle it as a part of another product?
• do they have the resources to enhance and maintain the product independently?
• is there a competitive advantage to use this software over the open source version (either in the code or the project management)?

Answering no to any of these factors indicates the OSS is a better choice.

Most of the time, the code itself isn't the determining factor. One needs to examine the bigger picture.

SIDEBAR OSS projects can't legally promise they'll keep future versions open, or that there will be future versions. That's one reason why having an open license is so advantageous. Also, OSS projects aren't required to accept patches from contributors (particularly without a transfer of ownership or rights).

Answer 2

The question for this and any other external library is maintenance.

What is the lifespan of your application and what is the apparent lifespan of this library? Yours should hopefully be the shortest.

Who will do bug fixes for this library? As it looks from here, your company should explicitly allocate resources in the future for maintaining this software, as you cannot rely on any other fixing bugs for you. You cannot share the maintenance burden with anybody else since you cannot share the source. Want to hunt down an elusive race condition bug in code you don't know?

This thought alone might make the library too expensive to use.

This might be irrelevant if the library is very solid and robust and easy to work with on the source level, but my experience is that the peer pressure of true open source projects simply make the code better because you tend to do your best then.

Personally I would think very careful about if I would adopt this or any other external code, since the whole reason for using other peoples code is that you don't have to deal with it yourself. Also think of future maintainers - you should do fire drills changing code in the library to see if it can be done at all. There might be some VERY nasty surprises here.

Are you at liberty to discuss the library in question?

Answer 3

To be honest, I don't see why the management team of a company would have problems with using such an "available source" library. As far as integration into their own product is concerned, they can just regard it as a closed-source library.

For me, as a programmer, it does not matter if a library is "open source" or "available source". I prefer not to make local modifications to an external library, because that means an additional maintenance burden. Not only when bugs are found in my local modifications, but also on integrating the modifications again and again when a new release of the library comes out.

The only situations where, IMHO, "open source" beats the "available source" licence outlined in the question is when

• the licence of our product also requires disclosure of the sources of contained libraries
• we are in the business of producing an enhanced/extended version of the library

Answer 4

This is why the Free Software Foundation uses the terms 'free' or 'non-free' to describe software. They are not referring to price, but restrictions that are placed on use or distribution of the software.

It looks like you have hit one of the rare corner cases where you have full access to the source code of something, but the software is not "Open Source" by the OSI definition.

Either term has the capacity to become a misnomer. I paid $50 for my first copy of emacs (on QIC tape), but emacs is free software. I have the source code to some proprietary applications that my company uses internally, but they are not open source.

The thing that raises the biggest red flag (at least to me) is no guarantee to access to the source code of future versions. If you heavily depend on being able to modify this tool, I'd be careful. Even if you have verbal agreement with the vendor that you'll always have code, unless it's in contract form .. that agreement never happened.

As CTO, I try my best to ensure that we do not depend on non-free software. I've been on the bad end of vendor lock in several times in the past, a mistake that I like to avoid. While we do use some proprietary stuff, our business would not suffer undue hardship if all of a sudden we could not use it any longer.

It sounds to me like you are building stuff around having this software and access to the code, so I'd recommend getting something in writing that says you'll always have access. What happens if the vendor is purchased?

Answer 5

This does matter quite a bit. Main issues with the "available source" approach that you have described:

• You aren't in control of your technological destiny if you don't have the freedom to modify the source. Often hacking the source directly can be preferable to a messy workaround.
• You have no guarantee that the software will continue to be maintained, and you don't have the fall-back option of doing it yourself that you get with true open source.
• Since it sounds like a custom license, you probably have greater legal risk compared to using something well-known and proven like the GPL or BSD licenses.
• If it isn't real open source, you won't get the same level of helpful community around it which is a major advantage for many open source projects

My suggestion: try to persuade the creator to release the software under an open source license. That should be a win/win for everyone - you because you get the software you want under open source licensing, the creator because making the project open source is likely to make the software much more successful in the long run.