Contributed modules and themes policy

We've had several issues of bad behavior when it comes to contributing modules and themes recently:

Naming or renaming a project to start with '000' or 'aaa' in an attempt to game the alphabetical project listings so their projects are always listed first.http://drupal.org/node/484044

Using theme-generating programs like Artisteer and creating/mass-creating themes on drupal.org that are unlikely to be supported since the creator likely doesn't understand how Drupal theming works since they used a Point-n-Click program and never put any work into the source code.http://drupal.org/node/526194

Themes hosted on drupal.org that have common features disabled/crippled unless the users goes to the creator's webstie to pay for the full version.http://drupal.org/node/501364

We really need to come up with some concrete policies that we can point to when projects follow these behaviors. What would be even better is if we actually have a moderation queue for new projects so we can catch these things (and things like obvious security isseus) before they even get released to the public. For that, see http://drupal.org/node/484034.

Comments

Point #3 needs some re-wording to indicate glue modules (those that integrate a 3rd party paid-for service, like credit card integration) are fine.

Project names cannot start with a number. Besides gaming the alphabetical listing, an additional reason why numbers shouldn’t be used at the beginning of the project name is that PHP doesn’t allow function names to begin with numbers, so you wouldn’t be able to write any module, theme or preprocess functions for a project named that way.

Project names cannot start with letters or numbers that have the appearance of making the project appear first in the alphabetical listing of projects. This means no projects named “Aardvark” or “A1 Theme”.

No crippled or partial themes. A theme or module must be fully functional and must not require additional paid-for code to unlock the full functionality.

I would think this would be okay, as long as the version of the theme provided on drupal.org included all necessary GPL'd material (e.g., fonts, images, etc.) in order to fully function, and that the screenshot didn't include any material only available commercially.

But certainly, I don't think there's a problem with telling folks they can go to the author's Web site to buy a version of the theme that includes commercial-grade imagery or typography.

How about for #3 that the theme must be fully functional and look just as the screenshot / demo advertises with what is availble for free on Drupal.org? We could allow one line to say something like "additional features, variations, and paid customization available at whatever.com". This would ensure that what is being hosted is completely usable as is but also give them the chance to make a little money by offering extras above and beyond the base theme.

Mainly depends on what can be automated and what is the need in manpower for the manual checks

for #2 This point is I think about documentation, maintenance and support

What is the use of not adequately documented or maintained modules and themes in the repository?

Documentation, support and maintenance of themes and modules should be considered in allowing projects to exist in the Drupal repository. Project should have adequate documentation. Set minimum documentation requirements for projects to be released.

The issue queue should be maintained.
Maybe something can be done with the issue queue statistics here, amount of open issues against total amount of issues. The issue statistics are there but I don't think a lot of users look at it.
I mean users still use modules which have 75% open issues or bug reports.

I am sure some will say that this requirements will make it more difficult for developers making contributions to Drupal. I think it will and I think it's better to have well documented and maintained modules than modules thrown over the wall. Most (new) users of drupal don't see the difference, try out these modules, ask questions and don't get a response.

I see some Drupal developers with more then 10 modules to maintain. It's great they contribute that much to Drupal, but I can not see how they succeed in maintaining them. They only can succeed by letting other developers maintain some of their modules or by having co-maintainers. Popular modules should be adequate maintained otherwise (new) users will walk away.

for #3 I think it's difficult to define: Is it a crippled module/theme or a module/theme with additional functionality available? I made this list of kind of modules and themes that are now in the repository (I don't think it is complete, I had examples for each group but deleted them to not pinpoint particular projects.), but for me it gives a better understanding about what is allowed.

Modules or themes with additional commercial functionality. (ok, like...)
Driving trafic to commercial Sites/products with contributed modules and themes is done at Drupal.org (A lot will follow)
I think this will be more common in the future.

Modules and themes which have full functionality, but limited in the amount of usage (commercial if it is used for more users) (ok, like...)

for #3 I think it's difficult to define: Is it a crippled module/theme or a module/theme with additional functionality available?

A theme hosted on Drupal must be completely functional, and not have some parts that are enabled after the user paid the author. This means that the user interface must not have disabled parts, and there should not be any code executed only when a license key file is found (or a similar blocking mechanism allow the code to be executed).

I think it's absolutely fine that we have modules or themes with commercial elements. My main problems is if you download a module or theme that has a bunch of cool features on the project page, only to realize that they're all grey-ed out or disabled until you pay for the 'plus' version. Things like this need to be disclosed ahead of time on the project page so our end-users can research this before downloading.

Just to add that I switched to Drupal from Joomla!, partly as I felt Joomla was besieged by extras requiring payment; and even a few in which there were sneaky things like hidden links to authors' sites. Perhaps somewhat belatedly, I think there was effort to clean things up, by requiring a certain licence: greatly upset various developers, but maybe for better.

Yes, it's fair enough that people create add-ons they charge for; but I also think, to some extent, not in spirit of open source, and not in spirit of Drupal to date.
So, drupal.org doesn't have to host them [seems the intention is to host free extras].

And indeed, where "free" add-ons are aimed at making sales, perhaps as Devavrata theme - which led me to this thread; I've seen Dev creator admitting he'd created free theme as teaser for his paid for versions - would seem best to remove. Subjective, of course; but a degree of policing important. Maybe complaints can help, as flags for potential trouble, tho again could be abused.

Here's the theme in question about problem #3. Having a theme with 80% of it's feature disabled until you upgrade to the 'paid' theme is not appropriate. The theme should just not have options for those settings and there would be no problem.

Drupal won't have the same issues as Joomla! since drupal.org has never allowed the posting of modules or themes that aren't 100% GPL-compliant. Joomla! used to allow proprietary extensions and themes to be published on their site, including those with crippled functionality. That's changed now, and as of the first of July, everything in the Joomla! Extensions Directory is fully GPL-compliant.

Trying to post crippled themes or modules on drupal.org is an exercise in futility anyway, since there's nothing preventing anyone from taking the code that's been released under the GPL, fixing it so it's no longer crippled, and then re-releasing it. Of course, then you'd end up with confusingly similar modules/themes all over the place, which is part of what we're trying to avoid here.

I understand your concern. The reality on Drupal.org is that all kinds of related services to modules and themes are put on the project pages, without telling people they have to pay for that. If you have examples like that people will follow them I am afraid.

I don't see how to avoid this and if Drupal.org puts rules in place I don't see how you can control this without using a lot of manpower to review all the project pages and also posts of people.

No themes that are simply made of image, CSS, and JavaScript files (apart the .info file).
To be a Drupal theme, it should have at least a template file; differently it's just a set of files you could easily obtain in many ways. Just to make an example, I could use an HTML editor to create a HTML file using one of the template it has, change name to the files it created, add a .info file with the right name, and I would have a theme I could upload on Drupal.org. Doing so, I could create a dozen of Drupal themes.
Maybe I would need to change the CSS classes originally used; the point is that I would pass as Drupal theme something that is not even thought for Drupal (otherwise I would have read the API documentation to understand how Drupal theme system works).

This doesn't make sense to me. In fact, one of the touted features of D6 was to be able to create CSS-only themes. While I understand where you're coming from, I don't think it sends the right message. Perfectly wonderful themes can be made with just CSS and an info file, and presence of a template file does not a good themer make :)

What is about themes whose name is something like "A day of November"?
Such a theme could be simply named "November day", also because it is doubtful that the short name will reflect the full name (it's more probable that the short name would be something like "november_day".

In answering this specific situation I'd consider: No usage of prepositions.
Thus covers any oddities that would occur with an, or, but, the ... and so on and so on.

if it's to be done, I suppose it should be done in a way that attempts to cover as many bases as possible including but not limited to, profanity.

My feelings on this initiative though are in a very gray area. I may be in the minority here but, I feel, people should be able to name their themes what they want. Especially if they are giving a design away. In my eyes it's an altruistic behavior that should at least be unrestricted if not rewarded.

That said, I'm on the fence about how much freedom should be taken away with regards to designers developing a theme and giving it to the community at large, or developing a module for that matter.

I may one day want to use a theme someone worked hard on but long before hand had chosen its title as An African Safari, or Aardvark which was already mentioned. What about other languages? There's bound to be words out there that may one day be used as themes that may have a legit reason for Aa, or Bb. :)

I also understand how the top of the list of themes, sorted alphabetically, can be abused or taken advantage of. I call it the phone-book-leap-phrog method of advertising. I tend to read the phone book from the back to the front and have for years. The Z's get lot of my business.

I would try and gain an idea on how active the alpha sort module listing is. How often are people using this method?

Why you ask?
Using an analogy, If you take the carrot out of the jackasses sight, the jackasses stop.
My thinking is if you take away the perceived prize than there is nothing to compete for but having a great design. It getting attention by spreading through word of mouth, word of fingers and last but certainly not least .... usage.

Now, before those who use the alpha search get all riled up, let my just say that I don't personally use the alpha sorts ... ever. So it's easy for me, to throw to the wolves a feature I don't use. However, I can't recognize what is important to others. Including what may be important to them when naming a project on drupal.org.

The usage of numerals as the first characters in a project name, I grasp totally as its got the ability to cause issues with the code base itself when it comes to functionality and documentation.

A little peave of mine used to be that what I download is often titled differently than the project page is named. This used to confuse me. A recent peave of mine are when blatant advertising is used on the project page title: project name (snakeoil here ... get your snakeoil).

:steps off soap box:

in envisioning the future: (with the proper dedicated manpower)

I like the idea of a moderation queue/revision queue but this would require
A) getting it in place and
B) maintaining it.

Is there enough dedicated human power now to warrant it being specified for the redesign?

maybe a contrib theme Q&A team would be interesting group to work on/with. I'd think it would be a nice, entry level group initiative on drupal.org. Last year myself and another user, jwolf went through the themes and installed them took screenshots for themes that had none. I can only imagine the huge undertaking a Q&A initiative would be on already existing themes alone. However, in the end I do believe the work would be worth it for the entire project.

Edited multiple times by: VM; to ensure I was conveying my thoughts clearly.

Yes, excluding specific words from project names is a lot more gray area than numbers since we don't have a good reason besides "you're probably wanting to be listed first". I really like the idea of default sorting by project activity so that abandoned modules get sorted down and actively maintained things get the promotion. But it's likely something we're not going to see happen until the redesign. I'm thinking that this will be too gray of an area for now to make anything happen.

While using "AAA Cool Theme" to get to the top is annoying, an annoyance is all it is. I'm not too fussed about it. Let's not try to make rules about how they are named just to avoid gaming the system, which kills legitimate uses at the same time.

CSS only themes are fine, but they should include the possibility of adding functions, which means no themes that start with a number because PHP does not allow functions to start with a number.

Themes should be complete as uploaded. Saying there's more things you can add to it for a cost at another site or that the maintainer is available for customizations is fine, but the theme on drupal.org should give you everything in the description and screenshots and be complete and usable as is with no greyed out features.

Too many rules is just going to encourage people to not bother. Let's keep it simple.

I agree with Michelle's comments; the "no themes beginning with a number" rule makes sense to me, as it can have technical repercussions. Even if the author doesn't initially intend to add PHP functionality to the theme, there's nothing preventing that from being added in the future.

My feeling about theme names is that this is really an IA problem with the drupal.org theme directory; i.e., themes probably shouldn't be sorted alphabetically to begin with, as it's not particularly useful to users. I'd rather see the current theme directory replaced with an interface that allows users to search/sort by category instead of by name. For example, I should be able to say, "I'm looking for a Drupal 6 compliant theme that uses a CSS grid system designed for fixed-width 1024x768 displays", or "I'm looking for a Drupal 5 theme that has a fluid three column layout", and have selectors that allow me to filter all available themes using those criteria. Hopefully this is something that will be accommodated with the new design.

In the meantime, we could simply change the default sorting on that page from "Title" to either "Creation date", "Last release" or "Usage statistics" and the placement advantages of having a theme named after aardvarks or the German town of Aachen would immediately disappear.

Yes, searches by theme functions would be best. I favour fluid themes, so search for these.
Improved theme search would be very useful, esp now numbers of themes mushrooming.

Good re GPL compliance; would be kind of funny to see someone un-cripple a theme, then upload. Devavratabellsandwhistles, say.
Tho yes, crippling some features might be ok at times (not so sure tho), but should work as promoted.

Sorry I'm late to this thread-- but having read all the comments this is how I see the consensus shaping up:

First, we need to change the default sort of the themes page to something other than alpha. Either create date (my preference) or usage statistics. It's much easier and faster to do that than figure out all manner of rules to prevent users from gaming the system.

Also, if we use create date, it needs to be the actual create date of the project node and not another date or we'll have people constantly resaving project pages or creating releases to get bumped to the top of the list which is basically what we have now with names.

As for the rules, less is more, lets keep it simple. Something like.

theme names cannot start with a digit.

the theme as published on drupal.org must be completely GPL (including all images, fonts, features, etc.).

the screenshot must represent the theme exactly as released on drupal.org.

no artiseer/auto-generated themes are permitted.

the theme cannot be crippled in any way, shape, or form.

a mention of available commercial features with a link to the authors site is perfectly acceptable (but below the teaser).

What say you all? Does that capture the consensus?

I know the tendency these days is to put off everything to the redesign, but, imo, creating a handbook page and changing the default sort order of the themes page are both simple and fast and should be done asap.

That all sounds good to me. I believe there's an issue in the queue for changing the sort. I believe it will actually take coding, not just a UI change, but I'm not 100% sure.

Your list sounds fine with a couple minor nits:

I'd change to number 4 to add "unless substantially modified". I know that opens up more potential problems than just forbidding them completely but I've played around with artisteer a bit and it can get you a nice start to modify, which really isn't much different than taking an existing theme and modifying it. I would hate to have someone spend 10 hours making an artisteer theme into something unique and then think they can't contribute it because of how it started.

Number 5 I'd add "including greyed out theme settings that need a paid upgrade to activate." just to make it very clear that that is considered crippled as well.

As a graphically challenged individual, I happen to like artiseer myself-- I was just thinking about the day we recently got spammed by 27 artiseer themes from the same person in a matter of minutes. We don't want to become a dumping ground for cookie-cutter themes, though I'm not exactly sure how to draw the line.

Probably I am late and sorry if this is already settled. I got referred from a d.o issue where I wrongly posted.

Here's what I had to say -

I have always wondered about this, get to start your project name with 0 or a, and you are at the top of the list irrespective of HOW actually the theme is or what it does.

The http://drupal.org/project/themes is the most visited page for us to see or download themes.
It should be
random sorting every time I see the page
+/- a top sticky for the most recent 2 or 3
+/- any rating system like top downloads (but this is probably not d.o policy)

Why random or something like random is important is because in theory the 'zero' game can be applied to the top alphabets too, what if I name with a or persistently with b ? I always remain in the first page.
A random sorting can be instantly applied now by d.o - it does not need upgrade or a new look site to come. Probably the restriction in naming, except the php-technical ones, can be lifted off then too.

In the other thread it was said "The 960 Robots and 960.gs Fluid themes were not found in violation" - while this may be true I find the top-place "spamming" can still play VERY well, for example, I can first create and publicize some grid or xyz system in a website called 217.com, then bring a theme 217 xyz with a short project name twohundredseven, which starts with a much later alphabet 't' and yet can persistently occupy the top places in the list.

Rules are to made by foreseeing all these, otherwise silly things (like accusition of 'changing rule in the middle of the game') will keep on happening.

An order that is not alphabetic should be the default used one, but the users should be able to change the used order (and change it to alphabetic if they are looking for a theme, but they don't remember the exact name).

Rather than a purely random order, it would be better a list that show first the most downloaded themes.

@Worldfallz, this has the problem that some theme will persistently occupy top position just because they were created late, while those themes that were created earlier (even if they are better) will persistently be out of view from the first page. Ideally the list should be random.

I'm good with random as well, I just thought "create date" would give every theme a bit of visibility when first published. Sort of like highlighting new stuff. As long as the sort can't be gamed, I guess it really doesn't matter much.

First thing I do is go sort on creation date when I go to that page. I want to skim down and see the new themes. I think that's a perfectly reasonable sort order. Gaming the system is really pointless anyway. This isn't like locksmiths where you just pick the first one you see. You're going to keep going through the themes at least until you find one you like, and more likely all the way to the end to see all the options. By the time we get so many themes that it's just not practical to skim through the thumbnails on all the pages, the redesign will be done and we'll have better sorting options anyway.

At least until we can get some better search/sorting options implemented for themes in the future, I would have no problem with sorting by creation date, with the newest first, as an interim solution. The only way I can see that this could be gamed is if it were possible to change the creation date or put the creation date at some point in the distant future.

In any case, the page should probably also explicitly state that themes are sorted by creation date, and that if you want to sort by some other criteria to change the options in the right-hand column (this isn't immediately obvious to new users with the current design)

I just thought "create date" would give every theme a bit of visibility when first published.

@Worldfallz - that is why I suggested random sorting every +/- a sticky for the most recent 2 or 3

Gaming the system is really pointless anyway.

@Michelle - the basic issue, I am afraid, arose from that - not because of 0 disturbing function names.
Users will search till they find the one they need - its true. But that should not be reason that theme name with 0 or a or b should persistently be present at the top in a hard coded list.
Any commercial firm may come up in future, particularly when commercialization of Drupal is on a big way, who can release themes every other day with names starting with a or b ( one fully functioning theme and rest their company link to blah blah). Similarly they can use the 'create date' to monopolize too, unless Random comes into play.
The issue which lead to this thread was never thought of before, it is best to foresee even if it seems absurd at the onset.

I'm not saying people won't try to game it. I'm just saying it's really pointless. And the only way you can game the "create date" sort is to keep releasing new themes. As long as they're decent themes, that benefits us anyway. If they aren't decent themes and they're just releasing garbage, they need to be dealt with no matter what the sort is. Even random sort could be gamed by releasing so many themes the odds favor yours coming up first.

"Even random sort could be gamed by releasing so many themes the odds favor yours coming up first."

Random sort is not just based on the criteria of theme name but also who the release-ers are. It should take that into account just like arguments, filter and sort orders in Views.
In any case Random sort offers the POOREST chance at gaming.

Random sort would simply pick a random project node out of the list. It has nothing to do with who released it. Having a lot of themes gives you a bigger percentage of the pool and therefore more of a chance of being picked.

My preference is by created date so you see the newest themes when you go to the page. I really don't care all that much, though, since it's not that hard to click "Creation date" in the block. I suspect most folks who visit that page more than once do the same, so it would be one less page load to have it start out that way.

The problem with that is it can be easily gamed as well by simply resaving / committing the same code over and over. Personally, I favor create date for the reasons Michelle already gave, but I'm ok with random as well if there are strong feelings about it.

You divide the page into two panels ( which one will be wider or whether 50% each can be debated )
In one panel you sort by random so that every time people visit there are better opportunities to showcase by all the theme makes. A theme maker who has been inactive for a year may offer the best theme for an usecase :)

This is way beyond what we are talking about here-- which is an interim solution until the redesign is done. The module and theme pages have already been completely redesigned as part of that effort-- there's no need to attempt that here in a strictly temporary solution.

The next question becomes-- who do we need to talk to in order to get the current default sort changed? I'd hate to just open a ticket in the infrastructure queue-- those guys have their hands full as it is so I suspect it would just languish there unnoticed for some period of time.

@Michelle - that post leads to this post, and this post leads to that.

Yes, after I added the link here, I went and linked that post to this one. That way both sides of the conversation can find each other. That's fairly standard practice when the same discussion is happening in two different places.

Can you summarize it in a webmaster's issue? If we can get blessings from some of the higher-ups like killes or dww, that should be enough, I think. I was actually going to do that, but my computer time has been very sparse and will be until next week.

I'm also not sure about this statement, which I'd like Larry Garfield to take a look at: "By using the repository to host your themes, you agree to the terms of use as set forth on this and other drupal policy handbook pages." I know Larry's on vacation for the remainder of this week, but he can probably take a look at it next week.

Hosting themes on drupal.org is a free service provided by the Drupal community. It is a privilege-- not a right. By using the repository to host your themes, you agree to the terms of use as set forth on this and other drupal policy handbook pages.

Theme names shall not start with a digit.
For a variety of reasons, theme names may not begin with a digit. The most important reason for this is that php does not allow function names to begin with a digit, therefore themes named with an initial digit will prevent users from using override functions in the template.php file.

Themes hosted on drupal.org must be completely GPL.
Although the GPL license allows for different parts of a theme to use another license, themes hosted on drupal.org must be completely GPL including all images, css, javascript, fonts, theme settings, etc.

The screenshot used on drupal.org must accurately represent the theme.
In conjunction with the previous guideline, all screenshots used as part of the theme's project page must represent the theme exactly as hosted on drupal.org and not another version of the theme available elsewhere.

Mass generated themes are not permitted on drupal.org without substantial modification.
With the advent of tools like artiseer, it is possible to mass produce drupal themes with minimal effort and little or no skill or knowledge on the part of the themer. While these themes are perfectly legitimate, there is no reason to host such mass produced themes on drupal.org. We realize this is often going to be a judgment call, but drupal.org is not sourceforge or github and is not the place to host mass produced code.

Themes cannot be crippled in any way.
In case the previous guidelines were not clear enough: themes hosted on drupal.org cannot be crippled in any way, shape, or form. Period. This includes "grayed out" theme settings or any other feature or functionality that requires separate a download or payment.

3rd party libraries and plugins are acceptable.
Occasionally themes, like modules, make use of 3rd party libraries or code maintained elsewhere (ie jquery plugins or css frameworks). This is actually best practice and not considered 'crippling'. A link to the appropriate download(s) should be included right on the project page.

Author links are acceptable.
As with any drupal project, a mention of available commercial features or versions, with a link to the authors site, is perfectly acceptable. The link or text of the promo should appear below the teaser.

My comment about naming issues to prevent alphabetical order races.
1) You'll start telling people names cannot start with digits,
2) The you'll add that themes cannot start with "A " something
3) Then you'll add that Aardvark and AAA are not valid.
4) Then you'll keep denying any name that will come on top?

I've seen a lot of this stuff in past and the solution is not a policy but a change in the website: why d.o. show themes in alphabetical order? Why alfabetical is better than some random sort? Just change this and people will stop using "aaa"/"000" names.

At the moment at http://drupal.org/project/Themes I see (long name a.k.a. title / short name a.k.a url/directory/info name):
0 / zero: this is a project I just created to understand the answer to this question (and give visibility to this group)
960 Robots / ninesixstyrobots: if the "digit" rule is for shorname this is ok (and also my "zero" theme) otherwise this is not ok.
960.gs Fluid / ninesixstyfluid: same as above
A Block / ablock: this starts with "A "..
and so on.

Furthermore: why, as project creator, I'm not allowed to publish and unpublish my own projects?

Please read all the above conversation and don't ignore it. We're not interesting in policing links like "Aardvark" theme vs "AAA" theme. They're perfectly valid. 960/960.gs is the proper name of the grid system that those themes are based on. That's perfectly valid. The original theme that caused this was a theme that used to be named "Zero point energy" (which is the proper scientific term) was renamed to "0 Point Energy" only to game the alphabetical system.

Yes, I seriously created the zero project. I didn't know that "making Dave Reid" happy was on the policy too :-)
It seems I won't be able to publish back my KeepItSimple theme, so I thought that a good name for a newer theme that I'll upload without CC dependencies would have been "0". "0" (and not "zero") gives, IMO, an idea of simplicity. The simpler thing I can think about, don't you agree? So "0" seems a good name for a minimalistic theme. Then I read about digits in names, but at the same time I saw that 960 was allowed, so why not 0? So instead of keep discussing policies I simply created the project so now we can discuss a real use case and not an hypotetical use case.

In my opinion this aready shown that currently the policy is not clear otherwise I don't understand why "960" has not been renamed to Ninesixty...

Yes, I'm disappointed with policies and community members trying to abuse of their powers in the name of policies, and when you try to understand who defines policy and who agreed with the policies and who act outside the policy you find that there is no policy :-)

And yes, I read all of the above. The "Aardvark" reference has been copied by the very first comment of this thread and I also referenced "text of handbook page" that is one of the latest messages (is this enough to prove that I read the whole thread or is there an exam I can take?)

As I write this "Damien Tournoud" (administrator on drupal.org) changed the "long name" for my "0" theme to "zero": WHY? WHY 960 is allowed to have a number and "0" can't be a number? Of course ATM I don't care of the "0" vs "zero" but this stuff can't be left to people that go around moving up and down and hide/show projects as they like.

So, will the policies discussed here useful or simply some people around with admin powers will do whatever make sense to them?

1) Well, instead of thanking me for spotting a bug you keep fighting me. I've always been a good bug hunter, but my specialties is Java.

2) The project description explain why I created the project. Testing the policy was not the main goal. My main goal is to publish a new minimalistic theme with a name I like to d.o. Instead of wasting years discussing the policy I saw that "960 something" theme and I registered mine.

What's the problem? Should I have thought that there could be a bug in d.o.?

I simply asked "WHY" Damien did something, and he nicely replied to my request explaining me about the bug I hit. Yes, at first I thought that Damien was simply applying some personal policy (and I'm sorry for this, but does thinking counts too :-) ), but I'm used to ask before coming to conclusions, and that's good!

You were aware of this thread and our efforts to get people to not start themes with numbers, including the title, and yet you did it anyway. That, to me, is trolling.

Please correct me if I'm wrong but what I understood was that shortnames shall not start with digits (because of php function namings) while fullnames can (and that's why "960 robots" is allowed.
As this "understanding" (short vs full) derivated from reading a lot of opinions/threads around maybe some of the policy makers here can update the handbook to better explain this.

the author intends to create a minimalistic theme named '0' but with the project shortname 'zero' which is perfectly fine according to our current standards.

Maybe the "handbook" is already updated but If I understood it correctly that document is "private" and cannot be publicly accessible until published, so take this answer as a warning about an "undefined" borderline case of the policy.

If I can suggest some more text to improve the policy (at least what I understood is your policy, not what I'd like to see as a policy) you should make it clear that you consider an "@import " in css or any other url based linking to a resource not included in the theme is not allowed (that's was one of my proposed solutions for keepitsimple, but IF I UNDERSTOOD, this is not acceptable for you, and I agree that this should be not allowed). This kind of rule would also protect drupal users from funky javascript included in themes (that could raise privacy concerns). E.g. The google analytics code to a theme is not something I would like to find in a theme I'm testing. WDYT?

I hope this make it clear that I don't care about the keepitsimple theme. I'd like to have it published because I think it is good for users and downloading a CC-BY-licensed theme is not a big issue from an open source phylosophical point of view. But I understand that a community like drupal needs policies, so if you really think that 3rd party FOSS styles not GPL2 complatible cannot be referred then I will simply make a reason and I will dedicate on spotting where, in my opinion, the policy was/is not clear so other contributors won't waste time.

As I find a lot of CSS styles distributed with the CC-BY terms (free to use, change and redistribute but you have to link back), see for example http://www.freecsstemplates.org/license/, I think it worth adding a comment to the policy. And if drupal theme "bridges" like the keepitsimple theme aren't/won't be allowed (take this as my last call ;-) ) maybe someone will dedicate to this "market" an external resource.

Having a module or theme shortname starting with a number is invalid as it is not a proper or allowable namespace since PHP functions cannot start with numbers. Adding a project with the shortname '0' caused major havok in the drupal.org CVS integration, and that was our fault for not validating that properly. It shall be fixed shortly.

I guess you are confusing things. My project had "0" as "Full name" (that I thought would be used only for the title) and "zero" as the shortname. So I didn't use digits for the shortname, and I simply did what I saw was allowed to the http://drupal.org/project/ninesixtyrobots theme (shortname with numbers, fullname with text).

2. Themes hosted on drupal.org must be completely GPL.
Although the GPL license allows for different parts of a theme to use another license, themes hosted on drupal.org must be completely GPL including all images, css, javascript, fonts, theme settings, etc.

I think it worth making it clear this statement. Strictly reading this only tell us that what is hosted in CVS must be GPL. But I understand this is not how you interpret the "rule". What you're trying to enforce is that the module itself must not reference in any way any "non-GPL compatible" resource outside d.o.

With this regard I think it worth evaluating the status of themes like Gutenberg: http://drupal.org/project/gutenberg
The published screenshot does not represent what you can see if you just download the theme. One of the linked sites do not exits anymore, the other links to Movable Type CSS with no specific license terms.

IMHO it is good for d.o. community to have such a bridge theme, and that's why I think that the policy should be written to allow similar themes to be kept in d.o. Furthermore I think that the current screenshot is much more useful than what you would get by not adding an external css (an unformatted page).

About the compatibility I agree and understand the CVS requirement of using only GPL, but this does not automatically means that non-GPL data from an external site is incompatible with GPL. This issue has already been discussed here: http://design.acquia.com/content/licensing-drupal-themes

Opinions? Is the principle already clear to anyone and just to be added to the policies, or is this something that should be better discussed in order to defined a good policy? Do you at least agree that this should be made more clear in the current proposed handbook?

One of the changes I'd like to make to the proposed policy is include a link to the Drupal.org Licensing FAQ, which governs all modules and themes hosted on drupal.org. The FAQ makes it explicitly clear that all contributed files hosted on drupal.org are licensed GPL v. 2 or later.

I don't see any problem with Eaton's Gutenberg theme with respect to this policy, except perhaps that the screenshot he's showing only demonstrates possibilities for the use of that theme, not the way that it appears out of the box. However, given that Gutenberg is not a "crippled" theme that requires users to pay money to use its functionality, but a fully featured theme designed to integrate with Moveable Type's theme markup, I think it is certainly consistent with the spirit of this proposed policy.

One of the changes I'd like to make to the proposed policy is include a link to the Drupal.org Licensing FAQ, which governs all modules and themes hosted on drupal.org. The FAQ makes it explicitly clear that all contributed files hosted on drupal.org are licensed GPL v. 2 or later.

Everyone agree on this. BTW you are right and it should be repeated in this handbook, so to not leave space to interpretation.

I don't see any problem with Eaton's Gutenberg theme with respect to this policy, except perhaps that the screenshot he's showing only demonstrates possibilities for the use of that theme, not the way that it appears out of the box. However, given that Gutenberg is not a "crippled" theme that requires users to pay money to use its functionality, but a fully featured theme designed to integrate with Moveable Type's theme markup, I think it is certainly consistent with the spirit of this proposed policy.

Well, I would like if the official rule was like you are describing it.
My theme as been unpablished because it was a bridge to a 3rd party free theme distributed under the free open source license named Creative Common Attribution License 2.5 (Aka CC-BY).
My theme was not crippled and you don't need to pay anything for use the free theme. You simply had to download a zip file from the original theme author. I simply created the "bridge" the same way Gutenberg did.
Please read this one if you don't believe that someone is unpublishing themes using different policies from that described here: http://drupal.org/node/416022

IMHO keepitsimple is even better than gutenberg because keepitsimple external theme is declared under a FOSS license while most movable type themes are unclear about the license, so you don't know if you are really allowed to use them and under what conditions.

Okay, that's a very long thread, and it looks like it's been commented on at length by some veteran members of the community, so I won't re-hash what they've already said, other than that it appears that the primary difference between keepitsimple and Gutenberg is that keepitsimple requires the use of an third-party non-GPL-compatible library in order to function, while Gutenberg is a fully-functional theme out of the box that enables Drupal users to drop in MT themes if desired.

In this respect, Gutenberg is a true "bridge" theme that works with a wide variety of MT-compatible themes, while keepitsimple is a crippled theme that only enables the use of a single third-party theme with the installation of a specific set of files from that third-party.

If you had created a theme that worked out of the box, and also easily enabled the use of any styleshout template with a Drupal site, then it would be more similar to what Eaton did with Gutenberg.

Ok, it's easy for me to change it so to not show any errors when the external theme is not downloaded. I don't agree about the usefulness of this policy wrt bridges, but if this is what will be written in the policy it is so easy to accomplish that it doesn't worth discussing.

...and also easily enabled the use of any styleshout template with a Drupal site, then it would be more similar to what Eaton did with Gutenberg.

How many themes should be bridged by a bridge in order to be allowed in keepitsimple? No one ever before said that the number of bridged themes is a key factor in the policy and no one ever argued about keepitsimple CC-BY-licensed theme was only 1 theme and not 2. I never tested other styleshoult themes, but I could even try to allow more than one theme. The fact that I'm not invloved with styleshould make not so much sense to me and I don't think this will improve d.o. user experience, but if everyone agree that the number of bridget themes is the key point then I'll take this and consider the solution. Do you care about the licensing of the bridged themes?
So, let me see the updated policy/handbook with this number explained, first, because it is weird to be hearing this stuff for the first time considering we are talking about "bridge themes" since hundreds of messages.

So, let me see the updated policy/handbook with this number explained, first, because it is weird to be hearing this stuff for the first time considering we are talking about "bridge themes" since hundreds of messages.

I was responding to your question earlier in the thread about what makes keepitsimple different from Gutenberg, considering that you believe both to be "bridge" themes. There is no specific policy (and probably never will be) about how many themes need to be "bridged" in order for a "bridge" theme to be considered a useful tool.

The point is, that with Gutenberg, Eaton created a useful tool that enables folks to use almost any Moveable Type theme on their Drupal site, regardless of how it's licensed. What you created was a theme that functions as a Drupal wrapper for a single non-GPL-compatible theme that needs to be downloaded from another site in order for your theme to function.

And while I know you're not doing that here, the problem is that allowing these kind of one-off "bridge" themes to non-GPL-compatible third-party themes could easily be abused by someone looking to use drupal.org as a way to get free advertising for their commercial themes. This is why we generally unpublish any "crippled" themes that require non-GPL-compatible code to function, regardless of what license that code is released under.

I completely understand and sympathize with the fact that, in this case, the code and images have a CC license and you're clearly not trying to profit off this theme. I hope that someday we can host CC-licensed themes on d.o, but I've discussed this with the folks who were involved in the creation of the current policies and I understand why that's not a reality at this time.

No policy is ever going to account for all use cases, and in those circumstances it's up to the site maintainers to make a decision based on their best judgment, and that's what they've done here. While I understand that you and others may feel differently, I do not see that decision as a judgment on you personally, but I also understand and support the reasons why it was made. If we've failed in any way, it's in not making those reasons more obvious and clear to everyone.

The point is, that with Gutenberg, Eaton created a useful tool that enables folks to use almost any Moveable Type theme on their Drupal site, regardless of how it's licensed.

So, if Gutenberg is not similar enough let me understand AllDrupalThemes BaseTheme: http://drupal.org/project/adt_basetheme
The screenshot show multiple shots, like Gutenberg, then I click on the first link and I land on a paid-for CSS styles. Then I clic on the second link and I land to a self promotional page to sell drupal services.
When I look for free themes on that page I only find themes unrelated to the ADT theme itself and some of them are under the CC license... so, is ADT published by mistake and simply have to be fixed or is it allowed as it is and in this case I'd like to really understand the motivations?

What you created was a theme that functions as a Drupal wrapper for a single non-GPL-compatible theme that needs to be downloaded from another site in order for your theme to function.

Again this non-GPL-compatable meme? please, can you read all what legal team already studied and declared about compatibility with regard to CSS+images ? I've linked this stuff multiple times but it seems you keep repeating this "non-GPL-compatible theme" that is simply untrue. Maybe the whole discussion is because some of you don't understand the difference between code and data in the license interpretations? (no offense here, I'm just trying to understand why this "false" compatability issue is written here again and again).http://design.acquia.com/content/licensing-drupal-themeshttp://wordpress.org/development/2009/07/themes-are-gpl-too/

BTW, back on the policy issue, if what you really want to prevent is business and promotional stuff in themes why don't you disallow linking sites with commercial services? Instead the policy explicitly allow this! Otherwise why don't you allow this kind of bridging themes as long as there is at least one external quality "Free and Open Source" style to be used?

My opinion is that the way keepitsimple is created and packaged is very good for d.o. users, but I would be happy to simply improve it if I could find someone telling me what can be made in order to make it more useful. You are the first one argumenting the number of bridged themes and this is weird. Everyone until today talked about non-existant issues. This "number of bridged themes" issues could even make sense to me but I'd like to be confirmed by others before I take care of checking if my bridge already works or can be adapted to be able to run also other styles from the same web design agency (styleshout). To my eyes this whole thing is about "bago proved that some member don't understand GPL, or they didn't even care about checking the CVS content, so this member are angry with bago and they will try to find any motivation in order to have their revenge". This, again to my eyes, seems no more about keepitsimple, but about bago. (but I still hope this is not the case, and that's why I'm here simply trying to understand the concrete issue)

I completely understand and sympathize with the fact that, in this case, the code and images have a CC license and you're clearly not trying to profit off this theme. I hope that someday we can host CC-licensed themes on d.o, but I've discussed this with the folks who were involved in the creation of the current policies and I understand why that's not a reality at this time.

So, you first say that Gutenberg is allowed to "break policies" because it's not promotional stuff and it is useful for the community, so judgement can override policies. Then, in the same paragraph, you say that you understand and sympathize with the fact that the "external stlyle" bridged by my theme is all FREE under a clear and know license. Yet, in this case is no more judgement and it cannot be published because of the policy. So, it seems it works like there is no policy.

Let me try something different:
Let's say I simply change KeepItSimple in order to not ask people to download an external style and simply put an @import in one css included in the d.o. package pointing to the keepitsimple theme expanded on my website. So every creative common resource is downloaded from my website for everyone using this theme. (This is similar to what is done by google analytics module when it "imports" the ga.js code, for example).
In this case the module would be fully functional, fully GPL compatable, and would require no action.
Would this be allowed? This is not disallowed by any point of the current policy/handbook. I don't like this too much, but if this is compliant with your policy I'd be happy to do this.

All of the members of this group are active members of the drupal.org webmaster's team, so it's not necessary to re-post issues here. Furthermore, the question of whether or not a specific theme should be unpublished is off-topic to the discussion at hand, which regards general theme policies.

All of the members of this group are active members of the drupal.org webmaster's team, so it's not necessary to re-post issues here.

I'm not in the webmaster team :-(

Furthermore, the question of whether or not a specific theme should be unpublished is off-topic to the discussion at hand, which regards general theme policies.

Yes, but we are evaluating specific cases so IMHO it is good to see that there are special override rules to the screenshot policy. IMHO it worth adding a statement to the policy so it will be clear what are the circumstances that allow a "drupal theme" to use a different image instead of a "screenshot generated on a empty drupal with some simple content and the theme just installed".
I'm not a theme expert so I don't know how many other themes are "special" with this regard, but it seems it easy to find more of them: http://drupal.org/project/adt_basetheme
So maybe they worth a policy "exception" or details about their requirements.

3rd party libraries and plugins are acceptable.
Occasionally themes, like modules, make use of 3rd party libraries or code maintained elsewhere (ie jquery plugins or css frameworks). This is actually best practice and not considered 'crippling'. A link to the appropriate download(s) should be included right on the project page.

bago's theme is allowed by this rule... the "css framework" is maintained elsewhere...

"It is not possible to distribute a module that integrates a non-GPL compatible library with Drupal, because it would be a derivative work of both Drupal and that other library and would therefore violate either the GPL or the license of the other library."

as far as I can tell #2 + #3 means themes with CC components cannot be hosted at drupal.org right off the bat due to licensing compliance, regardless of the other non-license items in the policy. If this is not true, all we need is an 'official statement' (ie from Larry Garfield or other member of the da) that CC is ok.

As has been said many times in relation to this issue, GPL compliance is necessary but not sufficient for hosting a theme on drupal.org. Just because a theme does not violate the GPL does not mean we are required to host it here. We're in the process of trying to codify what those other, non license related, policies should be. And let's be clear about something-- policies have been in effect through practice and fixed issues already. Themes get published and unpublished all the time with all sorts of reasons. This thread was started just so we could document what has been already been in practice in order to be fairer and more consistent.

This effort has totally gone off the rails. People are being forced to repeat themselves ad infinitum for what, appears to me at least, is no good reason.

I think we want a policy that encourages theme contributions but also protects the end user experience of those downloading themes (typically the less technical user) at drupal.org. I think the items we've outlined here do that. I think it's common sense.

As I've said before, if you have to argue in order to decide whether or not a theme is "complete" it probably isn't and shouldn't be hosted on drupal.org. If we want to become like all the other bait and switch sites out there (oh, you mean you wanted a steering wheel with that car?), then fine. Document it in this policy as being ok and lets move on.

HASS -- YOU NEED TO READ BEFORE YOU POST. You are dragging this issue on and on posting about things that have already been answered multiple times.

Without offense this apply to you too. You keep repeating issues about GPL compatibility. No one here ever wanted to distribute non-GPL stuff from drupal.org, no one is discussing this.

If you think that Gutenber theme is OK, then also KeepItSimple must be ok. Both requires an external download in order to show something "nice". Movable Type themes are not under the GPL. Most of the themes you'll find for MT are under an underfined license (no license text at all) and many are under the CC, too.

So, what do you mean by that link? it says "Occasionally themes, like modules, make use of GPL or GPL compatible 3rd party libraries or code maintained elsewhere (ie jquery plugins or css frameworks).". This states that external GPL and GPL-compatible stuff is allowed.
1st. it is known that the GPL-compatibility does not involve DATA (CSS-Images): http://design.acquia.com/content/licensing-drupal-themes
2nd: I don't think there is a requirement on the 3rd party licenses otherwise you would start not allowing the google analytics module to "import" proprietary javascript from google and similar things.

"It is not possible to distribute a module that integrates a non-GPL compatible library with Drupal, because it would be a derivative work of both Drupal and that other library and would therefore violate either the GPL or the license of the other library."

Useless for this discussion. No one wants to distribute a derivative work of GPL and non-GPL works.
If we are talking about licenses and compatibility than this is a non issue as IT IS even OK to distributed them together but here we are not even talking about distributing them together they simply can be used together, like any commercial theme can be used with drupal. If you want to talk about policies let's stop talking about licensing.

# Linked from faq #10 is the list of gpl compatible licenses:

You keep mixing licensing and policy issues. We'll get nowhere this way. Do you think we have 2 issues. Let's split them and analyze each one until we have an answer, do you think we only have one, let's analyze that one.
The page you linked is about CODE compatibility. Here we are talking about DATA: CSS and images are not code. Furthermore here we are not talking at all about compatibility as the drupal module is indipendent bridge under the GPL while the theme is an indipendet style under another Free open source license.
Your policies already allow people to add themes having alternate commercial versions and also to post modules bridging commercial third party websites. The whole issue here is policy, one you get this we can stop talking about compatibility and we can try to understand what's best for the drupal community.

as far as I can tell #2 + #3 means themes with CC components cannot be hosted at drupal.org right off the bat due to licensing compliance, regardless of the other non-license items in the policy. If this is not true, all we need is an 'official statement' (ie from Larry Garfield or other member of the da) that CC is ok.

This theme does not have a CC component. Like the gutenberg theme if you want to see something you have to add an external style. As for the gutenberg theme you shouldn't care of the external licenses. IMHO a policy should be made to ensure that similar bridges are only done when FOSS styles are available and not only to promote some paid-for theme. Maybe this policy is already there and correctly does not exclude Gutenberg and KeepItSimple.

As has been said many times in relation to this issue, GPL compliance is necessary but not sufficient for hosting a theme on drupal.org. Just because a theme does not violate the GPL does not mean we are required to host it here. We're in the process of trying to codify what those other, non license related, policies should be. And let's be clear about something-- policies have been in effect through practice and fixed issues already. Themes get published and unpublished all the time with all sorts of reasons. This thread was started just so we could document what has been already been in practice in order to be fairer and more consistent.

It's you repeating issues about compatibility. IF you stop "attacking" compatability and you accept that licensing allow what KeepItSimple and Gutenberg do then we can discuss about policies. It is hard to discuss about d.o. policies and improvements to be made to this HandBook being created if you keep repeating stuff about compatibility that do not exists in KeepItSimple or Gutenberg.

This effort has totally gone off the rails. People are being forced to repeat themselves ad infinitum for what, appears to me at least, is no good reason.

That's probably because we don't agree on 1+1. IMHO you keep pointing to documents that are off topic for the very purpose of this discussion.

I think we want a policy that encourages theme contributions but also protects the end user experience of those downloading themes (typically the less technical user) at drupal.org. I think the items we've outlined here do that. I think it's common sense.

How do you think that Gutenberg usage is simpler than KeepItSimple usage for the end user? Installing an external zip in a given folder is exactly what each drupal user does for each module/theme. I don't see the point where a less technical user will not be able to use KeepItSimple but will be able to use Gutenberg.

As I've said before, if you have to argue in order to decide whether or not a theme is "complete" it probably isn't and shouldn't be hosted on drupal.org. If we want to become like all the other bait and switch sites out there (oh, you mean you wanted a steering wheel with that car?), then fine. Document it in this policy as being ok and lets move on.

We are talking about a policy to allow "theme bridges" and notf full themes to be hosted on d.o. As currently this is allowed to Gutenberg it is not clear under what policy it should be disallowed to KeepItSimple.
Have you ever downloaded Gutenberg theme bridge? Did you ever cared for the licenses used for Movable-Type themes?

Drupal also hosts some Zen and framework themes that are not usable as is but they are good for developers. IMHO they should still be allowed by a theme policy, but I'm not sure the current handbook allow this.

I'm not telling that KeepItSimple is perfect as is and there is nothing to change. Maybe the policy require a change in the screenshot or in the text I use for the project description, but the case is the same as Gutenberg. If the policy allow Gutenberg there's no legal reason nor policy reason to not allow KeepItSimple, unless you add a policy saying "themes contributed by Bago follows a different policy". You're free to do this and it seems you even have the power to enforce your preference. But please note that "having the right to do" is different from "the policy is defined by the community".

One reason could be that you turned around a clear and correct answer and this is why we need to repeat it again and again until we have an clear answer.

As I've said before, if you have to argue in order to decide whether or not a theme is "complete" it probably isn't and shouldn't be hosted on drupal.org.

Gutenberg is incomplete. Unpublish it please, I do not understand why rules do not apply to every theme and only to one.

Again - you haven't read the licensing FAQ. This counts only for modules, but not for themes data.

Again, bago have not hosted CC code on d.o and have also no plans to do. You may have missed this.

The screenshot used on drupal.org must accurately represent the theme.
In conjunction with the previous guideline, all screenshots used as part of the theme's project page must represent the theme exactly as hosted on drupal.org and not another version of the theme available elsewhere.

Additional others seems not support this rule, see http://drupal.org/node/577888. bago's "wrong" screenshot seems therefore also fine as Gutenberg seems to be fine.

I'd like to see rules applying to ALL and I mean really ALL themes and not only to a few exceptions for flimsy reasons and personal thinking of 1 person or a small minority we cannot name.

I agree that the rules have to be applied evenly and I don't see anyone here saying they shouldn't be.

The rules need to be published first, developers made aware of the rules and given the opportunity to alter their theme to comply, if possible.

In: http://drupal.org/node/416022
The unpublishing of bagos theme contribution may have been a bit too hasty but I'd put forth that his first comment #1974216 he stated "he didn't care too much" what happened to the theme and that statement may have helped get the theme unpublished prior to the rules being written and subsequently enforced. Obviously the care level has been understated.

It would help a great deal if all involved focused on policy creation and kept their arguments focused on that goal rather than working their way through the theme list to find others that aren't in compliance with a policy that has not been made public. It is known there are other themes that may not be in compliance based on a ruleset that isn't yet published.

If it makes bago and hass stay focused on the challenging task at hand, my suggestion is to republish the keepitsimple theme until such time as a ruleset is published and those developers can be pointed to the new rule set allowing them the ability to evaluate whether not not the possibility of compliance is possible. If they can't comply because another license and the policy don't work hand in hand then a decision can be made to unpublish the project/s that are no longer in compliance.

In: http://drupal.org/node/416022
The unpublishing of bagos theme contribution may have been a bit too hasty but I'd put forth that his first comment #1974216 he stated "he didn't care too much" what happened to the theme and that statement may have helped get the theme unpublished prior to the rules being written and subsequently enforced. Obviously the care level has been understated.

Isn't this comment a waste of time? Do we even have to discuss about how much I care today and tomorrow about something? Or do we instead want to simply go ahead and look better at the policies?
When people started accusing me to try to fool users into buying something from me and similar stuff I started caring. Everyone on the internet has a reputation, you should no. Until I will be able to freely speak I will defend mine.

So back on our focus.What are the policies that currently disallow KeepItSimple publishing and what is the difference between KeepItSimple and Gutenberg with regard to the "violated" policy? I ask this because KeepItSimple is unpublished while Gutenberg is published, so I must be missing something.
Let's answer this precise questions and work on a correct reply to this question, does it make sense?

If it makes bago and hass stay focused on the challenging task at hand, my suggestion is to republish the keepitsimple theme until such time as a ruleset is published and those developers can be pointed to the new rule set allowing them the ability to evaluate whether not not the possibility of compliance is possible. If they can't comply because another license and the policy don't work hand in hand then a decision can be made to unpublish the project/s that are no longer in compliance.

As I wrote on the unpublishing issue I don't care too much about this. KeepItSimple can stay unpublished while we all understand the policies and improve them, but here people is not answering "we are working on understanding this". They instead answer using arguments about GPL compatability, CVS rules violations, and so on. Either this is FUD or misunderstanding or they are enforcing their own personal preferences because of their d.o. powers.

In lieu of established formal policies, issues on d.o can, have, and will continue to be decided by the best judgment of the members of the responsible team.

That particular issue has been discussed to death over a period of several months, and a decision has been made about it. I don't think it's worth reversing that decision unless there's a consensus among the site maintainers to do so and/or a policy is established that makes such themes okay on drupal.org.

That particular issue has been discussed to death over a period of several months, and a decision has been made about it. I don't think it's worth reversing that decision unless there's a consensus among the site maintainers to do so and/or a policy is established that makes such themes okay on drupal.org.

Are you referring to the keepitsimple issue? I don't think you are right. The issue has been closed because it was becoming a flame and because there were policies issues to be defined here before being able to "fix" it. The issue is not closed and no decision has been made, in my opinion. Otherwise please tell me because I'm wasting my time in this groups trying to improve policies when instead people instead ignore policies and simply take personal decisions. I can't believe d.o. community works this way, so I ask you to collaborate towards better defined policies. This is the whole point of this thread, isn't it?

When the policy is finalized please ensure that all maintainers/admistrators both d.o and cvs are made aware by issue or by email so that they know how to proceed in the future.

As it stands now, I myself with elevated permissions and a desire to help in the d.o issue queue am completely confused about how to proceed with these types or similar issues. As such I feel I have no choice but to avoid them in the issue queue until such time as a formal policy is in play where I know what rules to follow too : )

It was made with Artisteer, but I am not going to create any more themes in the near future. My goal is to make this one and support it, unlike other Artisteer users. Is there a problem with this? I'm not sure why the tool used to create the theme matters so much anyway...
thank you,
Dan Silver

If you aren't dumping a bunch of themes in there and are going to support it, I don't think anyone is going to mind what you made it with. The point is to stop people who are essentially spamming via theme submission.

I have a concern about the complete themes rule that has been suggested multiple times. I do agree with all of your reasoning but I have one use case that I think should be addressed.

A theme creator may create a theme that contains non-gpl items such as CC images from Flickr or something like Fam Fam icons. These images would not be eligible for hosting on d.org. But a theme designer could contribute a theme to Drupal by uploading the theme templates as the release and put in the readme that the images must be downloaded from another server.

I feel this use wouldn't be spam but would be blocked if the above rule was put in place.

To continue this practice is used and accepted in modules. There are several modules that act as a glue between Drupal and another script. One popular module that does this is WYSIWYG. By itself the module has no functionality. The user must go and download an editor from another website. This type of use is considered acceptable for modules and I think similar consideration should be given to themes.

A practice used/applied with modules does not have to be the same practice used/applied with themes. I'm all for consistency but .....

In part I disagree with the idea that a theme can/should/will be distributed from d.o while having a download css or images from another site. Personally, if the user has to go elsewhere for css and images, the developer may as well just distribute the entire theme from their personal/commercial sites.

side note: OpenPublish is an installation profile and based on the project page description a complete drupal redistribution. Because it is an installation profile, the project can't add the 3rd party non GPL inclusions on drupal.org. Which would mean anyone downloading and installing said install profile wouldn't have all the files necessary for the installation to work properly after it was installed as inclusions would be missing in total. I may be missing your point though where it concerns your pointing out this specific project?

Back to non-GPL themes:

I'm of the school of thought that both can be handled separately and differently. Just because it's done with modules doesn't necessarily mean it has to be done with themes.

Without regugitating my opinion and thoughts from other discussions on this subject in total, I'll paraphrase.
Themes without a stylesheet are broken in my opinion. The argument that modules are also essentially broken I disagree with. A module missing a 3rd party inclusion does not make a site difficult to navigate when they are enabled. Once a theme is enabled without a stylesheet the task of navigating a site is made more difficult. A module that is enabled without a 3rd party library only causes that specific module not to work.

The idea that, well, we can just add some text to a readme.txt file doesn't work for me. As someone who spends quite a few hours a week supporting drupal in IRC and in the forums on drupal.org, I don't believe these files are read often by many users who post questions. Especially new users who've little to no idea about drupal or any other script for that matter. Once a theme is enabled that doesn't include a stylesheet, a great deal of those users will be posting to the forums that their site is broken.

I draw a good part of my conclusion by the amount of threads that already get started over IE's max stylesheet debacle. New users don't see styling, they panic and run to the forums with no clue as to how to explain what isn't working WRT their installation.

You made very good points regarding usability. I agree with everything you said. I guess from my viewpoint it is a matter of finding a balance. The GPL was created for software and either doesn't work for artists (both copy and images) or it just isn't popular among them.

Oh, on a side note, from our other thread inside the forum, talks with the designer who was going to let me port his designs to Drupal ended up null. For whatever reason he just doesn't want any of his work released under GPL.

A large complaint I hear about Drupal is themes. I'm sure a lot of the themes on Drupal.org (and Wordpress.org) that contain images are in violation of copyright infringement. For now it seems to just slip through the cracks, but if themes were opened up to the artistic community by allowing CC I think it would benefit Drupal not hurt it. Drupal.org already licenses copy under CC.

As for hosting off site, I personally feel that is a bad idea. One of the my favorite parts of the Drupal community when compared to other OS communities is that everything is centralized. There is no need to go to a hundred different websites. It builds confidence in the user. I think people are skeptical of a plugin from an unknown website but give greater trust to a plugin hosted on the project's website. With Drupal I always have confidence because everything is hosted here on D.org.

I know in the end my opinion doesn't matter but I just wanted to weigh in.

your opinion matters as much as everyone elses, don't sell yourself short. drupal.org is a community effort and you are part of the community.

Based on your previous comment, you agreed that the theme itself can be hosted on d.o but that the images and stylsheets could be hosted elsewhere. This would cause a user to have to go to 2 separate sites for a single theme. This idea is a direct contradiction to;

As for hosting off site, I personally feel that is a bad idea.

I dislike the partially offsite idea more than the totally offsite idea. If d.o is to host non-gpl themes it should consider hosting the entire theme over hosting only part of the theme to avoid sending users off on a wild goose chase.

** a bit off topic **
In trying to be constructive, I've offered up the idea of distributing non-gpl themes from d.o and giving them their own taxonomy term based on the license they are being distributed as. However, after much more thought on this, where does the line get drawn? Does d.o then open the doors to hosting commercial themes for free too? I'd really not like to see this happen at all without d.o or the d.a getting a piece of the action. Afterall, it's d.o bandwidth being used to serve these themes on d.o. If this were to happen, I'd like a more formal setup where d.o recieves a percentage of the sale of themes on d.o, which benefits the community as a whole. Though that is another issue entirely.

Based on your previous comment, you agreed that the theme itself can be hosted on d.o but that the images and stylsheets could be hosted elsewhere.

No contradiction, my suggestion was a workaround for the current limitations of all files on D.o to be GPL. It would not be my ideal solution.

RE: stylesheets: the more I think about it, I think there is less need for the style sheet to have a different license. I do see a line in regards to imagery. At the very minimum allow images to be CC'd. I think it would boost the creativity of the themes on the site.

For commercial I agree there is a lot to think about on that issue. I don't have an opinion at this time. I think my only opinion here is that Drupal.org should keep files that are Free as in Freedom. GPL holds to this, but does the CC attribution do this as well? I assume so, but I haven't studied the finer points.

This developer is adding links into the footer for newhostgatorcoupons.com to 5 of 6 themes being distributed from drupal.org.

I will paste my comments here, where it relates to the issue being discussed:

I'm all for giving a developer the opportunity to correct a shortcoming.

I agree that it should be part of the forthcoming policy and I am thinking a time frame should be in order. not less than 7 and not more than 21 days. Doing so would allow enough time for those on "holiday" or on "vacation"

A more stringent policy would be to unpublish the offending project nodes immediately following notification. When the issue is corrected they roll a new release and that project start the ball rolling again. Otherwise, there are still releases available with the offending issues.