Theme requires download of non-GPL files for CC licensing reasons of the DATA parts of theme

Is anything that's actually commited to CVS non-GPL? Requiring a third-party library/etc isn't specifically verboten from what I recall. The fact that the author *didn't* attempt to commit this to CVS shows they are at least aware of the risks here.

The conditions that apply to the third-party library apply also to the theme which uses such library.
I am not sure if the conditions that the project page for the theme reports are compatible with GPL.

"I find these themes that show a beautiful screenshot but require additional non-GPL code to make it look that way to be somewhat "bait and switch" and deceitful."

I do, too. I was complaining about that on IRC yesterday. I don't like these partial themes that are just teases. Like previews for a movie to get you to come buy the whole thing.

Michelle

My thought was this: if the theme uses a third-party library that has additional conditions it must respect, then I cannot use the theme if I don't respect those conditions.
It is like a program that uses a third-party library that is GPL; the conditions for the use of the library become the conditions to use the program. I cannot use the program if I don't respect those conditions.

Maybe the comparison is not appropriate, or maybe I am missing something. That is how I feel respect that theme.

Just noting that http://drupal.org/project/vitzo_flex does the same thing.

Michelle

In the case of http://drupal.org/project/vitzo_flex there is a different problem, but the problem is worst.
The theme downloaded from Drupal.org simply shows a blank page, and the user is invited to download the full theme from a different site.
I don't think this is even acceptable; it's not even acceptable that the themes hosted on Drupal.org are preview of themes hosted in other places, but that a theme hosted on Drupal.org is not even working is too much.

I opened a different report for Vitzo flex; see #470086: Theme hosted on Drupal.org shows a blank page because the author removed the files not under GPL license.

Queue cleanup:

Kiam this issue fixed?

Vitzo theme has been unpublished, not because the theme shows a white page (which was caused by some mistakes made from who installed the theme in his web site), but because it doesn't contain CSS file that must be downloaded from a third-party site.

This report was open for KeepItSimple (http://drupal.org/project/keepitsimple) that reports in the project page conditions that are not acceptable for a GPL License. The conditions are valid for a file (a CSS file, I guess) that the theme needs.
IMO, the conditions should not be listed in the project page.

I forgot to change the status.

has anyone contacted bago, the dev of the theme in question?

The user was active as of March 2009, per CVS

I don't think anybody contacted him.

I think this theme should be unpublished: it is not usable at all without download of the external CSS. It also doesn't seem to work, according to the posted issues.

Theme unpublished and the following email sent:

Bago,

The keep it simple theme in the drupal.org repo was flagged as an issue because of the license and the conditions set forth on the project page.

At this time the theme's project page has been unpublished until these matters can be addressed.

Please see and follow up: http://drupal.org/node/416022

Thanks in advance

Bago can respond here and reopen the issue.

Sorry for the late answer, I was on holiday.

The theme works, but depends on the external CC code.
What I committed is licensed by GPL and I own full rights (I'm the author).

The theme won't work without the external dependency. I saw other drupal "projects" requiring this so I simply did that.

Most "bridging" modules only works when other code is present. There are modules to integrate with commercial services. These commercial services are closed and commercial, but you allow the integration modules to be in drupal.org.. so why a "bridging" theme module to allow the use of the original keepitsimple theme should not be allowed?

I'm aware of source code licences, copyright, trademark laws and patent laws but this is more an internal drupal policy than a licensing issue, and I don't know the policy and who wrote the policy. So I simply thought this was allowed as it was the same use case of hundreds bridge/connector/integration modules already distributed by this site.

If you believe it is better to not have support for a CC theme this way then it's safe to leave it unpublished.

I don't care too much. I created that theme for my personal blog and I like to share.

I quoted the 3rd party license because you need that file otherwise this theme is useless.. like installing the oscommerce module without oscommerce, and so on. So it is better to let people know what are the dependencies and what are their licenses.

As I use drupal and many drupal modules I found this a common practice. I even found commercial dependencies.

I think that the case of a module requiring a third-party code library is different from a theme that doesn't come with a CSS file; the difference is the complexity of the code present in a third-party library, especially when the library allows to integrate the module with third-party services.

The topic here is the conditions reported in the project page, which are not acceptable from Drupal.org; differently, third-party modules that requires libraries you download from a third-party site doesn't report the conditions of use of those libraries in the project page.

+

Diff, Geshifilter and other modules need to be unpublished. They are all not working without an external library and it's complex task to install it - at least Geshi is not easy. Same situation like a theme with CC license not having CSS files.

If we are going to talk of modules that depends from third-party libraries, then the list is a little longer. I guess there is a difference between a library licensed under GPL License, and a library that is licensed under a different license.

I disagee with the assertion that because a 3rd party library isn't inlcluded it should be unpublished. The issue here is crippleware.

Unpublishing ALL modules that require an offsite third party library is over the top. At that point not only are you talking about filters, but editors as well.

I don't even think there is a problem with a module requiring a third-party library that is released under a license different from GPL; the important is that the module, and the library are not packed together (am I wrong about that?).

The topic here is a little different anyway; we are speaking of the conditions reported in a theme project page.

A module that requires a library is also crippleware. It's fully unusable without the library. Please define crippleware if you think different and you can argue that something with a missing library is not the same situation. I'm pretty sure we will find modules using CC or other licensed libraries if we search long enough.

If there is no problem with a module that requires a 3-party library - there is also no problem with themes. It is only fair to have for everything the same rules.

I believe this is another everything need to be GPL issue what is not correct as Drupal also allows to depend on other software that is not GPL. It was clearly written from the association lawer that CSS, images and other stuff not using Drupal API's don't need to be GPL licensed.

I'd think that the question that should be asked here is ... is the theme usable (what one would expect of a core theme) without the commerical stylesheet being purchased? If the answer to this questions is no, then the theme should likely be removed from the repo.

is the theme usable

would become

is the module usable

and we need to answer DIFF and GESHIFILTER module are not usable without the 3-party library. So unpublish all GPL code that rely on 3-party libraries. And not to forget CC does not require to purchase a license. It's only not the GPL license, but still free of charge.

I feal like the Google Analytics module (I'm the maintainer) - should also be unpublished. It integrates closed source code from Google. Today we do not need to pay, but maybe in future... I'm guessing - but somedays they may with to make money with it and than we need to unpublish for the reason it requires payments?

a module does not remove core functionality or require the third party library to use core.

How can a theme remove core functionality? I'm VERY confused...

A theme CSS framework licensed under a CC also does not require to be used in a Drupal theme. It can never change core.

hass any chance you've taken a look at the download of the theme in question? Using KeepItSimple as an example ...

There are there is no styling in the css files included with the theme. This theme can be enabled but have NO styling whatsoever, without downloading the alternate stylesheet. The theme should at least work with core to be distributed on d.o. IMO, The fact that the theme will not work with core without downloading an alternatate style sheet is what I am referring to as changing core functionality. Had this theme come with a stylesheet that provided the basics of what one would expect in core, I wouldn't see an issue here. However that is not the case at all with the theme in my example.

I'm sorry - I wished I could, but the KeepItSimple project is currently unpublished and I cannot access it.

I do not see any reason why a theme need to have CSS/image files on d.o. If it have .info, page.tpl.php, node.tpl.php, template.php and the other files that require to be licensed under the GPL - what is the problem with hosting them and providing the dev platform? A theme may look uggly without CSS files as content is "unstyled" and someone who like to see the full style is free to download the external CC licensed CSS files from an external site. This is 1000% comparable to 3-partly library with the difference that a module hosted on d.o cannot work at all without the external 3 partly library (read Geshi Filter - zero functionality). The theme on the other side can be enabled, and shows content "unstyled" to the user.

User expect this as the know they need to download the CSS files from an external site.

The paragon is a little wrong. To make a correct paragon we should think to a module file .info that would be downloadable from a third-party site, and that is licensed under CC (as a file .info doesn't contain PHP code, it could be licensed under CC).
In this hypothesis, could the module be hosted on Drupal.org?

IMO, the paragon between a code library, and a CSS file is not correct. A code library can contain code that is difficult to create (or it is not desirable to replicate -- as in the case of the code used by Diff, or many other libraries for the support of third-party services); differently, it is always possible to create a CSS file that emulates the aspect given by another CSS file (and if it is not possible, there are many CSS file licensed under GPL that could be used).

I guess that the solution to not use a library not licensed under GPL (which is not packed together GPL code) is to create an equivalent GPL library. Is there anybody volunteering for this task?

This is 1000% comparable to 3-partly library with the difference that a module hosted on d.o cannot work at all without the external 3 partly library (read DIFF - zero functionality)

Take off the CSS files from all the themes, and tell me what the difference between them is. I guess that without CSS files, Garland would visually appear almost the same of any other theme hosted on Drupal.org.

@Kiam: Are you trying to tell me CSS code is not difficult or does not contain code that is difficult to create? This is not a basis to discuss licensing issues like this. I can show you a *complex* CSS Framework that nobody else have yet build in the world except the maintainer of YAML (www.yaml.de/en) and he also provides his work only under a CC license. It contains much much code that is not available somewhere else.

I cannot speak for KeepItSimple as I'm not using it nor I have ever taken a look to the code, but the discussion is pointless. The CC code is not hosted on d.o, but the parts that require to be GPL are on d.o. Nothing wrong here...

This theme should remain unpublished --

If the author wants to sell the theme, they can do that.

If the author wants to release the theme under a different license, they can do that.

However, they can't do it via drupal.org

The module examples cited are for projects where there was pre-existing code that was already licensed under a different license, or code that was under active development as part of another project (so including it as part of the d.o download would run the risk of appearing to create a fork).

In this case, the author has all rights; they are just choosing not to release the theme and its components under the GPL. As I said earlier, they are well within their rights to do this, they just can't use the d.o infrastructure.

This is a won't fix.

Take off the CSS files from all the themes, and tell me what the difference between them is. I guess that without CSS files, Garland would visually appear almost the same of any other theme hosted on Drupal.org.

No, placeholders and HTML code can be different and therefore some may use float, other not and others have a table based design. The difference is visible... if there is only one char/letter different in the page source code it's different. All this depends on the users flavour.

Are we now discussing if something looks good/ugly or if it's a licensing issue if non GPL code is published in a different site?

@bonobo: I cannot read any argument why it's not allowed to host the themes GPL code on d.o and code that cannot be offered under GPL on a external site. I'm very interested why this shouldn't be allowed if the association have said, CSS and images do not need to be offered under a GPL license if they cannot.

Next time someone will only add one dummy CSS to a theme and point the users than to the external site... in such a case the basic theme is "usable" and from a first look "intact", but it isn't.

The issue here is that this theme author is showing a screenshot that only appears with CC licensed code, and they are essentially using d.o to distribute a CC licensed product.

And don't get me wrong; I love the CC-attribution license -- it's what I use to license my online writing. But in this case, the screenshot shown on the project page is essentially a lie; it shows the look/feel of the CC theme. From a usability place, this just contributes to the "All Drupal themes suck" garbage, because this theme attempts to skirt the expectations of contrib code.

Until the screenshot on the project page matches the look/feel of the code that is downloaded from d.o, and the CC license requirements are gone from the project page, this theme should stay unpublished. And even then, under the current terms, this project should have an enormous disclaimer on the project page:

"This theme will not work the way you expect a theme to work until you download external files from my website. Because I am choosing to license pieces of this theme under a different license, you will have to work harder to install this theme than you should. There is no valid technical reason for this; I have made a decision that forces you, the user, to work harder -- because this benefits me. However, I really appreciate the extra visibility that having my project on drupal.org provides my web site."

I have a few questions and I also like to please you all to come back to the question of license and not of flavour. If we discuss favour here we will not discuss a licensing issue and if we tell theme maintainers that we do not like their ugly theme and we unpublish it only for this reasons are are *very* unfair.

If we do so - we must unpublish 90% of the themes on d.o as they all looks ugly to me - personally spoken.

So again, let's come back to the reputed LICENSING issue:

1. The GPL allows to split theme code from proprietary code.
2. It was written by the Drupal association's lawer that CSS and images in a theme do not need to be offered under GPL.
3. In such a case a themes maintainer need to offer the theme code that integrates with Drupal (use drupal hooks and api's) need to be offered under GPL.
4. CSS and images can be licensed under a different license.
5. Where is written that users are not allowed to host GPL themes on d.o if they are broken? There are MANY broken themes on d.o
6. Always keep in mind that a theme shows content on a page with and without CSS and image files. If it looks ugly or not - it's not a licensing issue if something looks bad from someone personal view.

I would love to have a discussion based on facts not on flavour.

Removing the "wrong" theme screen shot would allow the maintainer to get the project published back? How can a wrong screenshot break a GPL license?

@hass -

The example I used for the screenshot is used to demonstrate that this project page is essentially lying to the unsuspecting user -- the screenshot on the project page is not what appears on your site when you download the theme.

RE:

It was written by the Drupal association's lawer that CSS and images in a theme do not need to be offered under GPL.

You are confusing what is legal, out in the world, and what can be hosted on d.o --

A person can build a theme and sell it -- from their web site.

They can release the css and image files under whatever license they want -- from their web site.

This is legal. But, this shouldn't be hosted on d.o --

The point here isn't the legality of what the theme author is doing. The point here is that the community norms of d.o were not adhered to -- and these norms clearly state (and will state even more clearly soon, thanks to WorldFallz) that, in the absence of a compelling technical reason (articulated in #36 and #39), the complete, usable download should be hosted on d.o --

This project, in it's current state, is nothing more than bait and switch advertising for the author's site.

RE:

Removing the "wrong" theme screen shot would allow the maintainer to get the project published back? How can a wrong screenshot break a GPL license?

I'm just going to assume that this is a rhetorical question, because otherwise it makes no sense. Lying on a project page clearly goes against community norms. The screenshot on the project page does not show the theme that is downloaded. This is not a licensing issue, but it is an honesty issue.

IMO, focusing the the trivia of the rules risks overlooking the spirit of what they are trying to promote. In the same way that we unpublish/delete spam, we should unpublish projects until their authors bring them into line with the community norms.

Really, the best solution here would be for the author to release the entire theme on d.o under the GPL. This would eliminate the need to have this thread, and it would get them more visibility for their site, because more people would actually use the theme.

Changing title to reflect the actual issue, setting to "won't fix."

Thank you for the detailed explanation as it turns out it's not a question of the license. I would be happy to see the links to this norms in this thread - if it's available soon and hope it will make some clear explanations about the license part, too.

Looks good to me, but what are all those linked hashes for?

Michelle

See http://drupal.org/forum-posting.

Oh. :-)
I didn't notice the author of that book page; I am sorry.

@WorldFallz: Ah, that makes sense. Good idea. :)

Michelle

@VeryMisunderstood: so you think I should simply add an empty CSS named like the external one so the theme works and we are fine? Useless, IMHO, but if that's what is needed it is easy.

@VeryMisunderstood: you ask if KeepItSimple requires a commercial CSS: the answer is no. You don't need to pay to download the css.

@bonobo: sell??? Are you kidding me? Do you know what is hte Creative COmmon License? Here no one wants to sell anything. THe code I contributed is GPL and is a wrapper to use a Creative Common distributed stylesheets. YOu let publish 3rd party integration modules (see all the antispams, newsletter integration, website analytics..) in d.o. Most of them require you to pay in order to make use of the module, and you're worried of a Creative common CSS required for a theme??? Sorry but I really don't get this. I'm an Open Source contributor (apache committer) since 5 years. I understand opensource and licenses. Whatever you wrote in #36 is plain FALSE: please read more before you take decisions. I'm the author of the drupal them. I'm not the author of the CSS itself. The CSS is available on the internet via the FOSS license I described in the theme page. What is included in the download has been written by me and everything is distributed under the GPL.

@WorldFallz #39: this theme is not to sell anything. The 3rd party download is free-open-source-software. Simply it is not GPL so it can't be packaged and uploaded to d.o. Most of the comments above are FUD.
Why Akismet modules are allowed in d.o? If I want to use them commercially I have to PAY. Why Akismet, having a 3rd party, commercial website presence requirement, allowed, while a theme depending on creative common css is not allowed?

@bonobo #40: I'm not distributing CC code via d.o: you may need to read again the definition of "distribution" with regard to licensing and copyright. AND the external file is not MINE.. I can't change their licensing. I didn't wrote this to bring people downloading something I writted under a different license (unlike you are trying to FUD).

@WorldFallz #43: you can do whatever you want. Simply if you allow commercial integration modules do be hosted in d.o and disallow a them bridge like this one maybe d.o is a directory where only who pay you is entitled to publish his stuff. Maybe the community needs something better. You can do what you want, the community can react the way they like. WHO decide what is "sealed"and what is not "sealed"?

MOST of the comments above try to induce the reader thinking I'm selling something. I don't sell anything. I wrote a theme for drupal based on a free open source stylesheet (distributed under the creative commons) and I decided to share it. I'm an Open source contributor (see http://james.apache.org/weare.html) and I like to share what I do. IMHO this whole thread is a waste of time. IMHO what I published is useful and the creative common "dependency" (it is not a dependency strictly speaking) is described to let users understand how it works. I've used plenty of modules that required external websites (often commercial) or external libraries (GPL, other free licenses, or even commercial ones) and I always downloaded them from d.o.

As a specific example these modules require an account on a third party website. Some of them are commercial?
http://drupal.org/project/httpbl
http://drupal.org/project/mollom
http://drupal.org/project/akismet
How is this better than a CC dependency? Let me understand: if I replace the instruction about downloading the Creative common CSS file and simply link the CSS file from my website (so I make them use a free 3rd party service) I can upload it to drupal org?)
I think allowing people to download the CSS is much better than forcing them the use of an external resource. BTW it's easy for me to put an "@import 'http://emailmarketingblog.it/sites/emailmarketingblog.it/themes/keepitsi...'" in one of the other CSS and I can stop telling people that they will need to download the Creative common CSS).

And if you're replying that the antispam websites all have a free account, then let's take this one:
http://drupal.org/project/campaignmonitor
in order to use it you have to subscribe to campaign monitor and BUY their services. But even with this requirement you allow redistribution from d.o.

I'm really confused about your weird policies.

You have my full support... but some seems to be more similar than others. People who think GPL is the only license they need to accept are not open minded to other models nevertheless it's the decision of the downloader if he like's toe use a GPL with CC together or not. As already said - CSS is not only one file - it could be a full framework like YAML and this is very complex and can also not uploaded to d.o, but the rest of the theme is also GPL and could be developed on d.o - like yours. But I know that GPL lovers do not understand that some others (we cannot change their mind) do not like to offer their work under a GPL license, but are fine with a free CC license.

Nevertheless some GPL people do not understand why others like to use a CC license - it's not their decision if others like to use something that's free and offered under a CC license and that is not available somewhere else in the world. I also do not understand why modules should have other rules than a themes. A theme can also show content unstyled and it's nevertheless a valid theme.

However, when distributing your own Drupal-based work, it is important to keep in mind what the GPL applies to. The GPL on code applies to code that interacts with that code, but not to data. That is, Drupal's PHP code is under the GPL, and so all PHP code that interacts with it must also be under the GPL or GPL compatible. Images, JavaScript, and Flash files that PHP sends to the browser are not affected by the GPL because they are data. However, Drupal's JavaScript, including the copy of jQuery that is included with Drupal, is itself under the GPL as well, so any Javascript that interacts with Drupal's JavaScript in the browser must also be under the GPL or a GPL compatible license.

So - CSS and Images are DATA... no need to be GPL.

If you wish to contribute a bridge module to Drupal's CVS repository, please do not check in the 3rd party library itself. Doing so creates a fork of that 3rd party library, which makes it more difficult to maintain and only serves to waste disk space. Instead, provide detailed instructions for users to download and install that 3rd party library for use with your module. If you believe that your module is a special case where it really does need to be included in the CVS repository, usually only because you need to make substantial modifications to it in order for it to work, please file an issue with in the infrastructure issue queue first to discuss it.

and bridges to the CSS files... looks like allowed. And if other bridge modules are allowed, themes also need to be allowed.

The @import with full qualified URL follows this allowed way:

It is possible to distribute a module that communicates with a 3rd party system over HTTP, XML-RPC, SOAP, or some other wire protocol, that leaves the 3rd party system unaffected. Examples of such systems include Flickr, Mollom, or certain legacy systems.

a matter of popularity rather than policy

Ähm - "matter of popularity"??? It became popular only by d.o! So if I have a theme that is popular or you think it is - I'm allowed to publish it via d.o? If this is not a strange "licensing" logic I don't know...

Sure - but it's clearly stated that Images and CSS (and everything else that does NOT integrate with Drupal and not executed in the PHP/memory) is DATA and this is allowed to be non GPL. So also fine for this theme...

Otherwise the theme could be a bridge to a 3rd party system that communicates over HTTP and @imports the CSS files from the remote system. Modules are allowed to do this - themes should therefore, too.

To clarify a few points raised above:

- Bridge modules that link to 3rd party GPL-compatible code are acceptable.

- Bridge modules that link to 3rd party NON-GPL-compatible code are not acceptable, and we have removed those from CVS before.

- CSS is, um, well, kinda weird. :-) As far as PHP is concerned, it's data. However, as far as other CSS is concerned, I don't know if it's code or not.

- Drupal's CVS policy is that everything that goes into CVS must be GPL compatible, because it comes back out under the GPL. Period.

- Some CC licenses are GPL-inbound-compatible. Others are not. (Inbound compatible meaning that they can be relicensed under the GPL, the same way BSD code can be.)

How we want to treat CSS that is an integral part of a theme, I'm not sure. My gut feeling is that a theme should be "self contained" and not require piecemeal downloads the way that a module may in some cases, but that's not a legal opinion, just a personal opinion.

@Crell: This is not what is written in the Drupal licensing FAQ. "Bridge modules that link to 3rd party NON-GPL-compatible code are not acceptable" is written in the FAQ. Mollom is as I know like a closed source remote service and Acquia also have such modules in CVS... and there are more.

We should not judge about "piecemeal downloads". If something is popular you download all pieces if you like it... aside it's only 2 pieces, not 10 or more.

again this conversation seems to be working its way toward what is legally permitted by the licenses rather than what is permitted to be distributed from drupal.org.

Licensing debates aside.

I'm a new user.
I download a theme from drupal.org
I upload the theme to my site
I enable the theme
I am presented with a site without any styling at all.

The above doesn't at all seem right to me but I digress I will follow whatever the consensus is in this situation.

Agreed a user can read a readme.txt, read a project page to learn that the stylesheet can be downloaded elsewhere but based on my support in the forums, few who ask questions actually take the time to read the project page or the readme.txt

My personal opinion is the same. A theme that has 'zero' styling in a stylesheet and essentially forcing someone to go to a 3rd party site to download the stylesheet should not be distributed on drupal.org. The theme can be distributed elsewhere.

Mollom, Akismet, etc. are 3rd party services. They involve no download of 3rd party code. Those are legally fine. 3rd party code would be tinymce, ckeditor, etc. Those require the download of 3rd party code that is under either the GPL or a GPL compatible license (eg, LGPL). There have been WYSIWYG bridge modules in the past that bridged to non-GPL-compatible commercial editors. Those were removed from CVS.

I am presented with a site without any styling at all.

Who have said you download a beautiful theme? An unstyled theme is nevertheless a theme and I have not yet seen any unpublish for something ugly - but I'm open to hear if this have ever happened :-).

So if bago like to offer his work (and he said he likes to do so) - he seems to have at least two options to comply with the d.o rules:

1. Use @import with a full qualified URL (theme looks as advertised, and is self containing or links to 3th party via HTTP) and the theme looks as expected, but do not have the CC files included in the release.
2. Add an ugly css that styles the theme in a non-beautiful way, but comply with the d.o rules by this way. Than tell users in the readme or on project home - there are other drop in files you can download elsewhere to make the theme really more great than any other on d.o.

Both options follow the Drupal rules... and everything else looks like unfair personal judgement.

Access denied
You are not authorized to access this page.

I believe there is a fundamental difference between an ugly theme and a theme that is void of a workable stylesheet.

If hass, bago or others want to produce an "ugly" stylesheet to comply with d.o distribution rules so be it. At the very least unsuspecting users who download these themes from d.o can open the style sheet and see something more than nothingness.

I'm not qualified to respond to the @import ideas.

I agree with that assertion. To me thats basically a bait and switch marketing scheme that I think has been mentioned by others in this thread.

@WorldFallz #62: Please keep in mind that I didn't upload the CC-licensed-CSS to Drupal.org. The linking between the d.o.KeepItSimple theme and the KeepItSimple CC-licensed-CSS is "over HTTP" and leaves the other system unaffected. In fact It will be the browser to link them and not something on the server side.

I work in open source since years and I understand licensing a lot. Please stop using GNU/GPL and other references to enforce your own idea because what I did with KeepItSimple is not breaking any law or any interpretation by any open source alliace/authority. What we are discussing here is simply a policy.

I still don't understand why the campaign monitor module, that require a commercial service to be bought is allowed by d.o. policies and a theme using an external CC-licensed theme is not.

PROPOSED SOLUTION: So let's say I put a keepitsimple.css file including simply an @import of some url (what is in the url can be changed at any time, you don't care, right?). If an HTTP link is something GPL doesn't allow then start removing every commercial bridge on d.o. and then come back removing bridges to "non-GPL but FOSS" projects. Seems fair, isn't this?

@WorldFallz #62: you keep confusing "distribution" by d.o. and what "linking" means for GPL. All files in the keepitsimple module are GPL and they can be distributed from d.o. Download of the non-GPL code (but still FOSS) is left to the user. Linking will happen at runtime by the browser via HTML+HTTP protocol.

forgive my ignorance here, but can CC licensed and/or @imported css stylesheets be altered, put back in the theme by those who download them? Or are there restrictions in place that disallow this type of usage?

@VeryMisunderstood #73: in the keepitsimple module I decided to use the original keepitsimple.css module "as is" and add my own style/work in htmlelements.css. I didn something more than simply importing an empty css. BTW I just updated the CSV to include an @import to the css on an external site..
If this is not allowed then start removing any commercial module around. Here we are not talking about commercial stuff, here we are talking about letting users of open source software to be able to use the best of what is FREE-OPEN-SOURCE-SOFTWARE around. The original author of keepitsimple.css (I'm not the author for that CSS, I'm don't even know the author) decided to publish his work for free under the CC-BY.

You don't want me to tell people to download the file? Ok, for your "weird" policy people will use a theme linking to a CSS on my website, so I will have the power to change the look of their site whenever I want. This pass your "weird policies" but IMHO this is a lot worse than simply doing stuff that make sense (yes, we are talking about sense, and not legality).

The fact that bago is not the original author of the css file and that he/she doesn't know who the author is points out another reason this shouldn't be distributed on d.o

@VeryMisunderstood #78: CC-BY rules are described in the theme.. btw here is a simple explanation of the keepitsimple.css licensing:
----------------
All the free CSS templates on this site are distributed under the Creative
Commons Attribution 2.5 License. This means that you are free:

* to copy, distribute, display, and perform the work
* to make derivative works
* to make commercial use of the work

Under the following conditions:

* You must attribute the work in the manner specified by the author or
licensor. (In this case, a link back to my site)
* For any reuse or distribution, you must make clear to others the
license terms of this work
* Any of these conditions can be waived if you get permission from the
copyright holder
---------------
Please not that if we go with the "@imported" then you cannot anymore any assuption about the licensing of what is linked and I can put at that URL whatever I want, before or after users downloaded the theme. IMHO, in order to help and protect d.o. users, the @import should be "disallowed" by the policy, not the integration with other FOSS licensed stuff. I suggested the @import because I think you are answering with "false arguments" in order to enforce your original ideas, so I simply show you the other ways.

For sure I won't contribute more work to this community if the donation process is so hard and boring.

VeryMisunderstood - September 14, 2009 - 19:08

The fact that bago is not the original author of the css file and that he/she doesn't know who the author is points out another reason this shouldn't be allowed.

WHY???? so you have a weird understandig of opensource. FIRST, we are NOT talking about "INCLUSION in the theme" and "DISTRIBUTION by d.o.". We are talking about allowing a drupal module to integrate with a 3rd party work. Who ever said that in open source you have to know the original author of everything is distributed? *Licensing* exists for this precisae task: being able to do something without being the original author: if you are the only and original author you can ignore any licensing issue because you own the copyrights.

Please someone explain exactly what is the "LAW", "LICENSING ISSUE" or "POLICY" that doesn't allow a theme to either
1) include a url to an external website (this is what an @import in CSS is)
2) simply leave the README telling people to download the CC-BY-licensed theme.

Please tell me the cause and I'll find you 5 other published modules breaking the same rule. After that you will unpublish all of them or publish back this keepitsimple, ok?

Here is one why:

* Any of these conditions can be waived if you get permission from the
copyright holder

In this specific case then noone can comply with the above based on your statements whether distributed from d.o or not.

It's very simple. Themes hosted on drupal.org should be "what you see is what you get" and "what you get is what you see". Plain and simple. That's what everyone expects and all the naysayers know it. It's what you would expect as a user as well. Claiming othewise is purely disingenous.

So, what's the problem? The theme thumbnail?
1) If I simply leave the current @import of an url to my website the generated thumbnail is what is shown by the thumbnail: just publish it so I can produce the new bugfix release.
2) Otherwise, if you don't want an @import (and I could accept this, but you should also remove any other module depending on external websites to work), I can upload a weird thumbnail resulting by the missing inclusion/link and you will publish back the theme,right?

Here is one why:

* Any of these conditions can be waived if you get permission from the
copyright holder

In this specific case then noone can comply with the above based on your statements whether distributed from d.o or not.

If I was the author then we wouldn't be here discussing: why do you think I would have done a GPL module with a single file under a different FOSS license? I'm not a fool, I'm an open source developer/contributor. And it seems I'm wasting time that I could dedicate contributing to other projects, here.

If you were the author the overall conversation would still be taking place with regard to the methods being used to distribute on d.o. However, you're honesty (I applaud you for it) brought to light another question, and as far as I am concerned, another reason to disallow this type of distribution on d.o

It's very simple. Themes hosted on drupal.org should be "what you see is what you get" and "what you get is what you see". Plain and simple. That's what everyone expects and all the naysayers know it. It's what you would expect as a user as well. Claiming othewise is purely disingenous.

Can't we simply remove the screenshot? I think this would solve your issue, right?

Arguing ridiculous amounts of minutae in order to circumvent this common sense assumption about those downloading themes at drupal.org is a waste of time. And, btw, you're not fooling anyone. The only reason to argue for absurd exemptions to wysiwyg and wygiwys on d.o is personal, professional, or business gain-- whether from increased traffic to a site, name recognition, increased customer base exposure, etc. It doesn't have to be about monetary payments. The very first sentence on the project page of the theme in question contains two links to two other sites. Even the screenshot contains the name of one of the referred sites-- not the name of the theme itself. We all know how much google juice and eyeballs drupal.org gets. So please, let's stop pretending this is about anything other than free high-exposure advertising on d.o.

Are you telling me that you want to add another clause to GPL? Most GPL projects around live because this thing. Don't you think that Dries company get visibility for Drupal? What is the difference between the way I linked to keepitsimple.css and they way the mollom module links to the mollom service? When I clink on the first link of the mollom module I land to the mollom website and i see a big "PRICING" button... In what way the "mollom module" is allowed by the policy and the 2 proposed "keepitsimple" solutions aren't allowed?

If you have issue (or policies) against this, why don't you simply change the code to not allow links to demo sites or anything else? I'm not here to fool anyone. I think that users would be happy to use such a theme and this module is a good thing for users.

Please, everyone, answer this last simple question:
What is the motivation for allowing the mollom module (I take this one only because it is powered by Dries, but there are plenty of this modules) and disallowing the keepitsimple theme as it is now in CVS (using an @import to my own website) ?

I still think that a README to help the user download the CC-BY-licensed css file would be better than the @import, but I really want to understand why the import solution is not allowed.

Rather than of weird thumbnail, I would talk of a thumbnail that shows the theme as it is after a user download it from Drupal.org, and enable it.

I think we are keeping to change the aim, and we forget what we should focus on.

The first problem I think is the condition reported in the project page, which should not report any additional conditions that are not acceptable in a GPL License. I think I could not report in my project page that my project can be used only if I get money, or a postal card, or a gift I chose from Amazon.
The second problem is that I could not publish an incomplete project that requires the user to download a file which requires him to pay for a file, or to enable an account (and have a working theme/module), or another condition which is not compatible with GPL License. If I remember well, every conditions that say to use this code you must ... (and which are not listed in the GPL License conditions) are not compatible with GPL.

I read that it has been made a paragon with Mollow, and other services. I think the paragon is wrong as we are talking of services (as first), and in the case of Mollom I am not forced to always pay the service (I pay for the service if the requests done from my web site to the Mollom servers exceed an established number of requests).

And, btw, you're not fooling anyone. The only reason to argue for absurd exemptions to wysiwyg and wygiwys on d.o is personal, professional, or business gain-- whether from increased traffic to a site, name recognition, increased customer base exposure, etc. It doesn't have to be about monetary payments.

So, if they are the only reasons, what's your gain for arguing? And, better, as this is a question about policies: who define policies? Are you a representative for the decisioning committee? What's your role in this thread? (For real, I'm interested to know if I'm wasting time or I'm discussing with the right people)

The very first sentence on the project page of the theme in question contains two links to two other sites.

So, I go to this page: http://drupal.org/project/mollom and reading the mollom module description I find this sentence:
"The Mollom module is also included in the Acquia Drupal distribution.", where the last 3 words link to the acquia website. How do you call this? How is this better than a link in a site ferenced by drupal.org, considering that to use mollom I shouldn't even care about the acquia distribution?

Even the screenshot contains the name of one of the referred sites-- not the name of the theme itself.

Did you see the mollom module logo? My theme logo contains a screenshot of my personal website. This is the website I created the bridged-theme for, so it is OBVIOUS that I used that one to make a screenshot, because it better let you understand how your website can be if you use this theme. You have to put something there to understand the result. BTW, if your only issue is the screenshot, let's remove it and stop this thread. IMHO you are moving from issue to issue without trying to find a solution.

As strange as it is to find myself disagreeing with those I normally agree with, I think bago has a valid point. We allow modules to require 3rd party code for critical functionality and there are even themes that do ( http://drupal.org/node/396278 step #2). While I can understand not wanting crippled themes where the author takes a bit and hosts it on his website as a lure to get people there, that's different than including 3rd party code.

The question, to me, is whether the 3rd party "code" here is GPL compatable. For modules it has to be and therefore it should be for themes as well.

I seem to be in the minority both here and on IRC where I was just hashing it out with Crell and Heine but I firmly believe that we can't say it's ok for modules to require 3rd party code downloads and not themes. And only some themes at that since I haven't seen anyone complain about Blueprint.

I think the policy should be that requiring a 3rd party library is ok if it is GPL compatable. If an author takes out a chunk of his theme and puts it on his own site, then it is not a 3rd party library and should be considered intentionally crippling the theme and not allowed. But if an author wants to make a theme based on a 3rd party library and contribute the parts he can to d.o, I don't see that as any worse than, say, the tinymce module.

Michelle

This is not a license issue, but in large part a social issue. It is our job to discuss these issues and decide on a course that won't impact our community in a negative way. Fairness is of course one component of the assessment (though this is not Kindergarten). Predictability and common sense are another.

This isn't just about bagos contribution. Which he himself admits isn't actually his but about all themes that fall into this category as far as I can tell.

All themes that fall into this area would be subject to the same rules. If blueprint is one of them than that theme would have to comply as well?

I disagree that fairness is only important in kindergarten. We have a huge divide between developers and designers in this community already. I think saying "it's ok for developers to do this and not themers" is likely to worsen that. To me, that is common sense.

Blueprint is an example of this being used well, in my opinion. It's bringing a popular 3rd party framework to Drupal. To me, this is no different than the tinymce module making it easier to use tinymce with Drupal. There are many examples of this, many of them bridging Drupal to a 3rd party javascript/jquery code like all the image sliders. These modules serve an important function.

I haven't looked at the keepitsimple theme so I can't speak for that in specific. But I think, in general, it is important that our policy allow themes such as Blueprint where there is a good reason for using 3rd party, GPL compatable code/CSS.

Michelle

1. Theme names shall not start with a digit.

pass.

2. Themes hosted on drupal.org must be completely GPL.

pass. Everything in the theme is GPL.

3. The screenshot used on drupal.org must accurately represent the theme.

pass under the new @import solution. Otherwsie can be simply removed. or I can generate a new screenshot. I'll do this as soon as any other point is solved.

4. Mass generated themes are not permitted on drupal.org without substantial modification.

pass

5. 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.

Using the @import pass this one. But I'd like to better understand this one. I'm not sure what "crippled" means.

6. 3rd party libraries and plugins are acceptable.

mmm.. and you don't limit allowed licenses? Commercial libraries are allowed too? Interesting but weird.. not useful to my issue, anyway.

7. 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.

So, let's try one of the solutions

Solution A.
1) I remove any reference to the CC-BY-licensed css file (again I don't have any earnings in linking to that website.. I don't even know that company.. I simply know they are good at design). I also remove any link to the keepitsimple.css author from the project description.
2) I leave the @import and the README that explain people that if they prefernot to rely on my website they can download the file for free under the CC-BY license.
3) I create a screenshot without from that theme and not from my personal website (well. . the drupal logo is really horrible on that layout, but if you prefer this, why should I care? :-) )

Solution B.
1) I remove any reference to the CC-BY-licensed css file (again I don't have any earnings in linking to that website.. I don't even know that company.. I simply know they are good at design).
2) I create a GPL keepitsimple.css file to be included in the default distribution. The result will be the basic GPL theme.
3) I remove the current screenshot or replace with one created by the just downloaded theme.
4) I add to the keepitsimple project description a link to my website where I explain that the one included is the basic GPL skin, but they can download for free a CC-BY licensed css file to improve the result (I think this is like a reference to an advanced commercial version, just in this case is even better because you don't have to pay)

Solution C (not complying with your handbook).
1) Leave everything as it is.

IMHO the best one is C, but I will be happy to work on Solution A or B if you tell me now that it will be ok. I won't waste more time working on the theme if you don't want it.

Solution D:

Show two screenshots on the project page: one to the theme as it displays without the external code; the second as it displays with the external code.

The main issue here (as I see it, anyways) is that the theme as downloaded from d.o looks nothing like the screenshot on d.o. Non-technical users won't be able to make this work.

FWIW, things like blueprint, mollom, text editors, etc, are in a different category (IMO, anyways) because they are pre-existing projects, maintained elsewhere, in their own right. This theme clearly does not fit into that category.

But solution D at least eliminates the most egregious problems here.

The main issue here (as I see it, anyways) is that the theme as downloaded from d.o looks nothing like the screenshot on d.o. Non-technical users won't be able to make this work.

How is downloading the external dependency more difficult than downloading the theme itself? IMO the needed skill is the same. So if someone is able to download and install a drupal theme is also able to download the external CC-BY-licensed (free) zipped css. Am I missing anything with this? BTW I don't think this whole thread is about "easy of use". What is online now is really easy.

FWIW, things like blueprint, mollom, text editors, etc, are in a different category (IMO, anyways) because they are pre-existing projects, maintained elsewhere, in their own right. This theme clearly does not fit into that category.

I disagree. THe keepitsimple.css theme I bridged existed much earlier than I found it (it IS a preexisting project). I was looking for a new theme for my personal blog (the one that I finally used in the screenshot) and I found a good theme. Unfortunately there was no drupal port. So I did it. Then I decided to make it available to other users..

BTW while I'm replying I don't agree with your definition of what can be integrated.

For people accusing me of misunderstanding the issue I just want to notice that *I*, in #16, wrote that this was not a licensing issue but a policy issue.

So, once I know the policy, I try to understand what is the actual policy, who define it, what are the goals of a policy and why a group of people fight against a theme that I think is liked and useful to d.o. users. It's not me arguing about commercial links, it's someone else, so I have to reply with commercial links all around drupal org.
For what it worth, IMO the policy could even be that Dries decide what themes are beautiful and what themes are not, but when you work in the *open* you have to let people understand why something is allowed and something else is not. I think the community deserve understanding this stuff. If your policy is to allow only "blue themes" well, you can do it, the community of users wanting "green themes" will go elsewhere.

It is interesting to understand what exactly are the drupal policies so that maybe a business can be made around the stuff that is not allowed in the drupal website, too!

Do policy writers think that the keepitsimple theme is useless and no drupal user will find it useful or will find that downloading a CC-BY-licensed file will be offending or simply they prefer to keep the drupal theme listing "pure"? If I was the policy maker I would choose by usefulness.

From an old time internet and open source user and from a big open source contributor (just google my full name if you think I'm just trying to fool people into some business oriented gain) I think that is *weird* that mollom and other commercial website integration modules are allowed while for themes you push out a beautiful theme simply because it requires an external *FREE AND OPEN SOURCE* but not GPL compatible stylesheet.

re #100, yes, I know those are GPL. And I'm saying that should be allowed. Some folks here are arguing that it has nothing to do with license and themes should be complete and not have any 3rd party requirements. I'm saying that's not fair if we allow modules to do it.

So, again, the question is, is the 3rd party stylesheet in this case GPL compatible? If so, then it should be allowed because it's no different than what modules and other themes are doing. If it is not compatible, then it is not allowed on that reason, not because the theme is incomplete.

Michelle

I want to add that most of this thread exists mainly because unlike most drupal contributor I'm really aware of licensing and copyright and I pay attention and I try to inform users about what they can do and what they can't do. In order to be in legality and to be fair with copyright holders and users I perfectly explained in the project page what was need and who did what and who should be credited of each part of the resulting theme.

Instead, I just noticed that you don't care so much for other themes like:
http://drupal.org/project/ninesixtyrobots
Do you see any similarity with my port? Try downloading it and you will find that their "main.css" have a bunch of lines corresponding to the keepitsimple main css file and you will also find that images\dots.gif and images\quotes.gif for the d.o. tarball for that theme are the same that you find in the external CC-BY-licensed keepitsimple tarball.

Well, jjeff, author of that theme made 769 commits on d.o. so I guess he really own the copyrights for that stuff and the violator must be styleshout, otherwise I would be warried about anything included in the 769 commits to drupal org.

I'm sure there are hundreds of similar examples in drupal themes and modules and instead we are "bikeshedding" a correctly licensed theme published by someone that care about licenses and open source. It is funny that I found a possible violation exactly about the same content I linked in my theme and as the first result of the current themes page... http://drupal.org/project/Themes .. isn't it?

So, again, the question is, is the 3rd party stylesheet in this case GPL compatible?

The CSS file is licensed under CC license; therefore, it is not compatible with GPL license.

Forgot to notice that the first 2 themes are named "960 something" and the first rule included in WorldFallz handbook was no numbers at the beginning of the theme name!

BTW this is offtopic, it is just some more work for you, hope you are happy that I helped you identifying a couple of possible hidden violations of the handbook rules.

Those themes were considered in compliance with the rule as the theme does not use 960 (in its numerical form) in the theme itself. The project page is the only reference to the numerical value.

The above was already discussed in issues that took place over the use of numerical values in a theme. The issue at hand was that numberical values make php puke when used. Those that were not in compliance were unpublished. I don't have that thread handy. Will paste it as soon as I locate it. Kiam may have it handy.

The thing is, there's 2 issues.

I think there are more than 2 ;-), but I agree that this is not a single issue :-)

One is licensing. In the link to gpl compatible licenses provided at http://drupal.org/licensing/faq#q10, it is said specifically, that CC licenses are not GPL compatible and shouldn't really be used for code in the first place (see http://www.gnu.org/licenses/license-list.html#ccby).

You say CC should not be used for code and I agree: In fact a CSS+images are not code but creative style/design work. The fact that you use a text editor to edit CSS does not make it a programming language. They are simply style sheets.

So right off the bat, it seems to me this particular theme is not allowed (in exactly the same way several wysiwyg editor modules that bridged to non GPL compatible libraries were removed).

I don't know the history. If you removed wysiwyg modules bridging to commercial licensed libraries I think you did a good thing. If you removed GPL code that was violating the GPL terms then you did a good thing. If you removed GPL code only because it required some external free open source tool and instead you allow 3rd party and commercial site integration modules like mollom IMHO it is weird. YOu accused me of "mixing" arguments but here you 're back to a *module* example and not a theme example. Are we talking about GPL, laws, copyrights, trademarks? Or are we talking about policies? I think we agreed that the issue here was about policies and not about license compatibility from a legal point of view.

Those themes were considered in compliance with the rule as the theme does not use 960 (in its numerical form) in the theme itself, the project page is the only reference to the numerical value.

Nice to know! So the "handbook" should better report that "Short project name" shall not start with a digit, while "Full project name" can be anything.

not sure if the problem is with short project names in this case. rather, that if the .info file is named 960.info and preprocess functions and such follow the theme name then the theme won't work as expected or documented.

not sure numerics can be used in short project names?

@everyone: I'm new to drupal.org site, so I'm not sure who should I reply to.
1) Who is responsible for d.o. website? Dries? The Drupal Foundation? The Drupal COmmunity?
2) Who define the policies for content publishing? Is there a committee?
3) In case someone of the authors here have more power/responsibility than any other site member (like me) I'd like to know this.

Without these answer discussions could be a big waste of time.

E.g: at least 5 people here explained why the keepitsimple module should remain unpublished and they referred to completely unrelated laws/licenses/rules/documents that I've not been linked to when I subscribed to this community. Can anyone define its own rules/policies here or is there one of you here that I should listen for the truths? Someone complained about different policies between themes and modules, someone admits there are different policies, someone says that there is only one policy. I'm really confused.

Sorry, I don't know why the component keeps updating to "Mail".

1) we are
2) we do

we = all involved in the community at large who want to be part of the process. (This includes you)

Most issues like this one though are chimed in on by site maintainers and site admins and those active in the community. ie: forum support, irc support and the like.

The best place to start understanding the concept behind this thread or the need for these rules may be the group page worldfallz linked much earlier.

@112

1) The domain drupal.org is owned by Dries, the Drupal Association pays for the servers, and drupal.org is run by the community.

2) The policies for the CVS repository are defined by the CVS administrator after consultation with the community. I am the CVS administrator and I am not known to change anything WRT these policies.

3) From the way a community works, it is obvious that there are some members who have more responsibilities than others.

The CSS file is licensed under CC license; therefore, it is not compatible with GPL license.

I wonder why the lie that CSS and images need to be under a GPL repeats again and again here... could you guys please read the FAQ http://drupal.org/licensing/faq *first* and than comment? THX. The Drupal association lawer have written this FAQ as I know, so do not try to add your own wishes - this is not correct!

Again - CSS and Images are DATA and there is no need that DATA is offered under a GPL license. This is not the case for modules, as they will *always* implement hooks and therefore run in the memory with PHP and use core code. This need to be GPL, but NOT the themes CSS and images!!!

Additionally we should be happy if others develop on d.o as they share their code. A theme can be a complex package of code and we can only LEARN from it - nevertheless the CSS files may be missing. Only take a look into Acquia theme files (for e.g. template.php) that is really one of the most complex themes I'm aware about on d.o. Only to learn from this many theme overrides, variable declaration and so on and so on. For this reasons we should always be *happy* to read this code - if a theme works well or not is complete or not - if we have the GPL part of the code we can benefit from it! There are so many broken themes and modules on d.o never ever seen a light and will not... only with broken DEV versions. If people download this sh** they also expect that it works and looks like the screenshot, but it doesn't.

OT: How about unpublishing the iDrupal theme. I was never able to get this working and it does not looks as it's advertised on project home. Aside this theme makes me downloading an iDrupal module, an iDrupal theme and an iDrupal iPhone app... if this is not difficult to implement... 3 pieces to get it working and than to find out it's looking completely different was no fun and a waste of time, too.

Currently we only have a hasty decisions made by a one or may handful of people here - judging something they do not like as they are in love with the GPL and no other license and not aware about the Drupal licensing FAQs. Sorry, but this is my impression. Naming 5 active people as "we" is not very helpful without any written rule. Have this 5 people asked the other 500.000 d.o users? Are they the committee? I believe not. I also do not like to read handbook pages written by one person that is in love with the GPL and do not accept anything else nevertheless it's written to be acceptable in the FAQ. This is personal interpretation only and a wrong, too.

hass

This is an issue with distributing from drupal.org. To be distributred from d.o the theme must be GPL compatible.

If you, or others want to create a non GPL compatible theme and distribute it from your own site, or another site you are free to do so. That is what the licensing FAQ is discussing as far as I can tell.

I don't understand how the lines keep getting blurred here.

The iDrupal theme is GPL and thus any one can alter and fix it.

@VeryMisunderstood: the theme comply with the GPL... always keep this in mind, please!

It's been stated multiple times that CC is NOT compatible with GPL. I'm no licensing expert.

I've explained my reasoning for my +1 on removal twice, regardless of licensing.

Also of note, the handbook page that includes the rough draft may have been collated by one person. Though the draft was born from a discussion with multiple people in threads already linked to this issue. Thus try not to lay this at the feet of the person tasked with the collation.

Lastly, and to clarify, we = those able to comment and make a case or provide an argument. You are also included in the "we". From this issue and the other discussions that have taken place "we" are trying to work out a framework for a ruleset. Obviously you disagree with much of the reasoning being used, I respect that.

#115 thank you for the answers that seems to me more correct than #114

3) From the way a community works, it is obvious that there are some members who have more responsibilities than others.

I'm used to meritocracy and other models. That's why I thought there was someone with more powers. And that's why I asked who, between my interlocutors, had more powers than me ("me" as the alias of the casual drupal member with no special power).
I'm not saying that we all should be equal or advocating a model better than another, I'm just trying to understand who should I trust when we talk about policies. I wonder if drupal have something similar to the Apache FOundation publishes the "rules" (http://www.apache.org/foundation/how-it-works.html) and then you can find public records for each vote that took place between foundation members (and not every users) and you can see learn about each committee member list and their powers.

I understand that the whole issue here is going off topic, but I remember I read a lot of documentation before starting committing to drupal and I'm almost sure I didn't violate any rule I read when I signed up: on the other side I find many users (and until they tells me their roles in the d.o community from my point of view can only be simple users bringing their personal opinions on the table) speaking about policies. Now I'm not a newbie with regard to licenses, license compatibility and policies so I get a bit upsets when I understand people reply me with false-arguments for lacking knowledge. I wrote that this was a policy issue at the very beginning of this issue but it took a while to have a link to a group with a "draft" about a policy. I was not sure how much credibility/value to give to a group thread (this has no "officiality" to my eyes, because of missing inbound links from the rest of d.o, mainly, I believe...). I've already partecipated in communities where every member had his own "community policies" in past, so I'm just moving to understand.

The fact that after 50 and more posts in few hours there are still people (http://drupal.org/node/577446) thinking that I uploaded non GPL code to the CVS repository make me a bit sick.

It's been stated multiple times that CC is NOT compatible with GPL. I'm no licensing expert.

This is incorrect if you speak about CSS and Images (this is DATA) in themes and we only speak about them here as the rest of the code is GPL'ed. Read the FAQ, please.

bago,

that is what everyone involved is trying to come up with a solid ruleset. That was what started this issue as well as other issues.

Obviously, there are very polar opinions regarding how to move this forward and get the rule set published. Some feel it should be allowed to be a free-for-all with what is distributed from d.o as long as the licensing FAQ is adhered to (regardless of any upload/distro policy that is being worked on) others feel as strongly that this shouldn't be the case.

@bago: I believe you can only trust the license FAQ as this is written by a lawer under contract of the Drupal Association. There is a list of the Association members at http://association.drupal.org/about/staff... Gerhard seems one of them, but I'm not sure if the rules and lawyer part is his responsibility. I cannot speak for the rest in here - maybe some more are part of this team... but we may also read some "in love with the GPL, but not aware about the rules" in here. I cannot say for sure - so don't hurt me, please.

confusing the d.a with d.o doesn't help things and ignores Gerhards comment with regards to d.o in http://drupal.org/node/416022#comment-2041436

drupal.org is run by the community

If it helps (and since the question continues to come up), I am merely a site maintainer here on d.o who wanted to weigh in on this as a community member. My vote shouldn't weigh any more or any less than any one elses with regards to this issue or any other on drupal.org. That said, it's why it should not matter what any one persons title may be on d.o

My only interest in this issue is for the standard user (most important to me) and what to do when these issues arise so I know how to handle them in the future based on the rule set that comes from this and similar discussions.

While I realize that there is no way to make everyone happy all of the time. Only some of people happy some of the time. I continue to ponder this issue and here is what I've come up with in an effort to make BOTH camps happy.

What about a discussion that includes CC themes?

example:
allow them to be uploaded and give them either a CC taxonomy term or maybe a non-GPL taxonomy term.
Those intersted can sort by GPL or CC.

As far as I understand, the long-standing policy of Drupal CVS is that every single thing checked into CVS must be GPL. This is simply a policy that makes it easy to be consistent and easy to avoid misunderstandings about licensing for anything in CVS. Thus, this policy is unlikely to change.

That being said, clearly this thread shows (as we all know) there is a demand and need for reasonably centralized ways to distribute themes that are free but have some non-GPL parts. See http://design.acquia.com/ for one such effort.

pwolanin,

The crux of this problem here is that what is checked into CVS, in this case, with the keepitsimple theme is GPL. However it is void of a real world working stylesheet. The stylesheet is required to be downloaded separately at which point the stylesheet is CC and has restrictions even though the rest of the theme (downloaded from drupal.org) is GPL.

As loathe as I am to subscribe to this thread...

It looked like an open-and-shut issue, but bagos arguments here have convinced me, and I think he's actually right.

Although there (at first) seems to be an element of bait-and-switch, the published policies, and the precedent from other existing modules do allow 'bridge' modules or third-party enhancements to be referred to.

What is left is the 'good faith' behaviour, and community attitude to whether a contribution is 'worthy'.

I believe from bagos contribution here, that what has been done is in fact in good faith, and respectful to both licenses, as much as possible. The contribution, building on a CC base he thought was valuable, is not commercial or excessively mercenary. Linking to your own or other sites in the course of documentation is not evil, and is one of the foundations of keeping open-source developers healthy. Don't pick on that (either of you)

As arguments in this thread have shown, either:
- distributing the theme with a crap placeholder css
- linking absolutely to the offsite file
- publishing a crap screenshot of the no-css result
Would all be technically allowed (I think the offsite link should not - for spyware concerns), but each of those approaches would be worse than being up-front and saying "this theme builds on a useful framework that cannot be hosted here for licensing reasons, get it here if you want"

I disagree with hass however - a "theme" comprises "look and feel", and this distribution without css has neither, therefore is not a usable theme as-is. That argument doesn't work. Still, as a theming contribution or framework, it is at least as worthy as many other ugly or starter themes or trivial API-only modules.

...Provided the limitation and instructions are clearly stated on the project page.

Have a look at the Gutenberg "theme" by eaton - which I think is an amazing and positive approach to expanding the Drupal theme library. That thing cannot perform as advertised without requiring a download of third-party css. And it's great for that! We need more theme framework cross-pollination!

Sorry, a change of the cvs policy wrt non-GPL stuff is not going to happen. It introduces too much of a hassle without a tangible benefit.

I gladly do without themes that aren't GPL on drupal.org.The authors of such themes need to find other ways to distribute them.

based on Gerhard's comment we can moved this back to fixed.

The above was already discussed in issues that took place over the use of numerical values in a theme. The issue at hand was that numberical values make php puke when used. Those that were not in compliance were unpublished. I don't have that thread handy. Will paste it as soon as I locate it. Kiam may have it handy.

This has been discuss in #501364: Theme devavrata (and sub-themes); at #501364-35: Theme devavrata (and sub-themes) is reported why 960.gs has been accepted; bear in mind that the theme short name doesn't start with a number (and that is the second reason the theme has not been unpublished).

I don't understand, anyway, why are we talking of this, when the topic is another one.
To me, it sounds like if a thief would pretend to not go in prison because somebody first accused of homicide is not in prison anymore. You can think that we are not talking of prison; that is true, but we are not talking of how the theme has been named too.

I will add that to publish projects on Drupal.org is not something absolutely required; Drupal.org CVS committing must follow some rules that has been decided (and that will be decided when new trends come out) to avoid some misuses of the repository.

Thats already been explained, tested and explained again. see: http://groups.drupal.org/node/24465

This issue of numerics in full project names should be discussed in a new thread, I think.

heh, we posted at same time. readjusting status.

@VeryMisunderstood: I was referring to bago, who seems to like to find not existing problems just for the purpose to change the topic of this thread.
I agree that the numbers question has been already defined, and it is part of another issue. I reported the link because I was said to have it handy (and for completeness of the discussion, to avoid that somebody reading this thread would think different projects are handled differently for no reason).

Yes; it seems we keep crossing each other. Next time I will shake hands. :-)

Sorry, a change of the cvs policy wrt non-GPL stuff is not going to happen. It introduces too much of a hassle without a tangible benefit.

I gladly do without themes that aren't GPL on drupal.org.The authors of such themes need to find other ways to distribute them.

Gerhard, I understand that it is difficult to really understand what's going on here, as the thread gone offtopic multiple times, but I don't think that a change to CVS policy is needed. Please can you explain what file in KeepitSimple was non-GPL? I repeat that I never committed any non-gpl file. Insisting that this issue should be closed because the project incluses in CVS non-GPL code is not a solution to this thread.

If you want to close this because bridging modules to creative commons styles are not allowed by Drupal policies then you (I guess) have the powers/right to do this, but please be honest with the motivation.

It's ok to keep this closed while the policy is better defined here: http://groups.drupal.org/node/24465 because this is not the place to understand or define policies. I will take care of reopening this once the policy has been better defined.

I also add that this issue title is wrong and misleading. I'm the author of the bridging module and I required external download for licensing issues not for business or technical reasons. I'm not the author of the CSS so I'm NOT trying to make money with this creative common external download (and furthermore the resource is FREE/OpenSource otherwise I would not have published the bridging theme itself). Most people here understood this, but I'm not sure that the policy enforcers have.

I'm the author of the bridging module and I required external download for licensing issues not for business or technical reasons.

That is what the title says: theme requires download of non-GPL files for non-technical reasons.

That is what the title says: theme requires download of non-GPL files for non-technical reasons.

If you read the whole thread I'm sure you got that many partecipants thought that I by purpose authored a splitted theme under 2 different license with the very purpose to create a business. Instead my choice has been not a choice but my only option. IMHO it is important, if we are analyzing the MERIT of the issue, to understand that I'm not trying to hack the d.o site in order to make money, I just made a GPL bridge theme to a FREE CC-licensed theme and I shared it. The title is misbehaving because it seems the policy is not about technical or business reasons, so it induce people to think I'm trying to fool users while I'm not.

I read the title as saying that the theme required the user to download a non-GPL file when it is not technically necessary. What you add is a personal interpretation of the title that other people could not share.

I changed the title, and removed the business part. I don't see any business reason to make a user download a file that is licensed under CC; if there is such reason, we should at least document it (differently, it is just a supposition).

I hope that we can now focus on the topic of this thread (which has been already marked as fixed, though).

I hope that we can now focus on the topic of this thread (which has been already marked as fixed, though)

Well, the fix motivation is about non-GPL content in CVS and it is clearly not the case, that's why I asked what file violates the GPL (if some file I committed contains violation to the GPL I probably don't understand GPL so well as I thought and I hope you can point me to let me learn).

While I don't think there are GPL issue with what I committed, I understood some of the "guru" comments about the policy and that's why I won't reopen this one until we'll have a better common understanding of the best policies for d.o. Nobody here thinks that the "no-GPL code in CVS policy" should be changed and I never suggested this. This simply is another issue. It seems there is no agreement on the SOLUTION for this issue, while many solutions have been suggested. I tryed to understand what solutions were officially solving the issue and publish back the theme and what not, but I had no success. Gutenberg theme is still there, so I'm almost sure I can tune KeepItSimple in order to satisfy the policies (once I understand better the policies)

So I invite everyone interested in the "themes policies issues" to join the dedicated group here: http://groups.drupal.org/node/24465

@hass, @dman, @VeryMisunderstood and whoever understood/agree that there is no non-GPL stuff in CVS for keepitsimple and care about a policy to allow or disallow "bridging" themes, I suggest you to speak there.

@VeryMisunderstood: I don't think that the comment of Gerhard not to commit CC code to CVS prove this issue as fixed. It was your personal idea a few comments before, but we do not need to change this CVS policy! bago don't like to commit CC code to CVS, he only like to tell people they need to download 3rd party files from somewhere else to get the theme looking more great - like other modules also does if they require 3rd party libraries.

Gutenberg is a raw (unstyled) theme intended for use with CSS-based Movable Type layout styles.

Beeing nitpicking - the screenshots also sounds wrong as the text tells us the theme is *unstyled* out of the box. Another must candidate for unpublishing. I haven't tested the Gutenberg theme, but maybe someone else can confirm. http://drupal.org/project/gutenberg

1. It's very annoying that we discuss all again and again and we are not able to get some understanding that the GPL rules haven't been broken by bago.
2. As already said - we should be happy to share code - however it's done.
3. If this is now an quality assurance thread that tries to make sure themes are working out of the box - then we need to unpublish *many* more themes. But please do not discuss this again in this thread. It's not part of this issue.

I believe that the "policy enforcers" enforce something that is not yet written and try to implement a rule that does not follow the GPL logic that allows what bago have done. Commenting on this by saying it's a "privilege" to publish something on d.o doesn't count for me as the theme is still a theme like many others.

User experience is important, but if we have clear statements on project home that there is a required download to get a theme fully working - is really enough. It's 100% the way how many modules are working and I see no reason why a theme is an exception. I have also not yet read any good argument that there need to be an exception - as I'm also have no good experience with some bridging modules only as a side note. I also think that the experience argument is only pushed forward for the reason that there is no good argument to disallow themes with splitted data parts what is fairly allowed by the GPL (but some have not understood this).

Without understanding the GPL that is the basis for Drupal and the community enforcements nobody should comment here.

This thread is past it's due date, it's closed. Please continue the discussion on that g.d.o group.