Thanks
Dallas

The one area I would comment on though is with respect to you discussion of JS not being “tainted” by Drupal’s GPL. One could raise an argument that code which interacts with Drupal’s JS should be covered under the GPL. This would include anything relying on jQuery and possibly the JS settings. Quoting from the licensing FAQ on drupal.org.

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.

http://drupal.org/licensing/faq/

This would probably cover a large proportion of JS written in modules, whether they be contrib or not. Given the way most JS is used with Drupal these days I’d say that it probably would be covered by the GPL. However, I believe that it would be possible to write non GPL JS if it interacted with just the content of the page.

So in general, if you are looking to use copyright law to protect a business model when using Drupal it looks like i can be done with images, CSS, documentation (video, audio, text) and non executed config. This is a good fit for theme developers and training providers.

I’m not a lawyer either so please don’t take this as legal advice.

(Simplified,) The GPL says that you must provide the source to a GPL-licensed software application to whom you give a copy of it. The key here is the words “software application”, and what defines one. Early on, a key milestone was the creation of the Lesser GPL (LGPL), which provided for creating GPL-type add-ons that could execute as a run-time-loadable (/executable) component of a larger, non-GPL software applications without “tainting” the larger non-GPL application. This established a precedent (roughly) by describing a “software application” as that which was executing within the memory address space being used by a (single!) computer to perform its function.

As time has gone on, this got even slightly trickier when GPL applications is being used to provide functional web-services (SOAP, REST) interfaces to non-GPL applications. Again, since the web service is executing outside the address space of the accessing-application, the accessing-app is not tainted by the GPL of the web service provider’s code. (Web services would be chaos if the GPL did taint accessing-applications!)

Now apply this to a CMS, e.g. Drupal, and the browser of a visitor:
- When Drupal executes, it starts by executing index.php from Drupal, which is GPL licensed. This sets the address space, and thus the license for the remainder of the PHP files that are loaded – thus, all must be GPL. (Note: There’s a special provision for the PHP interpreter; the interpreter’s license is not determinative of the license of the code it executes, even though Drupal is (technically) executing within the address space of the PHP interpreter.)
- When the Drupal-rendered page is delivered to the browser it is the application execution address space of the browser that “runs” the CSS “software application” sent to it by Drupal. Drupal is not executing the CSS – the browser is. Ditto the JS, images, and for that matter, the HTML (e.g. an HTML 5 “application”).

(Technically, the Javascript that is part of Drupal (core or contrib) sent to a browser by Drupal is not actually being tainted by Drupal’s GPL. It could – in theory – be non-GPL. It is only a Drupal project requirement that JS checked into / hosted (for download) on Drupal.org be licensed by GPL. So, for example, if a company wanted to distribute their own Drupal distro – and did not care to host this distro on d.o for download – that company could include non-GPL Javascript. (This happens commonly across the non-Drupal open source landscape, where various companies sell “packaged distributions.”) Or, similarly, a company offering a SaaS solution might provide a module for Drupal (GPL, and hosted on d.o) which does not directly contain JS, but instead causes the visitor’s browser to do an http GET of proprietary JS from the company’s (third-party) SaaS service (which is then executed in the address space of the browser and talks back to that originating SaaS server).)

Hopefully this is helpful to those reading this thread.

Any advice for setting up mobile sites? Well I tried my best to share my experiences in these articles. These days I would:
- write a single responsive theme (based on Omega)
- use responsive images
- use a device global variable for getting out of sticky issues server side. ie block placement with context using the device variable as a condition. Mobile Tools does this I believe.
- use that device variable as a part of a cache key in Varnish
- serve both sites from a canonical domain and forgo the use of m.example.com

This would put you in a good position for a multisite or single site install.

Sorry it has taken me so long to get around to replying to your original post. When it came to getting the canonical metatag in I’m pretty sure I just hacked something up. It might have gone in a hook_init or it could have easily gone into the theme layer as well. You could write your own “mysite_mobile” theme and put the logic into mysite_mobile_init() function.

I think that the Drupal community has moved on a bit since I wrote these articles. Responsive design is all the rage. If I was to do a mobile site these days I would try to do it with a single theme and make it responsive. I still like the idea of a device global variable which could be used for placing “desktop” blocks when needed. Many frown on this but I don’t see it as a big problem. You have the caching issues still to deal with.

I wrote a bit about how I imported it over this way: http://cruncht.com/361/uriverse-dbpedia-drupal-case-study/

It was a labour of love which took a lot of SQL hacking to get to work. I could not afford to do node_loads and node_saves for 13M nodes so I opted to do the DB inserts directly. That way I could get 1000s of inserts a second rather than 10. I learnt a lot about MySQL, indexes, efficient queries and how to import stuff as quickly as possible. Also, how to recover from where you left off when a long running process died. All up it took a couple of months of tooling around with code and SQL. Once all of it was in it took another couple of months for Solr to index it all

I wouldn’t recommend this approach as it is a one hit import which takes a lot of effort.

If you have a smaller dataset then you have a few options.

Firstly, the migrate module couple be a good way to go if you have complex relationships and IDs to maintain. I really want to get into this big time one of these days. Imports will still be slow but you have the most flexibility.

Secondly, you have the feeds module. Good if you have a flat data structure and one to one mappings. You might be able to get away with crafting up a CSV and importing that way. I believe that Lin Clark has some good screencasts with Feeds and SPARQL (IIRC). Theres a lot of flexibility in Feeds too so this might be an easier option for you if you like wiring up config instead of writing code.

Thirdly, you can go old school and just write your own PHP script and do it with node_saves. Fire it up with “drush scr”. I like this approach because it feels natural to me. However, Migrate gives you a lot of nice goodies such as rollback, tracking IDs and making stub objects which will save you from pulling your hair out.

Finally, you have SQL inserts if you are handling a very big dataset. This will be more tedious now because of the way fields is handled. ie. a lot more inserts over more tables. You’ll get to know Drupal’s schema well though.

Oh yeah – another option is to just keep Dbpedia in a triple store and then provide a view onto that. That way you have more chance of keeping up with updates from Dbpedia. It isn’t updated that often though.

You may also want to take a look at Freebase. They have a nice API, up to date data and links to Dbpedia as well. You might consider importing from there using the search, image, mql etc apis. I’ve been doing a bit of that lately and it is quite pleasant.

All the best with it.

I am interested in learning more about how you imported DBPedia into Drupal. I am attempting something similar for a small subset of Wikipedia – but using Drupal 7.