I'm not sure how to present this information. Bug reports should be single-issue items, so I made this a task since I'm going to mention multiple items. I offer this "review" of the Licensing product just as food for thought and maybe the basis of some discussions. Whether any of these comments result in code changes is not my immediate concern.

At this point, I have taken only a quick look at the Licensing module. I will add to this issue as I learn more.

The module page says: "Licensing is designed to be a framework for providing software licensing and registration through Drupal." and then gives some reasons why the project is not a duplicate of various others, including my project, uc_product_keys.

Detangle the licensing functionality from a specific ecommerce suite. (Plugin modules can be written to integrate licensing with ecommerce or ubercart without a great deal of pain)

This sounds good.

Allow vendors to sell software through physical store fronts, but still keep the licensing system centralized in Drupal.

Actually, uc_product_keys supports this as well.

Allow plugin modules to handle other things like generating 'Activation codes' when registering a license.

uc_product_keys supports this.

I was considering integrating uc_product_keys with Licensing, but I don't see a clear path yet. If Licensing abstracted the licensing concepts and provided an API for those, that would be great. However, it provides not just an API, but a user interface.

As a base framework, I would have preferred that you had started by looking at all the existing modules you mentioned, examining their approaches to licensing and then abstracting out the common features. As I look at Licensing, I am finding it difficult to understand how uc_product_keys could integrate with it.

For example, it's nice to provide a way to generate product keys, but I don't see how a generic product key generation method could work for most programs. I see an Export feature, but no Import, which make me think that the system is set up only for generating its own keys, which would make it unusable for uc_product_keys.

I don't understand why a customer would want to register a license. Generally, a software product "activates" a license by talking to a special server. What is your use case for registration?

The product features listed include:

Ability to generate, edit & delete unlimited unique license keys.

I don't see license generation as a good thing. The ability to integrate with existing license generation could would be much better. License generation is a specialty business and may require some knowledge of the software being licensed. Perhaps the Licensing package is not for software products?

Ability to export your keys into a CSV document, which you can mail merge and distribute with physical copies of your product.

Good idea. Pardon me while i steal it... :-)

Ability for users to 'register' their key when they sign up for a drupal account, or by visiting a page when logged in.

As I said, I don't understand this.

Users can have multiple keys registered to one account, and they are all displayed on their user page.

That's fine.

Provides views functionality for default and custom reports.

Good stuff. I plan to add views compatibility as well.

Brandable license keys like XXXX-BRAND-XXXX-XXXX-XXXX

This is just one of a million schemes for customizing a license key to a product.

Enough for now. Some (most?) of my comments may just reflect my ignorance about the product. I'm not particularly worried or bothered by the module duplication issues. If Licensing provides a good base API that uc_product_keys could use, I would be happy to integrate with it.

I've been trying to respect the claim that this is a framework for licensing, but so far it looks like just another licensing product (in other words, instead of something uc_product_keys can integrate with, it's just something where users either pick uc_product_keys or Licensing depending on their particular needs). I would be happy to find out I'm wrong. I would also look forward to a short overview of the licensing process as you see it.

Comments

nicksanta’s picture

nicksanta commented

You've raised some good points. Not having enough time to write a proper response, I'll leave it at this for the moment -

The model the client wanted was pretty straightforward.

His software used an algorithm using a user's email address, name and software version to create an 'activation code' which unlocked the software. Up to this point he sold everything out of his storefront, and to give users their activation code, he took down their details in the shop, generated the activation code, and gave it to them.

He wanted to redevelop his website, add a storefront, and have the website automate the activation process.

So the process now, is when he gets a new lot of stock he generates as many 'license keys' as he needs, exports and mail merges onto stickers, places the stickers on the jewel case and sells that directly to the customer.
Then the customer visits the website, enters their details along with the license key during user registration, and then receives their activation code which they copy into the software during installation.

I suppose i was developing this from quite a naive perspective, and didn't take into consideration things like importing specially generated keys and verifying them via SOAP or similar. The model (at this point from a developer's POV) allows storing the key, setting a status flag, and associating it with a user.

My main motivation to putting it up on d.o was to get people's perspective and ideas to make it a better framework.

freixas’s picture

freixas commented

OK. I understand now. I thought perhaps the Licensing module would manage an abstraction of the licensing process and I was curious as to what you had come up with.

The registration process is usually automated by having the software talk directly to the activation server. This seems more user-friendly than forcing them to enter the info on the Web site and then enter the activation code into the software (assuming anything about DRM is user-friendly :-). For big companies, there is usually a phone line to use as a backup.

Your client has several interesting requirements:

  1. His software doesn't communicate directly with the activation server
  2. He is selling his software the old-fashioned way: physical media with a printed product key, (Actually, large outfits still use physical media/printed product key, but haven't most smaller developers gone to using downloads and emails? I don't know. I don't expect large companies will use Drupal/Ubercart/uc_product_keys to sell their software, so I wrote for the small developer.)
  3. He appears to handle the selling on his own rather than through an an e-commerce module like Ubercart.

uc_product_keys is actually flexible enough to handle all this, but you do wind up with the e-commerce aspect. It doesn't make a lot of sense to use uc_product_keys unless you wanted to sell the software online. You also would wind up with having to write about the same amount of code—the generation code, the export code and the manual activation process (that's by design: these are the pieces I expect that software developer will write or buy).

In any case, at this point I don't see any way to merge my work with yours. I don't think you can merge your work with mine, either, because that pulls in Ubercart.

Your customer would gain some benefits if he ever decides to sell online using the uc_product_keys model. Customers could download the software, purchase the product key and activate the product without requiring any of his time. Customers would also have faster, 24/7 access to the product.

Thanks for providing the explanation.

grasmash’s picture

grasmash commented
Status: Active » Closed (outdated)