CVS edit link for alpapan

As part of an academic team, we have been using Drupal to deploy bioinformatic software. We are publishing the software under GPL and would like to host in Drupal.org. The particular module we wish to upload, Drupal Bioinformatic Server framework is a unique API to allow system administrators to deploy common bioinformatic tools rapidly and safely, allowing Drupal to take of user management and permissions. Demos of deployed software can be seen at http://insectacentral.org and the source code is documented at doxygen standards.

We hope to see an increased use of Drupal for bioinformatic software and hopefully we will play a small part with this effort.

many thanks
Alexie Papanicolaou
CEC-Biology
University of Exeter

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alpapan’s picture

Component: Miscellaneous » Code
Status: Postponed (maintainer needs more info) » Needs review

Please find it attached. Please note it needs a Postgres database.

thanks and happy new year
alexie

alpapan’s picture

FileSize
398.52 KB

Sorry,
network from home had been consistently bad.
Here it is again.

alpapan’s picture

FileSize
397.55 KB

Darn, old version. Here is the proper one...

alpapan’s picture

FileSize
407.39 KB

And final oops: uninstall bug fixed.

a

apaderno’s picture

Component: Code » Miscellaneous
Issue tags: +Module review
alpapan’s picture

Hello
Thought I could beg for an update?
thanks
a

apaderno’s picture

Status: Needs review » Needs work

As per Apply for contributions CVS access the motivation should be expanded, and include more details about the features implemented by the module, and a comparison with the existing solutions.

alpapan’s picture

DBSF (Drupal Bioinformatic Server Framework) is an API to rapidly deploy software for laboratories that do have extensive bioinformatic facilities or are not satisfied with alternative software.

The DBSF has the following attractive features:

For the system administrator:

Secure & fast to deploy: the demonstration required 30' to setup from scratch, 10' of which was the BLAST server. The administrator has to merely click on a checkbox to activate the software and then choose which databases will be available to the plugins.

Secure with private data: We know that laboratories often have two types of data: those they wish to make public and the unpublished ones they wish to utilize only in-house. The solution is often the creation of two separate servers, one password protected. The DBFS takes care of user management and allows you to choose which datasets are available to which users. An unlimited number of user groups can be created included the anonymous/guest visitor who has not logged in.

Plugin format: It comes with NCBI's BLASTALL but DBFS is an API framework and easy to extend, our publication will have a manual as supplementary material to guide bioinformaticians in writing their plugins with 1-2 days.

High Performance Computing (HPC) support: Optionally (the demonstration server does), it can utilise the Condor job management system so jobs run on a PC-farm instead of the often meek BLAST server. A perl daemon manages the submissions automatically.

Database API is Chado-compatible: The DBSF is GMOD compatible and uses the robust, normalized Chado database. As Chado is sequence feature-driven we created sequence-less table set which follows Chado-convention. The future aim is to be able to integrate multiple website deploying this software.

For the end-user:

Build for wet-lab researchers. They can upload a multi-FASTA file to be used as the query or even the reference database: there is no need to restrict the user to the administrator's datasets. The file size limit is customizable (for demo it's set at 1 Mb). Users can bookmark their search and re-retrieve it within 7 days. Further, they can simultaneously run multiple BLAST algorithm searches.

Driven by open-source software and adheres to community standards: The output is driven by BioPerl (XML, HTML, TXT and a graph using Bio::Graphics). The database infrastructure is GMOD-compatible and the visualization is securely managed by Drupal.


Tutorials with figures can be found at

There is currently no similar module in Drupal

thank you
alexie

alpapan’s picture

Status: Needs work » Needs review
FileSize
404.93 KB

Current stable version attached.

thank you
a

zzolo’s picture

Status: Needs review » Needs work

Just come quick thoughts/questions:

* What is the "doc" directory for?
* The doc directory looks like it already has a CVS directory.
* If the doc directory is just documentation, that is not in a Drupal-ready format like hook_help or advanced_help, I would suggest that this be hosted somewhere else and linked to from the project.
* DB tables should be prefixed with module name.
* In install hook, why do you install the schema, then do a table alter?
* Overall, why does this module require Postgres?
* You use some nice features like foreign key constraints and cascading, but I think Drupal aims to be more portable over a feature that is often not used. Are these necessary?
* Statements like this: drupal_set_message("Software $name is active.", 'warning'); are not using that function and t() properly.
* Your dbsf file is 3000+ lines long. This is a lot of code to add to every page load. It is suggest that you split this up. The menu system allows you to specific a file to include on the pages you provide.
* Also, having a better file structure would be nice, such as an includes directory, or modules directory.
* Your module should not have sub-modules that do not have the prefix of the base module. This can cause name collisions with other modules in the CVS repo. If they are that separate of modules, they should be separate projects.
* What are the *.fsa files for?
* What is the perl script needed for? (as this could be a security risk)
* Your files should not include licensing information as putting up on drupal.org assigns it to the GPL.
* You should only include $Id$ at the top of files in comments, as drupal.org CVS handles the replacement.

Overall, pretty intense. I have very little idea as to what this does, but it does a lot of it. Great work, it would be cool to get this work out into the world.

alpapan’s picture

Assigned: Unassigned » alpapan

Thanks

I'll start updating it later this week.

apaderno’s picture

Assigned: alpapan » Unassigned
alpapan’s picture

Status: Needs work » Needs review
FileSize
61.66 KB
51.91 KB

Dear zzolo

Please find below the updated contribution and answers to your questions:

Please note that I have splitted the two modules files as two module as you suggested: "dbsf" and "genes4all" (used to be icbasic). The latter has all the common installations/functions for what will (eventually) be submodules and is a dependency for dbsf. The dbsf is distributed separately to ease the burden of dbsf-specific updates.

* What is the "doc" directory for?
It was the doxygen documentation. This has now been removed. I'll make a full manual/advanced_help someday...
A README has been added

* DB tables should be prefixed with module name.
Done

* Overall, why does this module require Postgres?
First, this module, being a specialized bioinformatics module, is not aimed for general use but is part of the GMOD Consortium (http://www.gmod.org). The Consortium's database of choice (Chado) is also implementing PostGres and wanted to clone part of its structure into Drupal with as high fidelity as possible. Second, PostGres 8+ is more secure and robust than MySQL (by far) and the foreign keys are used to enforce that. Third, I'm more familiar with PostGres than MySQL (sadly, again by far) and since I'm the only maintainer I can address issues much faster if I have to debug only one database system.

* In install hook, why do you install the schema, then do a table alter?
Some schema features, such as boolean or timezone are not supported by Drupal. I wanted to have the same tables as Chado (see above) so had to implement _alter

* not using that function and t() properly.
Fixed

* Your dbsf file is 3000+ lines long
Done, for both modules

* having a better file structure would be nice
Done

* should not have sub-modules that do not have the prefix of the base module
Done

* What are the *.fsa files for?
DNA sequence in FASTA file format. They are part of the Demonstration and now reside under examples/. A README provides more information

* What is the perl script needed for? (as this could be a security risk)
In dbsf: This is the daemon that handles the execution of the BLASTALL program, which is dbsf acts a WWW user interface for. I have tried to make it as secure as possible by allowing forking into an unpriviliged user. The README explains a bit more (and offers a disclaimer). If a Perl programmer wishes to co-maintain in order to ensure it is bulletproof then I'd have no problem with that.
In genes4all: This is a small bioperl (http://www.bioperl.org) script to query a database (external or as a flatfile) for Species information.

* Your files should not include licensing information as putting up on drupal.org assigns it to the GPL.
Done, except for the dynatree (http://code.google.com/p/dynatree) JavaScript script which comes with it's own non-conflicting MIT license (genes4all/includes/dynatree)

* You should only include $Id$ at the top of files in comments, as drupal.org CVS handles the replacement.
They had been changed by my CVS server. I've now updated it.

Many thanks for taking time on this, please let me know if I can do something more,
alexie

apaderno’s picture

Status: Needs review » Needs work

Your files should not include licensing information as putting up on drupal.org assigns it to the GPL.
Done, except for the dynatree (http://code.google.com/p/dynatree) JavaScript script which comes with it's own non-conflicting MIT license (genes4all/includes/dynatree)

See http://drupal.org/node/66113, and http://drupal.org/node/422996. Third-party libraries available from third-party sites should not committed in Drupal.org repository, if not in some particular cases; in general, Drupal.org repository should just contain Drupal modules.

alpapan’s picture

Status: Needs work » Needs review

Dear Kiamlaluno,

Note that

They are absolutely and always forbidden, unless if they are licensed under GPL or GPL v2+ or they have a broader license and can be re-licensed under the GPL.

You are probably aware that the MIT license falls under this category.

Further, the included script is known to work with the module. No one can guarantee that the script's developer will ensure such future compatibility

Is that acceptable?

The other option is to remove the script and make a new googlecode project to deploy just that script.
thank you,
a

alpapan’s picture

Here is the version without the MIT-licensed dynatree.

thanks
a

apaderno’s picture

So far, http://wwWendt.de/tech/dynatree/doc/dynatree-doc.html, and http://code.google.com/p/dynatree/ report just a license for the code, and that is MIT License. Only the author of the code can decide if license the code with both MIT License, and GPL License.

alpapan’s picture

FileSize
102.71 KB
96.21 KB

Some more up to date code attached.

thank you
alexie

zzolo’s picture

Status: Needs review » Needs work

Hi @alpapan, nice work. Since you have split the modules up into two distinct ones, can you choose just one to review? Thanks.

alpapan’s picture

Status: Needs work » Needs review

Hello
I guess I choose "genes4all". How may I get a project for "dbsf"; shall I make a new application?
many thanks
alexie

zzolo’s picture

To clarify, this issue is for your CVS application. Once you have a CVS account you can create all the projects you want (but should nto abuse that). The CVS application process is based on reviewing a module.

zzolo’s picture

  1. sorttable.js still has license information. You should rename it as well to be prefixed with your module.
  2. phylogeny_tree.js needs docblocks and should be renamed to be prefixed with your module.
  3. You are missing $Id$ in multiple files
  4. What are the license and origins of your image files?
  5. Please follow coding standards for all kinds of files, including CSS and JS.
  6.     drupal_set_message(t('The genes4all module was not installed: it requires a PostgreSQL database due to integration with GMOD and chado.'), 'error', FALSE);
    

    For these requirements, as well as for the memory requirements mentioned in the README.txt file, you should use hook_requirements().

  7.     $sql_delete1="DELETE FROM {genes4all_cv} where cv_id=%d";
        $sql_check1 = "SELECT cv_id as id from {genes4all_cv} as cv where cv_id=%d";
    

    Be consistent with your spacing and follow standards.

This is a lot of code and it would be really cool to get someone else to look at this as well as my time is limited.

zzolo’s picture

Status: Needs review » Needs work
alpapan’s picture

Hello

For images, would a LGPL instead of GPL be allowed or would I have to contact the author?

thanks
a

alpapan’s picture

Status: Needs work » Needs review
FileSize
138.25 KB

Hello

* Renamed js files; removed licensing info
* Added $id$ and docblocks in files which were missing
* Updated the image directories, all images are now under fetched from a GPL2+ license (see README in image dir) or created by me.
* Updated the code use Coder and passed checks on Drupal Coding Standards, Drupal Commenting Standards and Drupal Security Checks
* Implemented hook_requirements

thanks
alexie

zzolo’s picture

Status: Needs review » Needs work

As far as the images. The overall policy is to not allow third party resources or code in the CVS repo. There are some outliers, mostly for cases where you have modified the code or the resources are very difficult to find. Most of the time, there are instructions in the README to describe where to download things form and where to put them. I always have a hard time finding the handbook page for it, but its out there.

alpapan’s picture

Status: Needs work » Needs review
FileSize
137.56 KB

Thank you

I believe you mean this page
http://drupal.org/node/66113

They had been modified into SVG & GIF from the original PNGs. I was attribute the source in the images/README. Is that ok?

made some corrections on the genes4all_chado.install attached.
thanks
a

alpapan’s picture

Hello

as well as the above fix to use hook_requirements in genes4all_chado.install also made now the following:

* It now makes proper use of the variable tables (variable_get etc via genes4all_get_add_var) and renamed one such variable with module name
* a couple bugs from my side

http://gmod-dbsf.googlecode.com/files/genes4all_public_0.9.tar.gz

As you mentioned, it is a lot of code, and I really appreciate the time you've put in reviewing it but it has already made a more robust and Drupal friendly module (and I learned quite a bit!)
thank you,
a

zzolo’s picture

Status: Needs review » Needs work

Important things:

  1. In install file, I think you had a little laps in using $t() instead of t()
    
        if (isset($memory_limit) && parse_size($memory_limit) < parse_size($recommended_memory)) {
          $description = t('We recommend you set a memory limit of %memory_limit. Currently, a %memory_minimum_limit PHP memory limit exists.',
            array('%memory_limit' => $recommended_memory, '%memory_minimum_limit' => $memory_limit)
          );
          $description .= ' '. t('Increase the memory limit by editing the %f file and adding %c.',
            array(
              '%f' => conf_path() .'/settings.php',
              '%c' => "ini_set('memory_limit', '128M');",
            )
          );
          $requirements[] = array(
            'title' => t('Genes4all PHP memory limit'),
            'value' => $memory_limit,
            'description' => $description,
            'severity' => REQUIREMENT_WARNING,
          );
    
  2. Any README files should be README.txt files so that Windows doesn't go crazy.

Minor:

  1. You should have a @file docblock in your CSS file.
  2. Not sure if I undersand what the files in the help folder are doing?

Overall real close. I would say this should be good to go next time around.

alpapan’s picture

Hello

thank you

1. That's in the runtime loop, so no $t is needed
2. Fixed, even though the module will never support Windows (due to Perl)
3. Done. But didn't know I should as /none/ of the contrib module i have in my system have one (advanced_help, biblio, cck, ... views)
4. Placeholders... I added a note to that effect, I trust they don't hurt. I ought to do the help at some point but I have no time before July for such a time consuming endeavour

Pls, see same link as above.
ta,
a

alpapan’s picture

Status: Needs work » Needs review

One more time

Question:
Dynatree library is now under GPL, see http://code.google.com/p/dynatree/wiki/LicenseInfo.
I have not done it for this release but is it possible to include in the CVS now that it is under GPL2? this will reduce the installation steps for the user.

apaderno’s picture

The general policy in Drupal.org is to not add to Drupal.org repository code that is available from third-party sites. Drupal.org repository is though to be a repository of modules, and themes.

apaderno’s picture

Status: Needs review » Needs work

I don't see any attachment to the previous comments, which is what you are supposed to do when you are suggested to change the code.

zzolo’s picture

About $t(). You are right. But, it is good for consistency.

Well, most contrib modules dont fully follow the standards. Like I said, it is minor and would not stop the application process.

alpapan’s picture

Status: Needs work » Needs review
apaderno’s picture

Status: Needs review » Needs work

@alpapan: You are supposed to attach the new version of the archive here (see the other applications).

alpapan’s picture

Status: Needs work » Needs review
FileSize
137.9 KB

there must be some fancy automated system that takes advantages of attachments i guess

here
a

zzolo’s picture

Status: Needs review » Needs work

In genes4all_autocomplete.inc (please note the usual standard is genes4all.autocomplete.inc):

      $result = db_query_range(
        "select name from cvterm where cvterm_id IN (select distinct cvterm_id from library_cvterm) order by name", $string, 0, 10
      );

You are not capitalizing SQL reserved words, nor are you using the table prefix syntax: {table} . Both of these are very important. Please make sure this is true of all queries.

--
Note: Please be patient with the CVS application process. It is all done by volunteers. Our goal is not to be arbitrarily slow or meticulous. Our goal is to get you CVS access and ensure that you are and will become a more responsible Drupal contributor. For a quick reference on what I look for in a code review, please see this article.

alpapan’s picture

The {} is used for all Drupal DB queries but always excluded for the Chado DB specific queries. This is on purpose by design because of a bug we found in Drupal.

Can you please explain why capitalization is important because it would cost $$$ to fix this in the entire module.

thanks
a
ps. CVS application started 02 Jan and I'm glad it is not considered pedantic.

zzolo’s picture

Sorry to be annoying, but can you link to that bug. I have never come across that.

http://drupal.org/node/2497#formatting
"Make SQL reserved words UPPERCASE. This is not a suggestion. Drupal db abstraction commands will fail if this convention is not followed."

I wish there was a link or more explanation here, as I don't actually understand why this is either. Maybe someone else can answer that sees this. I am asking in IRC right now in hopes to find out. So, it seems like the main thing is for http://api.drupal.org/api/function/db_rewrite_sql/6 (the WHERE needs to be capitalized). I don't see why this would cost money?

Overall, this is really close, but we do need to address these things first. Thanks for your patience in all this.

--
Note: Please be patient with the CVS application process. It is all done by volunteers. Our goal is not to be arbitrarily slow or meticulous. Our goal is to get you CVS access and ensure that you are and will become a more responsible Drupal contributor. For a quick reference on what I look for in a code review, please see this article.

alpapan’s picture

Hello

Ok, will do.

Please verify that nothing else needs changing, otherwise I'll wait until all your comments have been submitted (it's really frustrating submitting a new archive only to go back to it a few weeks later) and get everything done together.

Drupal error:
When we had bracers around the table names for the external DB specific tables and the db_prefix for Drupal (i.e. 'default') was set but the db_prefix for the external DB (e.g. 'chado') was set to null, then the rewrite was using the db_prefix of 'default'. we never had time to investigate this it deep enough and submit any bug reports so we simply made our own patch to ensure that all external DB tables had no bracers. In any case, this solution is not causing any problems to the module even if it is 'not clean'.

Because the module is already used in production, i'm happy to flag this as an issue which needs to be investigated and if necessary file a bug report (but not anytime before September...).

thanks
a

zzolo’s picture

@alpapan

I don't see what the difficulty is in creating a tarball of your work. This module is very large and it takes a serious amount of time to review. It would have been much simple to apply with a much smaller module. I try, but I can't guarantee that I have caught everything.

As far as the {} issues. I can't seem to find the code that creates the chado table. Can't you just use the Drupal prefix when creating that table, so that the correct syntax can be used?

Also, it doesn't look like the images are actually GPLv2 form the link you gave. Also, the link you gave does not look like it includes the images you have with this module.
http://phytonix.deviantart.com/art/Ricebowl-22605468

--
Note: Please be patient with the CVS application process. It is all done by volunteers. Our goal is not to be arbitrarily slow or meticulous. Our goal is to get you CVS access and ensure that you are and will become a more responsible Drupal contributor. For a quick reference on what I look for in a code review, please see this article.

alpapan’s picture

Tarball
No it is not difficult making a tarball, but it is difficult uploading one if you have village internet connection. Uploading to google can be done via the server I sshed into. In reverse, I don't see the problem with clicking on a GoogleCode link rather than a forum link.

Images:
Ricebowl by ~Phytonix
Customization / Icons / OS Icons / *NIX ©2005-2010 ~Phytonix
Ricebowl is an icon collection for Linux, Mac OS X. Windows might be supported as well in the future.
Ricebowl will be my primary icon project now while Torchlight will not be updated any more.
Simple, consistency and soft color is the theme of Ricebowl.
Ricebowl is released under the LGPL license. See inside the package for license details.
If you want to donate to Ricebowl, please visit [link]

Any images not in on that site were created by me (as mentioned in README)

Chado
There is no chado table. It is a secondary database. Please see http://gmod.org/Chado

I cannot add the {} unless someone spends a lot of time testing that it doesn't cause the same problems it caused 6 months ago. Currently I nor anyone I know can help with that.

I will convert DB reserved words to capitals when I find the spare time. Currently, they are causing no problems on a production site (http://insectacentral.org)

thanks
a

apaderno’s picture

Ricebowl is released under the LGPL license.

LGPL License is not GPL License V2+. The two licenses have differences that don't make them compatible; just to make an example, LGPL License allows to link the LGPL code to code licensed under a proprietary license, but it's not so with GPL License for which the code linked to GPL code must be licensed under GPL License too.

alpapan’s picture

Hi

You're correct.

I asked him to dual license, otherwise I'll remove the image directory from the next distribution.

many thanks
a

alpapan’s picture

One question
I started the Drupal CVS process in order to take advantage of the update notification which IMO are extremely useful.
Say I wanted to release my module under LGPL (in another repository such as google code) because I find GPL too restrictive, but I would still want to tap into the update notification function. How could I do that / is there any precedent on doing it? For example, could I create a dummy Drupal module which requests to download the source from another repository (and why one has to do that) and I update it's version on drupal.org when a new version is released?

Really, we don't want users to spend 30' installing a module.

many thanks
a

apaderno’s picture

Say I wanted to release my module under LGPL (in another repository such as google code) because I find GPL too restrictive, but I would still want to tap into the update notification function. How could I do that / is there any precedent on doing it?

The update manager on Drupal 6 just checks out drupal.org.

I am not sure if using a different server would resolve the problem with the license.
As Drupal is GPL-licensed, any Drupal module must be GPL-licensed too. This is because any Drupal module uses Drupal functions, and it is linked to Drupal code.

alpapan’s picture

Thanks Kiamluno

Could you please explain this statement:

"One feature of the LGPL is that one can convert any LGPLed piece of software into a GPLed piece of software (section 3 of the license). This feature is useful for direct reuse of LGPLed code in GPLed libraries and applications, or if one wants to create a version of the code that cannot be used in proprietary software products." from http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

Specifically:
Section 3

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

* a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
* b) Accompany the object code with a copy of the GNU GPL and this license document.

And Section 5

5. Combined Libraries.
You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following [..]

and most importantly section 1

1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.

Further

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.[4]

http://www.gnu.org/licenses/lgpl-java.html

IMO meaning that LGPL software may be incorporated into another software that has a different license. This is because the LGPL license was constructed so that software is easier to use with other licenses, not more difficult.

Others seem to agree with this notion: http://www.differencebetween.net/miscellaneous/difference-between-gpl-an...

Summary:
1. GPL requires that you provide the code for all changes made to the software.
2. GPL is the basis of open source software for programmers.
3. LGPL is used for software libraries, versus the execution files of GPL.
4. GPL offers a wide range of potential improvements for the entire programming community.
5. LGPL has the potential to be transferred into GPL terms.

Where in my understanding the transferance occurs by the developer of the work linking the LGPL library, not the LGPL creator.

Also please read http://teem.sourceforge.net/lgpl.html

Please confirm that it is illegal to incorporate LGPL components in GPL software. For if it is not, then incorporating LGPL images in a Drupal module is perfectly acceptable, especially since due citation has been given.

many thanks
a

apaderno’s picture

Issue tags: +Legal

IMO meaning that LGPL software may be incorporated into another software that has a different license.

Any Drupal module, as it's used from Drupal code (which is licensed under GPL License) is still licensed under GPL License (this is why GPL is also called a viral license). If what you said would be true, then a Drupal module would be licensed contemporary under GPL, and LGPL, which is not possible.

apaderno’s picture

The LGP License reports the following sentence:

When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library.

The GPL License reports the following sentences:

This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law
:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".

In the case of Drupal modules, as they are linked to Drupal, they are derivative work of Drupal; as Drupal is licensed under GPL License, also the modules are licensed under GPL License.

alpapan’s picture

Status: Needs review » Needs work

Hi kiamlaluno

Earlier I was under the impression (from what you wrote) that LGPL-using software had to be bundled as LGPL. Hence my suggestion to release my module as LGPL. As I wrote afterwards above, I found out that there is a decent chance you're incorrect: GPL software can contain LGPL software and therefore my suggestion (as a resolution to the issue of what icons to use) of releasing my module as LGPL is no longer required.

Indeed, this is not about me trying to relicense drupal or this module attempt. It is about me trying to make module public without having to ask the user to spend 30' do install it. Your opinion that I use GPL icons and not LGPL is what I'm trying to soften.

I agree with you that the module would be under GPL. But I argue that portions of the module can be LGPL as long as a ATTRIBUTION AND LINK to the source file is provided. No relicensing is needed.

If this cannot be done because of Drupal's CVS regulations (not GPLs), then the CVS of Drupal can have a dummy module that links to another repository where the GPL drupal module can be downloaded as a single tar archive. This would adhere with GPL, Drupal CVS regulation, allow users to check the update and only take a couple of minutes to install it.

Please re-read my previous post in that context and let me know how to proceed or offer advice.
cheers
a

alpapan’s picture

FileSize
113.06 KB

Dear zzolo

I have made the changes you requested and the module can be found attached here. As requested, there is no non-GPL code in the module because of the Drupal CVS restrictions. It is my understanding these are CVS and not GPL restrictions (e.g. GPL allows including GPL software but Drupal CVS does not) but this is irrelevant.

There are a couple of instances where the {} notation is not included; this is for SQL statements specific to the external database. This is due to the reasons I gave you above, it is an external database and from perusing the Drupal site it seems that Drupal 6 doesn't have much experience with external databases. I trust you're fine with that.

Please let me know if there is anything else that needs to be addressed.

cheers
alexie

alpapan’s picture

Status: Needs work » Needs review
apaderno’s picture

Status: Needs work » Needs review

But I argue that portions of the module can be LGPL as long as a ATTRIBUTION AND LINK to the source file is provided. No relicensing is needed.

Apart that a module is integrally licensed under one or more licenses, you cannot license code under both GPL, and LPGL because the licenses are in conflict with each other. It's not also possible to license under LGPL code that uses a library licensed under GPL, because for definition the GPL license is viral, which means that is not possible to release under a different license code that contains GPL licensed code, or code that is considered derivative work of GPL licensed code (it is considered derivative code also code that links to GPL code); if that would be possible, then I could release under a proprietary license code that uses (or integrates) GPL code.

If this cannot be done because of Drupal's CVS regulations (not GPLs), then the CVS of Drupal can have a dummy module that links to another repository where the GPL drupal module can be downloaded as a single tar archive.

It is not allowed to create a project page, if you are not going to commit code in Drupal.org repository; there are some exceptions, but they do not include the case you described.

alpapan’s picture

Hello kiamlaluno,

There seems to be a lost thread. Or maybe you are commenting out of context? Please do feel free to comment below:

I'm mentioning licensing under GPL.

Purely for clarification, this is the position we have maintained (the googlecode repository reports the GPLv3 license): Further, maintaining GPL licensing was a constant policy apart from a brief period when you suggested that the use of LGPL icons would force me to license under LGPL. Therefore, please stop threading into any potential dual licensing of this drupal module.

I've also mentioned my personal opinion that including LGPL code (actually icons) in a GPL software is not a breach of LGPL license but may be a breach of Drupal CVS regulations. I requested your opinion on this and advice on resolution. My current action had been to remove the potential offenders.

Thanks for reading
a

alpapan’s picture

Dear zzolo

Correct, db_rewrite_sql has a pattern search for WHERE.

I guess the module worked before because it simply never made a call to rewrite node, taxonomy and comment queries. Actually it makes few calls to any Drupal table directly.

I know it is a lot of time to go through it and I really appreciate it as especially in the beginning it helped a lot. Please do note that a lot of hours have been spend on benchmarking this module so I'm iffy about asking anyone to make 'minor' changes every so often (and why I begged you to submit your suggestions in one go rather than a continuous trickle).

Having said that, it was good to change for consistency but it took 3h to manually change and check that ca 200 SQL commands didn't break anything...

cheers
a

alpapan’s picture

LGPL License is not GPL License V2+. The two licenses have differences that don't make them compatible; just to make an example, LGPL License allows to link the LGPL code to code licensed under a proprietary license, but it's not so with GPL License for which the code linked to GPL code must be licensed under GPL License too.

Dear kiamlaluno

This case seems to be popular, see e.g. http://drupal.org/node/299545.

I would like to know why you disagree with the discussion of this thread over using icons (which are not code it seems)? Why can /I or any commiter/ not simple relicense the LGPL icons into GPL and include them in the module?

I would like to point out that you forced me to spent hours literally trying to understand all this (adding 5 LGPL icons to my module) and I hope that you give a good overall explanation and then add it to the http://drupal.org/node/299545 thread so that it is to everyone's benefit.

thanks
a

apaderno’s picture

Why can /I or any commiter/ not simple relicense the LGPL icons into GPL and include them in the module?

If you are not the author of the icons, then you cannot relicense them under a different license; if that would be true, then I could get all the LGPL icons, and relicense them under a proprietary license.

I think that who applies for a CVS account agrees to commit files licensed under GPL License.

zzolo’s picture

Hey @alpapan, been traveling. Will get to review this again soon. Thank you for your patience and understanding.

I think we do try to catch everything all at once, but this is difficult, especially with your module as it is very big. It also poses a problem because we have to review the whole module every time you resubmit an edit, as we can't know exactly what changed, and possibly somewhere in the edit, someone could have broken good code.

alpapan’s picture

I'm sorry kiamluno but I cannot find what you say in the LGPL license agreement. I find the opposite in fact: that yes, anyone can use LGPL code in another package and license that package as GPL (or any other license under the world, even proprietary). Note that you are misunderstanding the concept of relicensing: one is not relicensing the original LGPL source code but the linking (which can be static i.e. inclusion, as per license text).

Unless you can show some FSF text that says otherwise, I (and others) believe your interpretation is incorrect. Also the aforementioned Drupal issue points towards LGPL images being allowed in Drupal modules and you have not replied to that issue.

thanks
a

alpapan’s picture

Hello

I find the diff program to be particularly effective. Do you have access to this program? I can prepare the text files if you wish

thanks
a

apaderno’s picture

one is not relicensing the original LGPL source code but the linking (which can be static i.e. inclusion, as per license text).

As far as I know, the license doesn't apply only to the source code, but also to the executable. If it would not be so, then I could sell a GPL program as it would be mine, under a private license.
If a library is licensed under LGPL, I can include it with an application I license under a proprietary license, but the library (source code, and library executable) is still licensed under LGPL License. Including it with an application licensed under a proprietary license doesn't mean to relicense the library.

alpapan’s picture

As far as I know, the license doesn't apply only to the source code, but also to the executable. If it would not be so, then I could sell a GPL program as it would be mine, under a private license.

What does GPL have anything to do with this? You're confounding two separate issues. Yes you can sell your own program as yours if it has LGPL components. And legally speaking, yes you are relicensing LGPL component (as a static library, not the original source code). I'm sorry if that doesn't fit your expectations but that is the difference between LGPL and GPL and it's not my job or obligation to try to change your personal opinion.

Because I'm not interested in having a philosophical discussion

The issue is can one include LGPL code in a non-LPGL program. And the answer is yes, absolutely; that is the purpose of LGPL. That contrast to your earlier claim that including LGPL code forces the including program to also be LGPL.

so before you reply, please consider the context of this discussion. Can I include LGPL icons in a GPL program such as a Drupal module. I and others say yes. I'm patiently waiting for your approval.

a

apaderno’s picture

I'm patiently waiting for your approval.

That's not correct; you are waiting for the approval of your CVS account, which can be approved from any CVS maintainer.

Let us remember that the discussion started because you were saying that Drupal modules could be licensed under LGPL, which is not exact, as Drupal modules are linked to GPL code (Drupal). If I am using a GPL library in my code, then also my code is automatically under GPL License. End of the discussion.

About the images, somebody already replied that we prefer to have GPL files in Drupal.org repositories; in any cases, files available from third-party sites should not be committed in Drupal.org repository, which should be a repository for Drupal modules/themes/installation profiles.

alpapan’s picture

No, the discussion started because you rejected LGPL images because they were GPL and not LGPL. I /suggested/ that perhaps I could then make the module LGPL and you correctly said no (and why) and I didn't disagree with that.

The issue is purely on images (feel free to read back).

Yes Drupal CVS /prefers/ GPL but it is not illegal or wrong to include LGPL. Actually it is good to include them and not have to make our own.

Further the 3rd party site argument is purely on something users can download and simply extract. In my case I use 3 images of a large set and recoded then in another format. So if these were GPL images, they would be allowed.

I request that the LPGL images i have now removed from my module are similarly allowed.

thanks.

apaderno’s picture

See comment #46 where you say:

Say I wanted to release my module under LGPL (in another repository such as google code) because I find GPL too restrictive, but I would still want to tap into the update notification function. How could I do that / is there any precedent on doing it? For example, could I create a dummy Drupal module which requests to download the source from another repository (and why one has to do that) and I update it's version on drupal.org when a new version is released?

The discussion about differences between GPL, and LGPL started from there (to notice that you are not talking of icons, but module, which for me means principally code). About LGPL license, it was zzolo to report that the images where not licensed under GPL. For what it can matter, I agree with him that in Drupal.org repository we prefer to have GPL licensed files. Is LGPL illegal? No, it isn't; as it is not illegal to choose what we prefer to see committed in Drupal.org repository.

alpapan’s picture

Thanks kiamluno, my bad

sorry,
a

zzolo’s picture

Status: Needs review » Fixed

Hi @alpapan.

Yes, I do know about diff. And yes, it would be helpful, but I would still have to review the whole thing as I may have missed something that was bad before anyway. If you want to provide a diff with your new module submissions, that would be welcome and helpful.

If you are concerned about testing changes, feel free to write SimpleTests for your module as it will make development much more efficient and more stable.

I have approved your CVS account. Thank you for all your patience and understanding through this process. I know it has taken a while, but I hope that you have learned somethings along the way and understand the Drupal community better.

When creating this project on drupal.org, make sure to note all the specifics to the module on the project page. Your module has some limitations that most users would not be aware of right away and it is important to tell them about it right away. A README.txt is a great failsafe but most users don't won't read it until there is a problem.

Please read the following resources to make sure you know how to use CVS and the specifics to the Drupal CVS infrastructure, as well as how to be a good module maintainer on Drupal.org. The Drupal community is very large and dynamic; we welcome you as a module maintainer and hope that you embrace and challenge the Drupal community and continue to contribute.

--
Note: Please be patient with the CVS application process. It is all done by volunteers. Our goal is not to be arbitrarily slow or meticulous. Our goal is to get you CVS access and ensure that you are and will become a more responsible Drupal contributor. For a quick reference on what I look for in a code review, please see this article.

alpapan’s picture

Thank you for your time.
Currently buried with work so it may take a few weeks until I get round to it.
Simpletests are an excellent idea but may take longer than testing it de-novo each time.

ta
a

Status: Fixed » Closed (fixed)
Issue tags: -Legal, -Module review

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

apaderno’s picture

Component: Miscellaneous » new project application
Issue summary: View changes