Closed (fixed)
Project:
Drupal.org customizations
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
22 Mar 2007 at 10:39 UTC
Updated:
23 May 2014 at 18:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
bertboerland commentedas per IRC:
"[12:25] bertboerland: your request should have been against project.module methinks.
[12:25] will change
[12:25] bertboerland: or maybe we need a drupalorg.modulel where we could form_alter such stuff away.
[12:25] bertboerland: put ^^^ in there"
lowering prio as well
Comment #2
boris mann commentedI wouldn't want to remove the option from the generic project module. Maybe time to build a drupalorg.module and put in some form_alter functions to override various "stock" items?
Comment #3
dwwyeah, drupalorg.module has been needed for a *long* time... ;) i'm all in favor.
that said, i'm also all in favor of ripping these fields out of project.module and using CCK-defined node types for project nodes. each site should be able to define whatever makes sense for their kinds of projects, instead of all these crazy hard-coded fields.
i know 5.x CCK (contrib) can already add fields to any node type, not just CCK-defined types. however, i doubt that's going to fly on d.o. yet, i'm happy to rip out fields we don't want now, and encourage other sites to just use contrib CCK to put back in (or add) whatever they want in 5.x, an we can reconsider a more thorough cleaning in 6.x, once core has CCK field support (i hope).
Comment #4
killes@www.drop.org commented*aol*
Comment #5
dwwsorry killes, what does "*aol*" mean? ;)
Comment #6
killes@www.drop.org commentedOh dear, what has the world come to , when computer nerds don't know what *aol* means...
http://www.catb.org/~esr/jargon/html/A/AOL-.html
Comment #7
aclight commentedThe CCK part of this is a duplicate #85049: convert project* to CCK.
However, now that the drupal.org module actually exists, this could be done. Since #218571: add hook_project_page_link_alter(), implement to add security link to all project pages got in, the drupal.org module could just implement hook_project_page_link_alter() and do an unset($links['license']) to prevent display of the license on the project page. This, in combination with implementing hook_form_alter() to remove the field from the project edit page, would solve the problem. I'm moving this into the infrastructure queue so that if people are interested they can take this up over there.
Comment #8
aclight commentedWhoops...wrong queue.
Comment #9
pwolanin commentedwe could maybe also set the default license link (which is now never displayed) to: http://drupal.org/node/7765 if someone could make a nice alias for it.
Comment #10
aclight commentedI wonder if we should link to a page on our own site instead of the gnu.org site. What if they happen to change the URL or something like that.
Also, maybe we want a db upgrade as well that sets the value we decide in the database so that projects already created are consistent with new projects.
Comment #11
pwolanin commentedempty string?
Comment #12
pwolanin commentedbump?
Comment #13
Crell commentedaclight asked me for a legal opinion here. Here is my legal opinion:
1) Anything in Drupal CVS is GPL, period, so module authors should never be able to set a license.
2) Anything already in CVS is either under the GPL or must be removed. I'm not sure if we should wipe that data, however, before checking it to see if anyone is claiming a non-GPL license (or a specific version of the GPL, which is also bad). Can someone with database access check and see what the current status of that column is before we blank it? Do any modules actually use it, and do any of them point to a non-404? Do any point to a non-GPL link? If so, I need to know that so I can go hunt them down and, er, "correct the situation". :-)
3) I do not believe a license link is required, but a centrally-controlled one is OK. However, were we to include one it should point to http://drupal.org/LICENSE.txt specifically for the time being, since that file we have control over. At some point in the future we may put up a better licensing page/faq on the site, at which point the link should probably change to point to that instead.
So +1 on this patch, *after* we've confirmed the current status of modules that are using that field when they shouldn't.
Comment #14
pwolanin commented@Crell - any progress in looking into this?
Comment #15
Crell commentedPer discussion with killes, the attached patch will remove the License field iff it doesn't already have a value. That lets us remove it for new projects while we go through and nix the others, and they all go back to this default. And all will be right with the world.
Comment #16
gerhard killesreiter commentedComment #17
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.