Preventing commercial exploitation of small changes that require a lot of work

Question

At my previous job I was responsible for building and maintaining a library in their ecosystem. The project is mature in the sense that no major new features are being implemented. It is still maintained, which means that bugs are fixed and every now and then minor enhancements are made. To give a sense of the maturity: the project has some 30k sloc, and currently about 100 lines are changed per month. These small changes do require relatively much work (a couple of hours a week, even when you have written almost the entire code base).

The company has no expertise to maintain this project, and I see they are now introducing new bugs and failing to fix existing bugs. Because I use this library in other projects I expect to have to continue to maintain it at least in the near future. I don't want my previous employer to benefit commercially from this work, for two reasons: (1) to not provide free labour on principle; (2) to motivate them to train somebody to eventually maintain the library themselves.

The project is licensed under a 2-clause BSD license. My old employer has several projects under such a license, and earns money from (subscriptions to) some closed-source projects. These projects are only available to a few clients, who receive the source code. You can imagine something like the Blackboard educational software business scheme, but on a smaller scale, and clients are responsible for their own instances.

My idea is to fork the project and provide it under a GPL 3.0 license. I understand that all code written before the fork will then also still be available under the original BSD license, but code committed after the fork should only be available under GPL 3.0. The idea is that if the company would want to use my fork, they are making a derivative that also would have to be licensed under GPL 3.0 (at least under the FSF's understanding of derivative works). They will not want to open source their application, so they cannot use my fork. My concerns with this are:

• If I make my changes of 100 lines a month under GPL 3.0, the company may look at that, and implement the same patches with some minor changes (e.g. replace a for with a while) under their 2-clause BSD license. This is the easy way out, because the major job is to figure out what needs to be changed, not how to write it down. Am I in any way protected from this happening? Do I have some kind of intellectual property on the change that extends beyond the exact implementation to the ideas behind it?

• The company distributes their software only to selected clients (and I am not one of them). Would they in that situation still be required to open source their application to the general public? And how would one go about proving that they use my fork / requesting their source?

Are these concerns valid? Are there better ways to solve this problem?

Answer 1

implement the same patches with some minor changes (e.g. replace a for with a while) under their 2-clause BSD license

While copyright is based on the implementation of an idea, it is broader than the exact implementation of an idea. Anything which "starts" from your code is a derivative work of your implementation and would therefore be covered by your copyright and hence the GPL - the technical term here is "derivative work". While there is no exact threshold for a derivative work (and it will vary by jurisdiction), taking someone else's code and just making trivial changes to it is clearly a derivative work.

Would they in that situation still be required to open source their application to the general public?

No. Any GPL obligations to supply the source code to a work apply only to entities who have legally obtained a copy of the binaries. You do not have a copy of the binary so have no right to the source.

Answer 2

The company distributes their software only to selected clients (and I am not one of them). Would they in that situation still be required to open source their application to the general public?

No, and this seems to be one of the most commonly misunderstood things about the GPL. The GPL only requires that source be available to users of the binary.

And you're not providing "free labor." You contribute to open source projects because it benefits you; in this case pretty directly because you're using the library in your own project. Whether it benefits others is incidental and irrelevant. If it's easier to fork it than keep up with the new bugs they're introducing, then by all means fork it. Let them do the work of merging your changes if they want to. But don't try to deny them the use of it out of spite. Remember, you're only able to use it at all because they put it under an open source license. They're placing no demands on how you use or maintain your version, and you can't expect to place any demands on how they maintain theirs.

Answer 3

Given your preference to restrict certain purposes, the GPL family of licenses will not help you achieve your aims. Comparing the GPL with other FOSS licenses is not more worrying than using other FOSS licenses, but then no FOSS license can help you with your goals. Compared to other licensing regimes, like the ones on the list I have curated, your choices will be in more alignment with your preferences and goals.

To reduce anxieties about being exploited, you will need to fix your work to a license that (at a minimum) explicitly disallows the purposes that concern you most - eg. commercial use.

As side notes: if there is only one way of doing something - like writing (pseudocode) var A = a++ for an increment then writing var B = b++ is not copyright infringement. Also, the way of doing something is more about software patents, while copyright protects how ideas are expressed.

Your concerns are valid but if I am reading your goals correctly then I think the best way to solve this problem is to find a license that explicitly states the restrictions you want, and then fix your work to whatever license offers you that.