You probably know the list of open source licenses officially approved by the OS

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.

Explanation / Answer

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).

Related Questions

Navigate

• Browse (All)
• Browse Y
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.