Another screencast of yours truly: this shows the Plasma netbook shell running on a bog standard Asus EeePc 1005Ha.

It can be seen the new neat animations of the search and launch interface when results are loaded. What's neat is that it seems to run quite well on this pretty basic hardware and animations are just as smooth as they should be :)

OGG version

Like my esteemed colleague at KDAB I’m also now a Nokia Certified Qt Developer!

Given that I just was an assistant on my first KDAB Qt training course in Berlin last week I’m happy I haven’t let down my fellow Qt experts at KDAB; I’m at the company meeting in Iceland so would never hear the end of it if I’d not passed…

There’s been some horse riding (which I boycotted in favour of cake), whale eating (tastes like moist beef and was a non-endangered species, absolving my guilt), soaking in the Blue Lagoon and much banter has been had. I’ve also been fighting with our time-tracking tool, Charm (which is in KDE SVN) to try and get Carbon and Cocoa events working nicely side-by-side (Carbon is the C-based API that is not supported for 64-bit applications, which are the default on 10.6). I was pleased to see that Qt Creator (my current C++ IDE of choice) also supports limited amounts of Objective C which has made things slightly less confusing for a certified Qt Developer

So i just got a mail saying i'm now a Nokia Certified Qt Developer. Great!

… not just a marketing guy. :-) During the Qt Developer Days in Munich, I took the Qt certification exam (actually as one of the first people to take it). It was my birthday, so they let me pass:

Also, right now I’m in Reykjavik, Iceland for the KDAB company meeting and 10 year anniversary. Preliminary conclusions: Watch out for roastbeef, it tastes like whale, riding on a horse feels like riding a square-wheeled bicycle (but slightly more scary) and having infinite amounts of energy under your rearside makes for interesting and relaxing uses and given a large-ish island with tectonic and seismic activity, you’ll find the capital at the most likely spot for an earthquake.

On Wednesday the Washington Post’s “Security Fix” blog had a small item on privacy issues with the smart grid. It was most interesting for me because of the graph that was included: by looking at a simple metric (power draw in the house) one could reach conclusions on what was happening inside. Breakfast, lunch and dinner can be spotted. This isn’t much of an issue if the data is available only to the power company, stored securely, and applied only to its intended purpose for which it is collected. Presumably that’s to optimize power delivery.

But when the information is used outside of that context, then bad things can happen.

This kind of concern applies to all kinds of metrics that indirectly show what is happening inside a closed box. Consider an active developer on software project where the source repository is available publicly. This applies to lots of them — and CIA.vc makes relevant stats for many even more public. By looking at time stamps you can find out roughly when the developer is active. How accurate this is depends on the style of development, but I know I’m a commit-early, commit-often guy so you can (or used to be able to) find out when I’m awake by watching commits. No commits? I must be elsewhere. Commits skewed by three hours? I must be in Brasil, hacking.

Even that information isn’t all that bad, although it’s a derived piece of information that possibly wasn’t intended to be public. But you can use it for nefarious purposes (e.g. housebreaking). Power consumption of an encryption chip was once used to determine whether it was doing a multiply cycle or an add — and knowing that revealed bits of the key being used, and so extracted the key from the chip. That’s the kind of ancillary information leakage that we can also worry about.

All in all I think it comes down to: data collection technology isn’t bad per se, but the safeguards around the collected data and the purposes to which the data is put might be. Privacy then is a matter of trust in the people that hold the data to do the right thing (regrettably humans are susceptible to temptation).

I’ve very pleased to announce that my work on Phonon to integrate support for PulseAudio has now been committed to trunk and will form part of KDE 4.4 \o/

There were a few teething problems due to some last minute merges I did (which I clearly didn’t test properly – my bad) and which I then went on to mis-interpret which led me to commit two rather silly things in phonon (a revert and then a revert of that revert!). What can I say… I need more caffeine obviously!

The slightly annoying news is that the support needed for this to work is not yet in a released version of PA. I do however have a simple patch for you here, that distro packagers are welcome to stealliberate from the Mandriva SVN. If you do this, you’ll also need to apply this minor patch to phonon:

diff --git a/phonon/CMakeLists.txt b/phonon/CMakeLists.txt
index c5ce57a..50a3851 100644
--- a/phonon/CMakeLists.txt
+++ b/phonon/CMakeLists.txt
@@ -8,7 +8,6 @@ endif (PHONON_BUILD_EXAMPLES)

 add_subdirectory(experimental)

-set(PULSEAUDIO_MINIMUM_VERSION "0.9.21")
 macro_optional_find_package(PulseAudio)
 macro_log_feature(PULSEAUDIO_FOUND "PulseAudio" "A cross-platform, networked sound server." "http://www.pulseaudio.org" FALSE "" "Allows audio playback via the PulseAudio soundserver when it is running")
 macro_optional_find_package(GLIB2)

Just so that it recognises your PA build.

There don’t seem to be any specific bugs yet, although I am dealing with something relating to streams going AWOL with Xine, but I’m not sure the problem is in this code. Further testing and feedback is much appreciated. Feel free to report problems to me directly or assign bugs to my kde (at) <this domain> account in b.k.o.

Have fun!

Fitting my earlier post about rating and stars in Get Hot New Stars Stuff , I just listened to “Dead Stars” by Covenant…

So this is all about stars. At first I wanted to answer the comments individually, but there are just too many.

A few points keep coming up:

• The number of items in the Hot New Stuff Dialog is limited: not any more, the dialog will fetch more items if you scroll down. (I’ll do a screencast soon, promise!)
• Updates: There is a category that shows only installed items, here it’s easy to update individual ones. Applications will have the possibility to query for updates without invoking the gui at some point, probably not in the initial release though.
• Displaying the Rating of an item will most likely be the “five stars, just as in Nepomuk/Dolphin” variant. It shows the numerical rating in a tooltip (yeah, we all love numbers, don’t we?? though I would still download what I like, not what the rating tells me to like). I stretched the scale a bit, since ratings from 0-20 and 80-100 are nowhere to be seen.
• The user will be able to rate items, but only gets to choose “I like it” or “Don’t like it”, same as on openDesktop.org.
• Different categories (as seen on openDesktop.org for example) will probably return, I would like to see some mockup how to integrate that into the dialog without having lots of combo boxes around…
• The scrolling is badly broken, I really need to look into that.
• It’s getting late, I should be in bed

Today I updated the KDE Licensing Policy with a couple of changes following requests from folks. Most notably Creative Commons is now allowed. This is only for standalone media files (such as an image for a splash screen) and not for anything which might want to be mixed with GPL material such as icons. "Attribution-Share Alike 3.0 Unported" is the version allowed. The other change is requiring BSD licencing for CMake modules, which brings the policy into line with existing practice.

The other day I met with a couple of local entrepreneurs whom Chani had met at the recent Qt Dev Days in California. The four of us gathered around some tasty vegetarian vittles and discussed small devices, Qt and Plasma. It was a good time and we found a lot of common ground .. including agreeing that Javascript is a great language for writing little user interface elements quickly that will run reliably.

In that vein, I've been working on getting the Simplified Javascript API for writing Plasmoids ready for creating more than just toys. To that end, all the Plasma user interface elements (pushbuttons, etc) are available including the complex ones like the TabBar, Animations are fully supported, we have AnchorLayouts (and maybe even GridLayouts soon) in addition to LinearLayouts and, perhaps most exciting, we now have the ability to load API extensions.

An API extension is a security controlled set of functions and objects that are loaded on demand. These extensions are requested by the widget by listing the required and/or the optional extensions it wants loaded in its metadata.desktop file. This way, even prior to the widget being loaded we can know what it will want. The Simplified Javascript Engine then decides if the widget will actually get that extension or not.

There are a set of built-in extensions currently defined: FileDialog, LocalIO, NetworkIO, HTTP and LaunchApp. They each do what you expect, with NetworkIO being a generalization of HTTP. I'm busy implementing each of them between now and the end of next week. We aren't limited to these built-ins, however: any QScriptEngine extension plugin can be loaded, security willing, just by listing it in the metadata.desktop file. This means that widgets can be extended with arbitrary functionality.

The security framework is still in development, but all the hooks are there with some of the pieces in place now. Most importantly, we know exactly how we want to implement the missing bits. I'll be working on filling in the gaps as I can, and hopefully when Rob returns with hacking time again (or someone else steps up in the meantime) that will go a bit faster.

The other important bit has been to actually document what the Simplified Javascript API provides. The relevant file in kdebase/workspace/plasma/design/ has been morphing into increasingly comprehensive API documentation. What I need to do is turn this mammoth file int a nice set of web pages that I can add to a revamped plasma.kde.org. Any one out there up to doing some HTML slicing and dicing?

There are also a growing number of examples to augment the documentation and which are just begging for Techbase tutorials to be written around.

Add to this the progress being made with Plasmate and the ability to script plasma-desktop itself with Javascript and things are looking better and better for Javascript in 4.4. Huzzah.

In an unrelated side note, Markey's blog entry on finding a balance in software configurability is really well written and makes several excellent points with great clarity. A must read if you haven't already seen it, in my humble opinion. :)

The Ubuntu Developer Summit is happening this week in Dallas. The theme of the discussions is LTS and what it will take to have a release in six months which can be supported for three years hence. We've been having sessions on packaging, development, bugs policy, translations and more. You can find the schedule and how to take part in sessions on the summit website, there are icecast streams for all the rooms. The Kubuntu specs are on this wiki page still works in progress of course. It's going to be great to have a KDE 4 release suitable for LTS, just six months to do it!

Some of the Kubuntu Team take to the ice rink

Things have been crazy busy lately on every single front in my life. This has come at the expense of not blogging much at all, which has sucked. So much has been going on, a lot of it very interesting and fun and which I would have liked to share with you as it was happening. Such is life, but we need to catch up. So grab a coffee (or whatever you prefer, tea maybe? :) and let's catch up!

I ended up at a fencing competition as a spectator this weekend cheering on S. (and editing text from the sidelines for the Akademy sponsorship brochure that Claudia, Kenny and Nuno are working on; it's looking great!) and then out for dinner with old friends here in Vancouver the day after that. I also completed one of the last I-just-moved-to-a-new-province tasks as well: I got my car registered and insured with the locals here in B.C. Turns out that my B.C. drivers license expired the same year I got my now previous car insurance in Alberta, which led them to give me 14 years of safe driving and pushing me into the highest discount bracket (and one year away from the highest rating bracket over all). Still, it was one more thing that filled in my schedule.

The KDE promo team is in high gear as well, and that's keeping me a bit more busy. The promo sprint they just had was a great way to punctuate the increase in activity we've been seeing. A Dot story will apparently appear sometime soon detailing what went on at the sprint, but there have already been a number of blog entries on planet.kde.org about it. One outcome of the sprint is that we're starting to organize our communication strategies a bit more. This was not, by far, the most important result of the sprint, but it's the one that's kept me busiest. I was really impressed, and surprised even, to see how many people were at the promo sprint and, as a result, how much they accomplished. But when you have a larger group of people, you need to step up the coordination as well.

I remember the first KDE release announcement I ever wrote. It was just me and a text editor and Coolo reminding me it needed to be ready in a day or two, latest. My how things have changed (and for the better).

I've also been hacking my brains out in a few different areas for 4.4, though I'll blog about some of that later. With the feature freeze behind us, it's become apparent just which items are going to drop off my "can do for 4.4" list, however. Most notably, I'm not going to get to notification queueing or a replacement for the desktop zoom in/out feature. These will have to wait for 4.5 as I work on other items that I hope will have bigger pay offs for 4.4. The items that are being left on the cutting room floor for 4.4 will fit in well with 4.5, though, I think.

I've already come to a determination as to what the focus for the Plasma family will be in 4.5. We've already discussed it a bit on the mailing list, but I won't be announcing it publicly until Tokamak IV which will be in February in Nuremberg. We'll be toasting with the OpenSuse people (congrats on 11.2, btw!) and hopefully enjoying the company of a few friends from elsewhere in industry as well. Most importantly, we'll be setting the Plasma agenda for 4.5. Much love will be had. (Or something, it just sounded like a good ending.)

I'm also in another "prep for shows" cycle. I'm going to hopefully be making it to Fedora's FUDCon in December (congrats on F12 and the KDE spin, btw! Seems to be the most popular spin by a kilometer! :) and am gearing up for one or two others.

One show that caught my eye is the Linux Audio Conference. The people involved in getting it going are quality folk (a big shout out to Armijn!) and if there's an area that F/OSS needs attention it's audio. Our stack is a mess at the moment, and not because of API issues but because we're doing a poor job of system integration, shoving features out to our users way before the software is ready for that and the like. I'm hoping that LAC will be well attended and some positive, useful results that will lead to improvements in how we handle our audio stack with care and respect will emerge as a result. I think it's really interesting that LAC will also focus on using media and will be striving to get media content creators there as well. This should help widen the scope beyond infrastructure navel gazers when it comes to audio and get a lot of great feedback as well as grow our shared community around F/OSS audio.

Now, I couldn't mention shows without talking about the most important gathering in the next six months as far as KDE is concerned. Yes, I'm talking about Camp KDE. I'll be there and I plan to bring a truck load of hugs and inspiration with me. I hope to see you there!

This evening, #kde-edu on IRC was host to a meeting between various KDE-Edu developers and interested parties, concerning the state of KDE-Edu, and future directions. Whilst annma was unable to make it, Nightrose did a great job chairing the evening, and the meeting was very productive.

The reason I write about it is not due to KDE-Edu per sé (though watch planetkde.org for other people's posts on the topic), but rather about how people can help out in KDE for anyone thinking of doing so. Simply put, under the right conditions, the barrier for helping out has negative height, i.e. helping out is so easy that it's almost easier than not doing. At the meeting (bearing in mind I'm not an edu developer) I was planning mainly to watch, maybe contribute any observations I'd made, and so on. But, when it turned out I'd been doodling a list that people would like, I found myself taking minutes. Similarly, fregl realised he'd just volunteered to mentor people doing junior jobs in KDE-Edu, and so on and so forth.

So, I'd encourage anyone lurking who'd like to help out in KDE, in any way - development, documentation, promotion, feedback, testing, etc. etc. - to have a chat to people already doing something along those lines. Heck, bring a friend, too. And, who knows, you might find the right job for you has landed in your lap.

In the week of November 2nd I travelled to a little village in Italy called Orvieto. The reason for going to this lovely town is two conferences in a row.
The first one is the OpenDocument plugfest. The second is the openOffice.org conference, both of which were new experiences for me.

The ODF plugfest is a meeting where different implementors of a standard come together and come up with user scenarios and test how well they port between the implementations.
So you’ll see a document created in KWord being opened in OpenOffice.org and Microsoft Office and investigations started when the resuls are not as expected.

I did a presentation at the event of the progress made in the Qt (QTextDocumentWriter) and KOffice implementations of ODF and naturally the Maemo Office reader and last mentioned the Nokia sponsored officeshots.org node we are preparing.
The next day I had another presentation where I showed an interoperability issue with right-to-left languages. Several bugs were found in OpenOffice.org and MSOffice and a discussion followed to share the concepts of right-to-left text and (visual) text-alignment. These are tricky things so its important to all have the same ideas on how it should work.

The event had lots of talks, essentially making is clear we are not the only ones doing ODF and showing whats going on in this space. It was interesting to see how far MSOffice has come with ODF, and at the same time how much we need KOffice to become the big second implementor. MS said several times that for optimum interoperability they choose a solution that works better with OOo and not what the specification says it should do. Having a second independent implementation will benefit us all by keeping the standard authoritative, not the most popular implementation.

The event consisted of several interoperability scenarios, essentially manual testing of making a document, saving it in your app and adding it to the wiki. Then loading everyone else’s document and checking whats broken. Followed with an investigation how you can do better. Its a good way to keep the developers focussed so they don’t spent all their time on one feature and being bad overall. KOffice did pretty well here, except for the areas that were already marked as experimental anyway (like change tracking, which is work-in-progress).

Joining the OpenOffice.org conference was making me a bit uneasy, on going there I felt like I’m a spy in the opposite camp. How wrong I could be! The conference was indeed called OpenOffice.org but essentially is a collection of people interested in the open document format as well as the main implementation. There were lots of people from governments and other stakeholders that made clear they were just as interested in KWord as in any other ODF implementation.
This is a stark contrast to the usual events I go to where the majority of participants are volunteers or students. For I went through my business cards quite fast and wished I had brought more.
As usual I get a lot of good energy from these conferences, so many friendly faces, good talks and this being Italy, I had quite good food too

I’m always happy to get a face to a name I’ve been emailing with and nothing works better than a conference in a country where wine is as cheap as water during dinner.

Finally LibAttica has landed in kdesupport (that’s where additional libraries are kept, that are not by definition part of kdelibs). Téo promised to bring his price winning Amarok about dialog into KDE-Land for KDE 4.5

I am just about to finish the first big big re-factoring of our Get Hot New Stuff framework. Since it got ported to KDE 4, Jeremy kept it up and running but didn’t have a chance to run with it due to some issues that belong to the land of “real life”. I poked at it two years ago, but then I’m a lazy bummer, so nothing at all happened there either.

Finally, Frank pushed me to get around and do work work on the dialog. The version in our re-factoring branch is ready to be merged into kdelibs, take advantage of LibAttica and just wants to put a smile on your face. Well, it’s not quite there yet, some features are missing - just the ones that are important to me that is the social community interaction part. Rating items, seeing more information about the author and so on. But with LibAttica doing the actual work, it’s at the tips of my fingers. Just need to do the right connections. So far I’ve been redoing all the backend stuff.

It’’s time to start polishing our good old dialog a bit. And here I’d like feedback from you! I have experimented with different ways of showing the rating of an item. Let’s say, we get a number between 0 and 100, how should we represent that in the user interface? In the original version we showed the number “Rating: 79″. Maybe not the most visual way. How about a progress bar? Nope, doesn’t really fit. Nepomuk uses stars. Those fit very well with the “Get Hot New Stars” icon that we have for “Get Hot New Stuff”. So why not go and borrow the widget? In the first iteration, I used 5 stars, just like Nepomuk. But it didn’t seem quite right to reduce the large range 0-100 to that. Plus the widget looks insanely huge and dominates the dialog just a bit too much for my taste. So I personally prefer the ten-little-stars variant.

But I probably think much too limited, knowing what goes on in the background… And I still have the old dialogs in mind. So dear reader, let me see some creative mockups, ideas and fresh ways to go about this dialog and it’s layout, contents and so on. Why not layout items in a grid? Something completely different? Throw it at me. Maybe the next version will be yours! Should we have different layouts for showing Wallpapers (images in general) and things that don’t necessarily have preview pictures? Vocabulary files usually are not that visible. Plasma Applets should have a preview, but here the text is important.

You can reach me at lastname@kde.org. Since Frederik is my firstname, use the other one

And if you ask yourself as developer, what will change, that’s easy to explain. Instead of having the somewhat strange logic of going through a class to give you a dialog, you will use the new dialog just like any other KDialog - either modal or not. When you’re done with it, ask it for a list of changed or updated items and be happy The only thing you need as well is a appname.knsrc file which is just a KConfig file that contains a bit of information about where to download from, how to install the items. That’s usually two lines and I’ll put an updated tutorial on techbase. Speaking of which, I started a small Attica tutorial, let me know if you’d like to read on or there’s something unclear about it. Porting an application that uses the Hot New Stuff framework already should take no longer than ten minutes.

Many thanks to Frank and hive01.com for making this possible!

The FSFE stand at FSCONS was staffed by a mix of full-time employees, interns, volunteers, Fellows, country team leads and (occasionally) anyone who would stand there for a few minutes while the rest took off for a food break. In order to show who the FSFE is, I took to drawing little portraits on the whiteboard. Now, my artistic skills are well known — I believe I’ve written of my sheer awesomeness with Kolourpaint; phrases like “skillz like a road-kill hedgehog” apply. Nonetheless, here is a little flash-card which you can use to identify FSFE people at your next conference.

Not very long ago, Aaron wrote an article about improving our user experience, stating that "Micro-Options Suck". Coincidentally, an article appeared on dot.kde.org only a few hours later, stating the following: "Choice Is Not A Usability Problem".

Ardent readers will notice that there is possibly a contradiction here. In this article I would like to explain why this is not really a contradiction, but rather a misunderstanding. To get us started, let's make a jump back in time (using Flux Capacitor technology):

The year is 2004. It's cold. You are alone. There is a house in the north (called "KDE"), and a house in the south ("GNOME"). Press "n" or "s".

> n

You have entered the house of KDE. It's a big house, full of obscure items. The sheer number of items is highly impressive, but you get confused. It is too much. What is your next step? Press "n" or "s".

> s

You have entered the house of GNOME. This house is neat, clean, but also kind of empty. There are very few things to play with. You get confused. What is your next step?

> I give up. User reboots into Windows.


The gist of this little analogy:

KDE was wrong. GNOME was wrong. Also - they both were right!


This is quite obviously another contradiction. Obviously this means that Mark is not quite right in the head! Well, you're possibly right on both accounts, but let me explain why it actually makes sense: The truth is somewhere in between.

KDE has historically been known for being "the nerd's desktop". Basically, we were so proud of having our own desktop that we quickly determined that giving everyone as much freedom as possible is ideal. After all, the competition (Windows) did not offer this. Developer A came along, going "Hey, I have this fancy idea. It's a bit weird, but let me show you!". Developer B was quick to reply: "Hell yeah, why not? After all this is our own desktop. We can make all of our dreams come true. Let's do it!"

GNOME has historically been known for being very sparse with options. They did this for a good reason: Someone smart realized that KDE was totally going overboard with options. Too much is too much. Let me show you a classical example:




Now let me show you an example of the Dolphin settings dialog:



Dolphin has won 2009's Akademy Award for "Best Application". The above screenshot demonstrates one of our reasons for choosing it: Peter Penz realized what generations of GUI developers (both in KDE and GNOME) got wrong: The true secret to getting your settings right is choosing the essential ones, while making good choices for defaults that don't need micro-options.

Unfortunately, this is not easy, and it separates the good GUI designer from the bad one. In fact making these choices is bloody damn hard, I kid you not. It requires a lot of thought, experience, and taste. But in the end, you, as a developer, are responsible for making these choices. Creating software is not about giving the user a LEGO blocks game. If options get too complex, the users might as well learn programming and do it all by themselves. That's because, if you think about it, choosing an option is programming: You make the program use one code path, or a different one. This is essentially the same as an "if() {}; else() {};" block wrapped in GUI sugar.

To sum it up:

If you’ve been reading the kde-core-devel mailing list, there’s been some talk recently about bugzilla, how much it sucks, whether we should switch, and alternative tools to switch to. However, only one person told me about something that could be improved. So, in order to get feedback on whether or not our customizations that are currently live on bugs.kde.org are hindering vs. helping, I’ve changed the layout on bugstest.kde.org back to the standard default bugzilla layout.

Please, if you use kde’s bugzilla currently, take some time to test out bugstest.kde.org. When you do this, please send feedback. The feedback should be something that we’re doing on the live site that is done better by the test site.  It can be good or bad!This can be in the form of a bug report in bugs.kde.org against the bugs.kde.org product, or sending me a simple email. Please include changes that you want made, or specific issues with the site so that I can at least look at fixing them.

I get that a lot of KDE folks are not happy with our current Bugzilla. I’m glad that you want to have good tools to work with. So far, I haven’t really seen anything that’s better. I’ve only seen systems that do things differently, which means that we can emulate that with Bugzilla, most likely. That’s after using Jira, Mantis, Flyspray, Bugzilla, and Redmine, and an old version of RT. Why not work on improving our current tool? If you think that Bugzilla has fundamental problems that require switching, I want to know what those are too.

Every now and then I post a recipe on this blog, and sometimes I muse about KRecipes, and there have been a few KDE events (the launch event in Mountain View, or CampKDE) where I’ve baked cookies or done other foodie-oriented activities. You can usually count on me to go looking for interesting food (there is no guinea-pig to eat in London, BTW) at events as well. But this winter season, I’m looking at something different. We are looking at something different. The “we” here is the FSFE, and we’ve decided that there’s worse things to do than cook a lovely dinner for some of our friends. So as part of our 2009 Fundraiser the executive team (comprised of at least three affirmed foodies — I’m not sure we have anyone who can function as a sommelier though) will be cooking a lovely dinner for one lucky sponsor of the FSFE.

Perhaps I’ll be able to practice this weekend with Claudia in Berlin — I seem to remember we got along pretty well cooking dinner in Paul’s appartment last year, but it’s a little hazy. Otherwise I’m left to come up with something creative to do with the rutabaga in this week’s vegetable hamper all on my own.

So watch out: Freedom Food might be coming your way.

A somewhat odd article that touches on patents and science crossed my desk last week in the weekend science section of my newspaper, the NRC. It’s about an experiment used to detect dark matter, the DAMA experiment undertaken under the Gran Sasso mountain. Science is largely about reproducibility, at least in the physical sciences: an experiment must be repeatable for it to have any weight as a data point. The reporting might be a little sketchy here, but it claims that the experiment is not repeatable (by researchers elsewhere) because there’s a *patent* on some parts of the original experiment and no-one can deliver the parts to another group of researchers without violating the patent license. The patent holders in this case are the research group who did the experiment in the first place.

Now, this might simply come down to a basic patent licensing dispute (which might be resolved either by granting special permission by the patent holder to another research group, or by re-using some of the original equipment, or by working around the experiment design entirely), but it’s certainly an illustration of how patents can stand in the way of even basic science questions asking “is this true?”