3 ms·

Could you expand on what you mean by "reduce the cost by switching from the MIT license"? On your licensing page you also state "Open source licensing is still

Could you expand on what you mean by "reduce the cost by switching from the MIT license"? On your licensing page you also state "Open source licensing is still available, though it is the most expensive option by far." I think understand what you mean here, but still feel a bit confused.

dalke 6y ago
Sure, and I apologize for the confusion. I have academic licensing at EUR 0 for the pre-built Python wheels packaged for "manylinux" and EUR 1000 for source code availability. For companies have EUR $X for single geographical site, EUR $Y for multiple sites, and EUR $Z for MIT license. $X < $Y < $Z. For purposes of this example, say that $X=EUR 5000, $Y=EUR 10000, and $Z=EUR 20000, and that license renewals are 20% of sale price. (These aren't the actual prices, but not unreasonably different.) That means world-wide license renews for EUR 2 000 and MIT license renews for EUR 4 000. I had several clients with MIT licensing who switched to my (IMO generous) proprietary license to save a few thousand euro. The primary difference is the lack of a redistribution right, which means their value on that right is less than EUR 2 000. (I think the one company which continues to pay for MIT licensing does so because they see it as a way to provide extra funding to chemfp within their accounting structure, and not because they want the redistribution right.) Does that clear things up?
- raphlinus 6y ago
  Ah, so with the MIT license option they have the right to redistribute the source code, but you're asking them not to do that, as it would undercut your business? And most of your customers comply, as they have their own interest in holding their code close to the vest? This seems like a highly unusual structure, I can't think of a single other example where "made available under MIT license" does not also imply "code published." But I think I can see where it makes sense for you.
  - dalke 6y ago
    Yes, though technically I didn't ask them to not buy the MIT license option, but rather offered them another option which was cheaper. Personally, I would have preferred they stayed with MIT because it appeals to my desire to have people people support open source, and because I would have made more money. I don't think my pharma customers have any desire to distribute the code, other than to their collaborators. It's not so much "close to the vest" but rather that they don't have any infrastructure support for that - no public repos, no public mailing lists, little career benefit for doing so, and little involvement in managing FOSS projects - and a risk that I would drop them as a support customer. I'm more concerned about academic customers - people who don't want to pay money - who might release the software, and be able to offer "free"/grant-subsidized support, because that's what grad students do. I agree that I'm in an unusual. Chemistry has always been more protective than, say, biology. I suspect it's because the connection between compound and new commercial product is more direct than between a biological sequence and a new commercial product. OTOH, there's a huge amount of public research money going into bioinformatics, so it's hard to compare things head-on. I don't know what other fields are like though. If I developed an improved method to find oil, and sold it to petro companies under an expensive open source license, I don't think they would redistribute it to their competitors.
    - raphlinus 6y ago
      Thanks for the answer. In practice, the "MIT" option sounds very similar to the much more standard "buy a license to integrate the code into proprietary software." As I'm sure you're aware, that's the model that Ghostscript has used for 30 years or whatnot. Is there a particular reason you're risking your customer doing a source release instead of taking this avenue? My (incorrect) understanding of your MIT option is that it would essentially be a buyout, in other words compensating you for the lost revenue from a public release. I've seen that happen as well.
      - dalke 6y ago
        To date me, I learned about the Ghostscript model from Michael Tiemann in late 1996, when it used a delayed release model - GNU Ghostscript versions were released approximately a year after the corresponding Aladdin Ghostscript version. That model influenced my early thinking for chemfp. I thought there would be enough commercial interest to pay to develop the leading edge (and get a copy under an open source license), with a, say, 2-year delay for the no-cost open source version. There wasn't. But unlike the Ghostscript of 30 years ago, I wanted chemfp to be a fully open source project. That is, checking now, https://web.archive.org/web/20070614092626/http://pages.cs.wisc.edu/~ghost/doc/gnu/4.03/new-user.txt https://web.archive.org/web/20070614092626/http://pages.cs.w... says "[Artifex Software Inc. is] the only entity legally authorized to distribute Ghostscript per se on any terms other than the GNU or Aladdin" - that doesn't sound like an OEM could re-sell the source code under the same terms as received by the OEM, since only Artifex was authorized to allow that distribution. "Is there a particular reason .." My general support for FOSS? My willingness to try an experiment, see how it turns out, and report the results, in order to further the discussion about open source software in my field and how to fund it? My understanding that my pharma clients, almost as a rule, don't do software releases? My expectation that I can always fall back to consulting? My annoyance that published papers on fast similarity search almost invariably showed an amazing performance boost compared to a slow reference baseline, so even if there was a buyout this way, it would still result in reaching my main goals of promoting my FPS format and setting a more honest baseline? So no, no particular reason, but rather many reasons.

dalke 6y ago

Sure, and I apologize for the confusion. I have academic licensing at EUR 0 for the pre-built Python wheels packaged for "manylinux" and EUR 1000 for source code availability. For companies have EUR $X for single geographical site, EUR $Y for multiple sites, and EUR $Z for MIT license. $X < $Y < $Z. For purposes of this example, say that $X=EUR 5000, $Y=EUR 10000, and $Z=EUR 20000, and that license renewals are 20% of sale price. (These aren't the actual prices, but not unreasonably different.) That means world-wide license renews for EUR 2 000 and MIT license renews for EUR 4 000. I had several clients with MIT licensing who switched to my (IMO generous) proprietary license to save a few thousand euro. The primary difference is the lack of a redistribution right, which means their value on that right is less than EUR 2 000. (I think the one company which continues to pay for MIT licensing does so because they see it as a way to provide extra funding to chemfp within their accounting structure, and not because they want the redistribution right.) Does that clear things up?

raphlinus 6y ago
Ah, so with the MIT license option they have the right to redistribute the source code, but you're asking them not to do that, as it would undercut your business? And most of your customers comply, as they have their own interest in holding their code close to the vest? This seems like a highly unusual structure, I can't think of a single other example where "made available under MIT license" does not also imply "code published." But I think I can see where it makes sense for you.
- dalke 6y ago
  Yes, though technically I didn't ask them to not buy the MIT license option, but rather offered them another option which was cheaper. Personally, I would have preferred they stayed with MIT because it appeals to my desire to have people people support open source, and because I would have made more money. I don't think my pharma customers have any desire to distribute the code, other than to their collaborators. It's not so much "close to the vest" but rather that they don't have any infrastructure support for that - no public repos, no public mailing lists, little career benefit for doing so, and little involvement in managing FOSS projects - and a risk that I would drop them as a support customer. I'm more concerned about academic customers - people who don't want to pay money - who might release the software, and be able to offer "free"/grant-subsidized support, because that's what grad students do. I agree that I'm in an unusual. Chemistry has always been more protective than, say, biology. I suspect it's because the connection between compound and new commercial product is more direct than between a biological sequence and a new commercial product. OTOH, there's a huge amount of public research money going into bioinformatics, so it's hard to compare things head-on. I don't know what other fields are like though. If I developed an improved method to find oil, and sold it to petro companies under an expensive open source license, I don't think they would redistribute it to their competitors.
  - raphlinus 6y ago
    Thanks for the answer. In practice, the "MIT" option sounds very similar to the much more standard "buy a license to integrate the code into proprietary software." As I'm sure you're aware, that's the model that Ghostscript has used for 30 years or whatnot. Is there a particular reason you're risking your customer doing a source release instead of taking this avenue? My (incorrect) understanding of your MIT option is that it would essentially be a buyout, in other words compensating you for the lost revenue from a public release. I've seen that happen as well.
    - dalke 6y ago
      To date me, I learned about the Ghostscript model from Michael Tiemann in late 1996, when it used a delayed release model - GNU Ghostscript versions were released approximately a year after the corresponding Aladdin Ghostscript version. That model influenced my early thinking for chemfp. I thought there would be enough commercial interest to pay to develop the leading edge (and get a copy under an open source license), with a, say, 2-year delay for the no-cost open source version. There wasn't. But unlike the Ghostscript of 30 years ago, I wanted chemfp to be a fully open source project. That is, checking now, https://web.archive.org/web/20070614092626/http://pages.cs.wisc.edu/~ghost/doc/gnu/4.03/new-user.txt https://web.archive.org/web/20070614092626/http://pages.cs.w... says "[Artifex Software Inc. is] the only entity legally authorized to distribute Ghostscript per se on any terms other than the GNU or Aladdin" - that doesn't sound like an OEM could re-sell the source code under the same terms as received by the OEM, since only Artifex was authorized to allow that distribution. "Is there a particular reason .." My general support for FOSS? My willingness to try an experiment, see how it turns out, and report the results, in order to further the discussion about open source software in my field and how to fund it? My understanding that my pharma clients, almost as a rule, don't do software releases? My expectation that I can always fall back to consulting? My annoyance that published papers on fast similarity search almost invariably showed an amazing performance boost compared to a slow reference baseline, so even if there was a buyout this way, it would still result in reaching my main goals of promoting my FPS format and setting a more honest baseline? So no, no particular reason, but rather many reasons.