You know you've been around the block a few times...

[jducoeur]

... when your internal monologue goes something like this:

"A-ha!  Yes, that looks like the right solution to the problem."

(Smug.)  "Oh, I like that -- it's pretty innovative, and I think it's even a good user workflow."

(Dismay.)  "Oh, crap -- that means I probably have to write an effing patent..."

ETA: folks, I appreciate that you're trying to help with the comments, but you're not -- you're making an extremely difficult and painful decision much worse. I've been studying this question at *least* as long as any of you, I understand it quite deeply from all sides, and quite frankly, you're not in my shoes and don't understand the sheer number of issues I'm juggling here. Please stop.

Comments

[serakit.livejournal.com]

Because if you do something innovative and don't patent it someone else will steal it and patent it and make you not use it anymore?

[mindways]

...why? With public commits, proving prior art if someone else tries to patent it later ought to be trivial, I'd think?

[jducoeur]

Comes with being an employee of a real tech company. This is one of those cases where the Architect part of my brain (which hates software patents with a burning passion) comes into conflict with the CEO part (which recognizes that they may be unpleasant, but they're currently a requirement of being in this business at the level I intend to play).

Frankly, if I come up with what I think of as a real, defensible patentable tech (not the BS kind, but something that I actually think actually is within the spirit of the system), it borders on a failure of my responsibility to the company if I don't do something about that. That's part of the difference between a small wholly-owned "lifestyle" project and a serious, ambitious C-corp (which Querki is) -- I may be the boss, but I'm still an employee, and have to play by the rules. I don't have to be an asshole about it the way some people are, but I don't think I can ethically abdicate the issue entirely. It likely improves the company's chances of success and survival materially, and that has to be balanced against the principle of the thing.

I'd love it if the whole regime of software patents was nuked from space, so that the playing field was genuinely level, and I will continue to argue for that. But until that's true, if I'm going to claim that I'm serious about this, I have to play the damned game. Failure to do so may sound noble, but it's basically a statement of lack of seriousness -- a naive unilateral disarmament.

(Don't think I take this lightly: I've been pondering the likelihood of this for years now. It's a sucky situation, but not an issue I get to simply duck.)

*Sigh*. This is where the whole "creating a real company" thing starts to get terribly real...

[herooftheage.livejournal.com]

Do you have either shareholders, or investors? If it's a privately held business, isn't your duty to the company pretty much what the private owners want? You might decide you need to patent stuff so you can attract investors, but that seems fundamentally different from a responsibility to patent.

[dsrtao]

Pros and cons.

Pro: a patent might be useful as a visible proof of the company's asset.

Pro: a patent might be useful to sue a competitor

Pro: ...I think that's all.

Con: publishing is much, much cheaper

Con: having a patent won't save you much in a defensive lawsuit. Establishing that a patent covers what you think it covers versus a publication covering the same technique will come out even.

Con: publishing benefits other programmers. Most of them will not be in competition with you.

Con: owning a patent that other programmers want to use forces them to buy licenses and hire lawyers, which are not things that other programmers enjoy.

But mostly I could just point you at

http://jducoeur.livejournal.com/845505.html

and

https://jducoeur.dreamwidth.org/265450.html

and https://jducoeur.dreamwidth.org/528071.html?thread=3962055#cmt3962055