I have received this message from Webpicasso:

------------------------------------------------------------------------------------
Hi,

we are the owner of the product Pageear©.

The modul "PageEar" is based on the free pagepeel from Webpicasso Media named PageEar©. This product is a brand from us and we agreed that the first developer create a Drupal Modul with the name PageEar including the PageEar files and the a copyright notice to webpicasso Media. Now you wrote your own pagepeel, kept the name PageEar, and deleted all informations to Webpicasso Media. We have no problems that you developed your own pagepeel but I red that you want to offer this modul without any copyright issues to third party so you must rename PageEar to your own product name.

So, we request to find another name for this modul in respect of the copyright.

Best regards
Christian Harz
______________________
Webpicasso Media
------------------------------------------------------------------------------------

I'm not familiarize with this things so I would like your advice.

At first it only affects the name and I think it is possible to change it on project page.

But I don't know if it would be better to change the CVS folder name too to a new name. That change would be something I could not do. Besides If it is necessary too, I don't know how it affects update system.

I suppose I should change the home page too, where I have the module documentation which name is "drupal pageear" and which domain is pageeargpl.co.cc.

So I would like your help to determine the best solution for this situation and suggestions for the name if possible. Does "pageeargpl" would be enough to respect name copyright?

Thanks in advance,
manfer

Comments

avpaderno’s picture

But I don't know if it would be better to change the CVS folder name too to a new name.

It is not possible to rename the CVS directory that contains a project. You need to create a different project, and re-commit the code, changing all the function names.

I would suggest to choose a name that doesn't include the old name. I would rather find a different name, like CurlyPage, or something similar.

manfer’s picture

I have just coded the new project. I created the project page. I did the first commit (as this time I'm starting from scratch I commited what is going to be 5.x version).

Now I'm stack, I'm receiving an error when trying to branch.

The command from within the project folder:

cvs tag -b DRUPAL-5--1

The error:

** ERROR: invalid branch for this directory:
** contributions/modules/curlypage
** See http://drupal.org/node/93999 for the format of valid branches.
cvs tag: Pre-tag check failed

On the documentation that the error shows I don't see any clue of anything I could be doing wrong.

manfer’s picture

What I want to do is create branch for 5.x compatible version. Commit 6.x to HEAD. Create branch for 6.x compatible version. Commit 7.x to HEAD. Create branch for 7.x compatible version.

After that tag on each branch to create releases.

dave reid’s picture

The proper branch for a 5.x-1.x type branch is 'DRUPAL-5'.

manfer’s picture

Well, reading that documentation node 93999 I was undestanding DRUPAL-5--x branches were accepted too though historically the brach was DRUPAL-5.

So as that documentation, at least for me, was not very clear, I finally understood (or misunderstood) that maybe 5--1 was not valid because I needed to start with 5--2

[Major] is an integer that indicates what major revision of the contribution the branch represents. In the case of development and other branches, the major version number must be 2 or higher, since the default stable branch for a given version of core (e.g. DRUPAL-4-7) corresponds with major revision 1, and by convention, releases with the major revision 0 (if used at all) are always from the CVS HEAD.

So before waiting for an answer (I did too fast but I hope maybe is not wrong how I did), and as for this situation that is a continuation of another module that must be discontinued for copyright issues, starting with 2 looked not bad, I tried:

cvs tag -b DRUPAL-5--2

and worked just fine.

Then commited the code for 6.x to HEAD, with changes, removes, adds, ..., and brach again:

cvs tag -b DRUPAL-6--2

Then commited the code for 7.x to HEAD,..., and branch again:

cvs tag -b DRUPAL-7--2

Finally in 5--2 branch I have tag as 5--2-1 to make it have the same number that should have the module if he continued with his old name. And same in 6--2 branch I have tag as 6--2-1. For 7.x just have made the development release.

This is not a mess, I hope.

manfer’s picture

If it is not a mess now I would need to know how to proceed with the old project.

In the new module I included the posibility to upgrade from any 2.x version of the old one. It is very easy, just maintaining the old one installed and enable and installing the new one will install the new module schema, import all pageears to new module and disables pageear module. After that the new module is installed with all the old configuration, and the old module is ready to be uninstalled, after uninstall, all files from old module can be removed. Doc included on INSTALL.txt.

If the other module is not present at all, or it is just installed but not enabled, the new module would do a normal installation process.

I have to explain this on old and new modules. How long should I maintain the old module or how is the best way to inform users about the change?

Which is your advice?

Thanks.

manfer’s picture

I have finished with the change. The new project is totally prepared, curlypage.

What is the best way to proceed next? Are the following two steps correct?

  1. In pageear unmark all the releases so no one is anymore supported?
  2. Change pageear project page to a notice explaining it is deprecated in favor of curlypage and with upgrade instructions?

If this is correct, something else I could do?

avpaderno’s picture

Change pageear project page to a notice explaining it is deprecated in favor of curlypage and with upgrade instructions?

It is enough to add a notice, rather than changing all the page text.

I would wait a little, before to mark all the releases as unsupported; one week, or two would be fine.

manfer’s picture

It is done, I included the notification on pageear project page. I will wait till December to mark releases as unsupported and change the pageear project page only to a deprecated notice.

Thanks for the help.

avpaderno’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.