Extension licensing

What is the recommended way to add a license validation scheme to a purchasable extension?
I would like to be able to use a registration code and validate Extension purchase using REST API for Marketplace.

I see that other extensions are hiding and obfuscating a curl call to validate the purchase in OpenCart Marketplace. Is this the solution we should be using to "license" an extension? Personally I don't like this method as every developer has to create their own license validation scheme. Is there an "official" way to validate licenses?

I realize that with open source code, whomever has the code can circumvent license validation by locating and removing any licensing code. Without some type of purchase validation, someone could share extensions and/or use on multiple sites with a single purchase. How does a developer of OpenCart extensions protect IP?

I do not think its possible for 100% solution, however something simple would be better than nothing. :-)

Thanks for any suggestions or ideas on how other developers are protecting intellectual property.

rgbworld wrote: ↑

Thu Aug 03, 2023 12:05 am

What is the recommended way to add a license validation scheme to a purchasable extension?
I would like to be able to use a registration code and validate Extension purchase using REST API for Marketplace.

I see that other extensions are hiding and obfuscating a curl call to validate the purchase in OpenCart Marketplace. Is this the solution we should be using to "license" an extension? Personally I don't like this method as every developer has to create their own license validation scheme. Is there an "official" way to validate licenses?

I realize that with open source code, whomever has the code can circumvent license validation by locating and removing any licensing code. Without some type of purchase validation, someone could share extensions and/or use on multiple sites with a single purchase. How does a developer of OpenCart extensions protect IP?

I do not think its possible for 100% solution, however something simple would be better than nothing. :-)

Thanks for any suggestions or ideas on how other developers are protecting intellectual property.

Looking for simplicity on the matter to avoid replication of an extension on an opensource project is simply unavoidable; replication will still occur.

straightlight wrote: ↑

Thu Aug 03, 2023 7:22 pm

Looking for simplicity on the matter to avoid replication of an extension on an opensource project is simply unavoidable; replication will still occur.

Forgetting simplicity and code redundancy, is there an official or recommended way to validate the purchase of an extension?
I've searched the Marketplace and forums for developer extension licensing and come up short

If nothing currently exists, I can write something up and post an example here. However, if there is a recommended process, I would appreciate information on the matter. If anyone is aware of an existing Marketplace purchase-validation or extension licensing solution please advise.

My idea would be to use a curl request to an endpoint (Marketplace or other), with an order id, email, etc. Then "activate" the extension based on the results of the reply. I'm open to any discussion or ideas.

Thanks!

rgbworld wrote: ↑

Sat Aug 05, 2023 4:58 pm

straightlight wrote: ↑

Thu Aug 03, 2023 7:22 pm

Looking for simplicity on the matter to avoid replication of an extension on an opensource project is simply unavoidable; replication will still occur.

Forgetting simplicity and code redundancy, is there an official or recommended way to validate the purchase of an extension?
I've searched the Marketplace and forums for developer extension licensing and come up short

If nothing currently exists, I can write something up and post an example here. However, if there is a recommended process, I would appreciate information on the matter. If anyone is aware of an existing Marketplace purchase-validation or extension licensing solution please advise.

My idea would be to use a curl request to an endpoint (Marketplace or other), with an order id, email, etc. Then "activate" the extension based on the results of the reply. I'm open to any discussion or ideas.

Thanks!

In this case, better to code it up yourself by posting an example.

Hi!

This licensing model is popular in Russia. Your server receives a callback from the marketplace after purchasing your extension. It then automatically generates a license code and sends it to the customer's email address.

All of these solutions use the ioncube loader or PHP obfuscators. Most often, the controller and/or admin model are encrypted; less often, the catalog model and controller are encrypted (only to protect the code).

I usually worked on finalizing the code of encrypted modules.

Most often, such files are easily decrypted on dezender.net. The decryption of one file costs 5 euros. Once it was not possible to decrypt, the issue was resolved by events.

Encrypted modules are prohibited on the official marketplace.

Sometimes such systems grow to CRM-like systems. At this step, the functions of checking for updates for modules usually appear, sometimes with automatic updates. Be careful with this feature, I know three developers whose systems were compromised. Also you can use third-party software licensing mgmt systems.

Hi, when customers purchase your code, they should have the right to read and modify it according to their specific needs. Using obfuscators or encrypting the code can make it challenging to maintain the code in the future.

Not only can it be challenging but also prohibited on the Marketplace.

I never suggested encrypting code, obfuscating, or trying to hide the code from a customer. I am vehemently opposed to such tactics - which is why I said I was looking for a "simple" solution. If a nefarious actor wants to circumvent licensing, then so be it. If a developer wants to tear it apart or modify it to make it their own, that's fine as well.

The original question was whether or not there is a recommended or official process for licensing extensions? Apparently, the answer is No.
Are other developers just hoping that someone won't put their extensions on a torrent site? (somewhat rhetorical)
Is license-validation frowned upon or not with regard to OpenCart?

Validation of a purchase should not be complicated or a burden on customer, and IMO should be built into core OpenCart. That said, I am working on an extension example that does what I want. I will post it here or try to get it added to OC repo when it's completed. Attached are couple screen grabs. The only thing left to do is a curl call to validate the license. On the store's server, I also need to implement the receiving of Marketplace callback for maintaining a license table.

My plan is to do some of what @halfhope suggested:
- Receive a callback from the marketplace and add details to a database table.
- On extension settings page, add an Ajax register form (order_id and email) - Done. See attachments.
- Validate the purchase on form submission and activate extension accordingly.

Thanks for the replies.

There is no RESTful API for licensing, and it won't make sense anyway.

When you order and pay for an OpenCart extension, you get an email confirmation from OpenCart which contains the link to your OpenCart account (which you already know anyway). In your OpenCart account there is a download section for your purchased extensions. The end-user can open a support ticket via the OpenCart extension page, and the extension author will then receive a support request with the following details:

Order Details

Order ID: xxxxxxx
Order Date: 2023-xx-xx xx:xx:xx
Order Status: Complete
License Status: Active
License Expire: Jan 20, 2024

Extension Details
.....

So it pretty much has everything you'd need for an open-source extension.

halfhope wrote: ↑

Sun Aug 06, 2023 5:14 am

Hi!

This licensing model is popular in Russia. Your server receives a callback from the marketplace after purchasing your extension. It then automatically generates a license code and sends it to the customer's email address.

All of these solutions use the ioncube loader or PHP obfuscators. Most often, the controller and/or admin model are encrypted; less often, the catalog model and controller are encrypted (only to protect the code).

I usually worked on finalizing the code of encrypted modules.

Most often, such files are easily decrypted on dezender.net. The decryption of one file costs 5 euros. Once it was not possible to decrypt, the issue was resolved by events.

Encrypted modules are prohibited on the official marketplace.

Not only prohibited on the official marketplace, prohibited in general by the License: GNU/GPL !!
Mean in other words: every "buyer" has the right to get the plain (uncrypted / unobfuscated) files - so then why working this way?

Or: why working on the "Open Source" szene, publishing extensions under "somewhat" license (other then GNU/GPL which all extensions has to be licensed because the "Framework" OpenCart is published under that license) and then encrypting/obfuscating?

Many times the so called "developers" argue with "protecting my code" - if so really, you should not publish any extension for OC!

Actually, the GPL license suggests that there may be no close connection with a separate library file that is used in the module - https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins

But even more interesting is that there is no legal precedent proving that the GPL license can be applied to extensions and it will be considered legal, which is why there is a whole article about it on the specialized website - https://copyleft.org/guide/comprehensiv ... dech5.html

We also have the case of MySQL v. Progress Software case, where it was clearly determined that a library that does not have close communication can be closed.

Also, the copyright laws of the United States, the European Union, Hong Kong, and other countries contain provisions stating that a program is a set of instructions, not a place in memory or an inherited object. And the law is more legally binding than a licensing agreement.

Also, in all these jurisdictions, there is a provision that “method of operation” are not subject to copyright protection. Whereas the GPL license applies only to what is protected by copyright.

An example of the implementation of the principle No protection for “method of operation” is the case of Oracle v Google, where it was established that the names of methods are NOT equal to their imperative implementation. Also in the EU there is the case of SAS Institute v. World Programming Ltd (C-406/10).

We also have presumption of authorship and contract law in all countries. Usually, contracts (including licensing agreements) should contain provisions typical for the industry. And we see that other licenses, both free and commercial, either do not infringe on the rights of the authors of extensions or explicitly assign copyright to the authors of extensions (I can give examples if it is not considered advertising).

It is precisely the extortion to give up one's property rights that we see in the marketplace. After all, the license for the program that the user accepts when installing it is a matter for the copyright holder and the user. To alienate property rights of third-party developers, a separate copyright alienation agreement is required, which no extension developer has ever signed.

And now the most interesting thing is that modules most actively use code like
$this->load
$this->db->query
And this code is not of GPL origin - viewtopic.php?f=10&t=5204&start=0
Accordingly, it is not original, which means that it is not subject to the GPL