4 ms·
That's mean, but you'll just have to live with that. If someone takes active steps towards preventing people from making secondary apps/utils, then they're (a)
by TheRealPomax 6y ago
That's mean, but you'll just have to live with that. If someone takes active steps towards preventing people from making secondary apps/utils, then they're (a) jerks, and (b) allowed to do that.
Might be worth actually contacting them to ask why, if you can make the case that secondary applications will increase the value of their app, not decrease it.
- lbutler 6y agoI can understand why they do it, it's enterprise software so the more open you make it, then the less licences they can sell. They do have a module you can purchase to run API calls and access their files/software but as you probably guessed that's another $40k license! Most of my apps I build use this API, but for me to provide to other companies they need them to also buy the API extension. I'd love to cut out the middle man and I'll do it eventually when I reverse engineer the header!
- mrmonkeyman 6y agoI don't get this mentality. You haven't created this system. You have no idea what it takes or else you would have created it yourself. You don't like the price, but you want it anyway. How is this, I mean come on, different from stealing? You even say it: cutting out the middle man. You want to remove their profits.
- xenonite 6y agoAlthough the circumventing of security measures would be illegal in many countries. (Like removing the copy protection of a game)
- traverseda 6y ago>That's mean, but you'll just have to live with that I mean I know we're all on board with the idea of intellectual property actually being a thing now, but surely there are limits? I've seen people take the hard-line stance that if something is your property you should be able to dictate exactly under what situation it can be used, but there have to be limits to IP holders rights on some level, and I feel like reverse engineering a file format is a pretty reasonable place to draw that line.
- jtbayly 6y agoI didn't take "you'll just have to live with that" as a claim that the user couldn't reverse engineer it. It simply means that they've made it harder for the user to do so, and so the user has to live with it being harder.
- TheRealPomax 6y agothis.
- jstanley 6y ago> I know we're all on board with the idea of intellectual property actually being a thing now I don't know that that's true at all! I'd say the pendulum is swinging in the opposite direction.
- cortesoft 6y agoThey aren't saying you have to live with the legal restriction, but rather the technical restriction of having to reverse engineer it without the headers
- deathgrips 6y ago>we're all on board with the idea of intellectual property actually being a thing now No. Intellectual property is not genuine property. It is a state granted monopoly and is antithetical to free market principles.
- rswail 6y ago"Intellectual property" isn't a thing, "Intellectual Property Rights" are. They're not "antithetical to free market principles" if you accept that the "free market" requires regulation and that there are benefits to society by the cost of temporarily restricting free use with the subsequent benefit of ideas and expressions not being lost on the death/loss/bankruptcy etc of the IPR holder. IPRs are (in general) things that are protected by law and open to licensing and civil suits for damages if used outside those laws and licenses: * Trade Secrets and NDAs * Copyrights * Patents * Trademarks
- hamburglar 6y agoI'm surprised that nobody's pointed out that there are actually valid reasons other than greed to obscure your file format. It's an implementation detail, not a contract. If customers begin relying on the implementation details, you end up with angry customers when you change the implementation details. A SQLite db without the header is basically a statement saying, "we are using the obvious file format here for our convenience, not for general purpose access. Screw around in here at your own risk." If you modified their app's internal state db and screwed it up because they have designed their software with certain assumptions that aren't clear from just reading their db schema, that would be a nightmare for them to support. The easiest thing for them to do is just to try to discourage tampering with their internal state. This is especially true if there's a chance that a market for secondary apps/utils will spring up. If that's to happen and be viable, they absolutely would want to put thought into what their supported interfaces are for those apps/utils, otherwise they will end up painted into a corner and unable to change their architecture without destroying a marketplace.
- EvanAnderson 6y agoI've never understood the "We can ship this but it's not contract" mentality. To my mind if you ship something it's contract. I think developers keeping that in mind would make the world full of more resilient code. You're making a contract w/ your future self, if nothing else. To the point re: modifying internal state and screwing-up the application - If you're writing anything out to persistent storage you should assume that it's untrusted data when you read it back in. If for no other reason than physics itself is a malicious (or, at best, ambivalent) actor.
- catalogia 6y agoSometimes a programmer may like to create such a contract, if only with their future self, but have reason to fear their boss will force them to break that contract in some not unlikely future.
- hamburglar 6y agoIf your app ships with a dynamically loaded library and I dig through the exposed functions and find something undocumented that looks useful and I figure out how to use it, that's a contract to you? That's utterly insane. Re: the concept of untrusted data, this is off in the weeds argument for argument's sake IMO. Do reasonable validations of the state data, sure, but picking nits about the nature of trust and internal application state is an infinite hole I'm not jumping into with you.