Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#52 | genes4all_drupal_0.9.tar_.gz | 113.06 KB | alpapan |
#37 | genes4all_public_0.9.tar_.gz | 137.9 KB | alpapan |
#27 | genes4all_public_0.9.tar_.gz | 137.56 KB | alpapan |
#25 | genes4all_public_0.9.tar_.gz | 138.25 KB | alpapan |
#18 | dbsf_public.tar_.gz | 96.21 KB | alpapan |
Comments
Comment #1
alpapan CreditAttribution: alpapan commentedPlease find it attached. Please note it needs a Postgres database.
thanks and happy new year
alexie
Comment #2
alpapan CreditAttribution: alpapan commentedSorry,
network from home had been consistently bad.
Here it is again.
Comment #3
alpapan CreditAttribution: alpapan commentedDarn, old version. Here is the proper one...
Comment #4
alpapan CreditAttribution: alpapan commentedAnd final oops: uninstall bug fixed.
a
Comment #5
apadernoComment #6
alpapan CreditAttribution: alpapan commentedHello
Thought I could beg for an update?
thanks
a
Comment #7
apadernoAs 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.
Comment #8
alpapan CreditAttribution: alpapan commentedDBSF (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
Comment #9
alpapan CreditAttribution: alpapan commentedCurrent stable version attached.
thank you
a
Comment #10
zzolo CreditAttribution: zzolo commentedJust 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.
Comment #11
alpapan CreditAttribution: alpapan commentedThanks
I'll start updating it later this week.
Comment #12
apadernoComment #13
alpapan CreditAttribution: alpapan commentedDear 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
Comment #14
apadernoSee 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.
Comment #15
alpapan CreditAttribution: alpapan commentedDear Kiamlaluno,
Note that
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
Comment #16
alpapan CreditAttribution: alpapan commentedHere is the version without the MIT-licensed dynatree.
thanks
a
Comment #17
apadernoSo 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.
Comment #18
alpapan CreditAttribution: alpapan commentedSome more up to date code attached.
thank you
alexie
Comment #19
zzolo CreditAttribution: zzolo commentedHi @alpapan, nice work. Since you have split the modules up into two distinct ones, can you choose just one to review? Thanks.
Comment #20
alpapan CreditAttribution: alpapan commentedHello
I guess I choose "genes4all". How may I get a project for "dbsf"; shall I make a new application?
many thanks
alexie
Comment #21
zzolo CreditAttribution: zzolo commentedTo 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.
Comment #22
zzolo CreditAttribution: zzolo commentedFor these requirements, as well as for the memory requirements mentioned in the README.txt file, you should use hook_requirements().
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.
Comment #23
zzolo CreditAttribution: zzolo commentedComment #24
alpapan CreditAttribution: alpapan commentedHello
For images, would a LGPL instead of GPL be allowed or would I have to contact the author?
thanks
a
Comment #25
alpapan CreditAttribution: alpapan commentedHello
* 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
Comment #26
zzolo CreditAttribution: zzolo commentedAs 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.
Comment #27
alpapan CreditAttribution: alpapan commentedThank 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
Comment #28
alpapan CreditAttribution: alpapan commentedHello
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
Comment #29
zzolo CreditAttribution: zzolo commentedImportant things:
Minor:
Overall real close. I would say this should be good to go next time around.
Comment #30
alpapan CreditAttribution: alpapan commentedHello
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
Comment #31
alpapan CreditAttribution: alpapan commentedOne 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.
Comment #32
apadernoThe 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.
Comment #33
apadernoI 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.
Comment #34
zzolo CreditAttribution: zzolo commentedAbout $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.
Comment #35
alpapan CreditAttribution: alpapan commentedsee http://gmod-dbsf.googlecode.com/files/genes4all_public_0.9.tar.gz as mentioned
a
Comment #36
apaderno@alpapan: You are supposed to attach the new version of the archive here (see the other applications).
Comment #37
alpapan CreditAttribution: alpapan commentedthere must be some fancy automated system that takes advantages of attachments i guess
here
a
Comment #38
zzolo CreditAttribution: zzolo commentedIn genes4all_autocomplete.inc (please note the usual standard is genes4all.autocomplete.inc):
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.
Comment #39
alpapan CreditAttribution: alpapan commentedThe {} 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.
Comment #40
zzolo CreditAttribution: zzolo commentedSorry 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.
Comment #41
alpapan CreditAttribution: alpapan commentedHello
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
Comment #42
zzolo CreditAttribution: zzolo commented@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.
Comment #43
alpapan CreditAttribution: alpapan commentedTarball
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
Comment #44
apadernoLGPL 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.
Comment #45
alpapan CreditAttribution: alpapan commentedHi
You're correct.
I asked him to dual license, otherwise I'll remove the image directory from the next distribution.
many thanks
a
Comment #46
alpapan CreditAttribution: alpapan commentedOne 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
Comment #47
apadernoThe 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.
Comment #48
alpapan CreditAttribution: alpapan commentedThanks 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
And Section 5
and most importantly section 1
Further
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...
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
Comment #49
apadernoAny 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.
Comment #50
apadernoThe LGP License reports the following sentence:
The GPL License reports the following sentences:
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.
Comment #51
alpapan CreditAttribution: alpapan commentedHi 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
Comment #52
alpapan CreditAttribution: alpapan commentedDear 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
Comment #53
alpapan CreditAttribution: alpapan commentedComment #54
apadernoApart 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.
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.
Comment #55
alpapan CreditAttribution: alpapan commentedHello 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
Comment #56
alpapan CreditAttribution: alpapan commentedDear 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
Comment #57
alpapan CreditAttribution: alpapan commentedDear 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
Comment #58
apadernoIf 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.
Comment #59
zzolo CreditAttribution: zzolo commentedHey @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.
Comment #60
alpapan CreditAttribution: alpapan commentedI'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
Comment #61
alpapan CreditAttribution: alpapan commentedHello
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
Comment #62
apadernoAs 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.
Comment #63
alpapan CreditAttribution: alpapan commentedWhat 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
Comment #64
apadernoThat'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.
Comment #65
alpapan CreditAttribution: alpapan commentedNo, 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.
Comment #66
apadernoSee comment #46 where you say:
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.
Comment #67
alpapan CreditAttribution: alpapan commentedThanks kiamluno, my bad
sorry,
a
Comment #68
zzolo CreditAttribution: zzolo commentedHi @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.
Comment #69
alpapan CreditAttribution: alpapan commentedThank 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
Comment #72
apaderno