Tag: SL News

New ToS released

Posted on by Inara Pey

M Linden has announced the release of a new SL Terms of Service (ToS), that will come into effect from the 30th April 2010.

The timing is interesting, as it coincides with the Third Party Viewer (TPV) Policy going into effect, and it is interesting to note that M’s post also refers to all the policies relating to the ToS as being “new” (i.e. updated).

As to the ToS itself, the language has evidently been cleaned up with a view to making it somewhat more comprehensible – even if the document is much longer than the older ToS.

However, longer does not automatically mean better.

Overall, the ToS appears to encompass something of a paradigm shift that has been hinted at in various blog postings from LL for a while now: that they no long consider themselves a platform provider, but rather a service provider, licensing aspects of their service for use, ostensibly as the user requires them.

Some elements of this move appear to be “good” – on the land front, for example, we finally move away from the absurd and highly misleading notion that “land” in Second Life is “owned”. In the past, this has given rise to all sorts of misconceptions and ranting within the official flogs.  The new ToS makes it clear that the acquisition of “virtual land” and the fees relating to the same are now effectively a licence to use LL’s server space and fees relating to the use of that space.

That said…this blatant move it liable to cause massive upsets: Linden Lab have long promoted the concept of “ownership” within Second Life – while the ToS has tended to make it clear users don’t actually “own” anything beyond IP rights to their own creations. As such, the ToS was found to be coercive during one famous case. While times have changed, one can well see the move to “licensing” land to be a causing of much potential upset in some quarters.

Similarly, the new approach is liable to cause much gnashing of teeth where Linden dollars are concerned, inasmuch as any fiscal value associated with them has now been almost completely stripped away up until they are actual converted to “real” currency and withdrawn. One cannot help this a) has been done to reduce the prospect of litigation following future account terminations; and b) will vastly reduce the funds people are willing to hold in their accounts.

These implications are potentially bad enough; then things get worse. Section 7, dealing with content, is perhaps the most confusing aspect of the new ToS, in that it appears to have been written around the God-awful “Second Life as the web” paradigm many at LL seem so in love with (and which is in keeping with their shift in now regarding themselves as a service provider along the lines of an ISP). As such, licences, rights, etc., are all talked about in terms of “uploading”, “publishing”, “submitting” and so forth, vis: You retain any and all Intellectual Property Rights you already hold under   applicable law in Content you upload, publish, and submit to or through the Servers, Websites, and other areas of the Service, subject to the rights,   licenses, and other terms of this Agreement, including any underlying rights   of other users or Linden Lab in Content that you may use or modify [my emphasis].

But what of content created in-world? The ToS implies that content created in-world (prim linksets, LSL scripts written in-world, etc.), fall outside of this section and thus are by default the property of Linden Lab. Even Section 7.6, relating to IP rights limit’s the user’s ownership of such rights to content you upload, publish or submit to the Service.

If this is the case, then it is worrying on several levels – both for users and potentially for Linden Lab.

Elsewhere, the new ToS introduces the TPV Policy in what is again bound to cause outrage. As I’ve mentioned previously (and more than once), the TPV is flawed in that the TPV confuses the use of third-party Viewers with the development of said Viewers. This has already given rise (rightly or wrongly) to outpourings of scorn and hurt from third-party Viewer developers  – and it now looks set to do the same with users of such Viewers. One can – to a point – see why the two have been mixed: TPV code is open-source and thus moddable – not only by the original developers, but by users why are so inclined.

Even so, it would have been far better had LL restricted the TPV policy itself to developers and the development of TPVs, and included a short, unambiguous section on users’ responsibilities in the use of TPVs within the body of the ToS. This would have scored two quick wins: i) it would have enabled LL to simply specify what users cannot do to existing TPVs without getting confusingly embroiled in deeper development issues; ii) it would enable developers to more clearly state their own EULA to ensure they both remain within the confines of the TPV Policy and limit their liabilities in the face of those determined to hack their code for malicious ends.

It’s also hard to fathom the policy around snapshots and machinima. Promoted by LL as an “aid” to such work, the entire policy looks set to achieve exactly the reverse. People are already trigger-happy with the AR option when it comes to “copybotting”; one dreads to thing what will happen when folks start innocently taking snapshots of one another as they hope around places that interest them and others start getting objectionable…..

The biggest problem with the new ToS is that while it is cohesive pretty much of itself, some contradictions are apparent – most notably between the ToS and the supporting policies. The ToS also absolves Linden Lab of virtually any and all liabilities – even in the case of them either turning off SL with no warning, or simply being so grossly negligent that they completely break the platform; at the same time, it enforces liabilities upon user even after they cease using the service. Hard to see either of these surviving a court case intact.

One can no longer doubt that the times are a-changin’ – but the question really remains as to how much this new ToS will really affect the overall use of SL. On the one hand, I can see elements giving problems, as mentioned above vis photos / machinima and possibly the use of third-party Viewers (possibly because the majority of “new” users will be driven down the Viewer 2.0 route), but I honestly suspect that – as with past upheavals in SL, life will go on more-or-less with an air of “business as usual” as the dust surrounding the new ToS settles. At least until the first lawsuit pops up.

Unless, of course, LL themselves see fit to rock the boat to the point of capsizing it themselves.

TPV: First casualty

Posted on by Inara Pey

imprudenceImprudence issued a statement earlier this week that they are withdrawing from Second Life as a result of the Third Party Viewer (TPV) Policy. In the statement, they set out their reasons as to why they are withdrawing, pointing to clauses 2b, 4a(i), 4b(iii), 7a and 7d, and 8c and 8d as being “unreasonable”.

Having gone over the TPV a number of times, I have to say I find Imprudence’s position for the most part hard to understand, as their interpretation of four of the clauses then mention seems to be wilfully subjective and misleading; while their reaction to two more of the clauses seems to lack any professional clarity of thought.

Imprudence state that (4a)i, (4b)iii, 8(c ) and 8(d) require us to promise to obey Linden Lab’s every future whim and that as such, the Imprudence team are unwilling to make such broad promises, not knowing what they may request.

This is a very sweeping statement, with Imprudence further claiming that 8(c) requires that they agree to stop using or distributing the viewer at Linden Lab’s request and that 8(d) requires that they agree to add, modify, or remove parts of the viewer at Linden Lab’s request, within a time frame dictated by Linden Lab.

However, these claims can best be described as over-exaggerated. Here is what clause 8c actually states:

If a Third-Party Viewer or your use or distribution of it violates this Policy or any Linden Lab policy, your permission to access Second Life using the Third-Party Viewer shall terminate automatically. You acknowledge and agree that we may require you to stop using or distributing a Third-Party Viewer for accessing Second Life if we determine that there is a violation.

Note my emphasis: the qualifier is clear. If a third-party Viewer breaks the TPV Policy, the Linden Lab require it no longer access Second Life. This is far short of Imprudence’s blanket assertion that Linden Lab require they “agree to stop using or distributing the Viewer” – a denial of access to Second Life clearly does not prevent them from continuing to distribute their Viewer for use on OS Grids, etc.

Similarly, clause 8(d) states:

If you are a Third-Party Viewer Developer, you agree to provide any content, data, executables, or for Third-Party Viewers based on our viewers, any source code that we may request to verify compliance with our policies, licenses, the GPL, or the law. If we believe that your Third-Party Viewer is not in compliance, we may request that you add, modify, or remove features, functionality, code or content, and you agree to comply with the request within a reasonable timeframe specified by Linden Lab.

Again, note the qualifiers I’ve emphasised. There is really nothing unreasonable here – if you wish to play in Linden Lab’s sandbox – which, by connecting to their servers and services a Developer is in fact doing – then sorry, Linden Lab have the right to ensure, so far as is possible (or, as I’ve stated elsewhere, give the perception they are ensuring) that your code does not constitute a threat to their services in and of itself  (excluding, obviously, mods any user introduces – which the Developer should again be able to prove relatively easily via the provisioning of their own source code).

Similarly, it is hard to see why Imprudence should be so upset of clauses 4a(i) and 4b(iii). Clause 4a(i) refers  to data received from Linden Lab’s servers – data for which Linden Lab has certain legal responsibilities (likely to be both State and Federal in nature (such as data privacy laws). As such, their various policies, terms of service, etc., must reflect such requirements  – and by extension, they need to ensure (or again, give the perception) that they are doing all they can to ensure that this data is protected when used by the software connecting to their servers.

Similarly, clause 4b(iii) relates to the protection of user data and makes a perfectly reasonable request that third-party developers take steps to ensure such data is kept secure when passing through their systems (and remember, if you use their Viewer, your login information, etc., goes through their servers). As such, it is in Imprudence’s best interests to ensure such data is protected at least to the same degree as on the Linden Lab servers. It is hard to see Linden Lab being so stupid as to issue requests for user data protection that exceed their own, and frankly – one would hope that Imprudence already have the necessary safeguards in place to ensure the data is as secure as possible.

Given that both these clauses relate to potentially sensitive data, I find it hard to accept that Imprudence, as responsible code developers would find a request to take reasonable steps to protect such data objectionable.

Indeed, in this, I find Imprudence’s own assertion that If and when Linden Lab makes any request of us, we will use our own judgement to decide how best to handle that particular request to be at least as presumptive and arrogant as anything in the TPV – even to the point of suggesting that if they see little need to protect user data, then that is their call, and nothing to do with either Linden Lab or the users of the Imprudence viewer.

Frankly, when all four of these clauses are viewed in their proper context, it is very hard to see how any professional software developer would find them in and of themselves reasons to reject the TPV Policy. That the Imprudence team opt to refer to the clauses somewhat out of context and apply highly subjective interpretations to them suggests that it is the thinking at Imprudence that is at fault, not the thinking behind the policy itself.

Clauses 7a and (d) have been the source of much wailing and gnashing of teeth across the Viewer development community, but again – as I’ve previously said – it is hard to understand why. While 7(a) is indeed poorly worded, and unnecessarily mixes Viewer use with Viewer development – there is absolutely no reason why the entirety of Section 7 of the TPV cannot be handled by a Viewer developer issuing their own EULA as a part of the distribution / installation package. A responsibly written EULA would clearly protect the developer for undue liability, and wouldn’t be in violation of GPL.

Certainly, it is what Kirstenlee Cinquetti has already done with her Viewer – and I’m pleased to see at least one voice of reason on the Imprudence website has raised the same point.

Which brings us finally to clause 2b. And here Imprudence have a point. As stated, the TPV Policy effectively restricts the export of content from SL to the creator. Period. If the user’s name is not on every prim, every animation, pose, script, contained in a linkset or whatever – then it isn’t going to be exportable.

This does – to be fair – read as overly restrictive. As if one is to remain fair, the clause seems to be less related to preventing content theft as it is about preventing “valuable” content being removed from Second Life per se – which LL have always looked less-than-favourably upon. Frankly, it is hard to fully justify LL’s stance on limiting content export so tightly: this automatically disallows the export of Group-created content for the purposes of back-up, and also disallows the export of content created by one person but sold under a license agreement to another. As such, I can see Imprudence’s concerns – just as I can see the issue LL face in trying to invoke the perception of protecting people’s creations when given the crudeness of the ownership / permissions system.

I doubt Imprudence will be the last of third-party developers to walk away from the Second Life sandbox. Each one that does will be a loss to the community to some degree, to be sure. How many do so on the basis of rational thinking as opposed to acting in a fit of pique, however, remains to be seen; and I have to say that having gone through the stated reasoning behind Imprudence’s move, I do feel it is a case of pique getting the better of them.

Third Party Viewer Policy – Further update

Posted on by Inara Pey

LL have quietly slipped out a revised Third Party Viewer (TPV) Policy.

While its heart was most definitely in the right place, the initial draft was flawed in several areas, as commented on by myself and others at the time.

Pretty much everything that appeared to run against common sense seems to have been fixed – with the passable exception that LL still insist of laying claim to the word “Life”. In particular Part 1h is gone from the document (good!) and Point 6a(ii) has been revised so that personal information such as rl name and address will not be published in the Viewer Directory. A minor niggle here is that it should be spelled out clearly in the Policy itself, but it is clarified in the accompanying FAQ.

Point 7a has been also  been cleaned-up. The original stated:

You are responsible for all uses you make of Third-Party Viewers, and if you are a Developer, you are also responsible for all Third-Party Viewers that you develop or distribute.

This was a dangerously ambiguous statement and one that could be taken to read that the original developer will be held to account for each and every use their Viewer is put to – even if modified by others outside of their control. As such, this one statement, more than any other, served to potentially undermine the entire policy: who in their right mind would agree to such a clause when knowing full well anyone could maliciously seek to download, alter and use their code?

In the revised document Point 7a now reads:

You are responsible for all uses you make of Third-Party Viewers. If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute.

The difference is subtle, but it is there; The reference to features, functionality and code allow a distinction to be drawn between being a developer being held accountable for their “original” code and being responsible for modifications to said code made outside of their control. This should in theory be enough to allay fears in this direction.

Only it doesn’t. Many are still up in arms about the Policy, largely due to the manner in which Section 7 has been re-cut.

The problem here seems to be part technical and part social – and frankly, it is the Lab’s fault that the two issues have become confused inasmuch as they have chosen to draft a policy that intertwines the technical development of a Viewer and its means of distribution with its social use (Section 7, “Your Responsibility for Third Party Viewers” is actually now sub-titled “If You are a user or Developer of Third Party Viewers”).

The specific point that has upset some Viewer developers is Point 7d: You assume all risks, expenses, and defects of any Third-Party Viewers that you use, develop, or distribute (my emphasis).

The mixing of use with development and distribution of third-party Viewers creates an unfortunate ambiguity wherein this statement could be taken to mean that third-party Viewer developers could still be held accountable for the uses to which their code is put once it has passed beyond their control. This is clearly unfair.

While it could be argued that a user taking an established Viewer and tweaking it for malicious purposes could be regarded as “development” of the Viewer, the fact remains that such issues should really defined within the Terms of Service, which a) themselves relate to the use of both the Second Life service and the tools used to connect to it; and b) are actually likely to be read by users.

Both as a part of this blurring of use and development, and as a matter in its own right in terms of overall technical liability, several raising objections to Point 7d have done so specifically in terms of “GPL violations”. I have to admit, I don’t fully buy-in to their arguments, and I’m not absolutely certain any court would agree with their black/white view of the text of this Point because:

  • Linden Lab have sought to clarify the Policy with a FAQ, where the meaning of various clauses in the Policy are spelled out in lay terms. As a supporting document, complete with explanations given by Linden Lab themselves and presumably approved by their lawyers, the FAQ does have bearing in a court of law. As such, were Point 7d to result in a Viewer developer being held unduly to account for the use of their code, the FAQ could be used to counter any action
  • More importantly, no legal document stands in isolation. There is the established precedent of law and the forbearance of pre-existing agreements and understandings. As such, a court is unlikely to go against a Developer who has acted fully and completely both with the spirit of the GPL and this policy, simply on the basis of point 7d. In fact, in many respects, it is hard to see such a case reaching court
  • On the wider, more controversial front, many view GPL as automatically granting immunity under the terms of the agreement. This is actually not the case. Clause 16 of the GPL broadly absolves the developer from liability, it does so with the caveat of unless required by applicable law or agreed to in writing (my emphasis). Thus, and while some developers may howl and scream at me for saying so, LL are technically within their rights and within the spirit of the GPL to introduce whatever clauses they deem fit into their policy. While this is a cause for concern – as this is how LL are adding the onus of liability – it doesn’t prevent developers in turn limiting the extent of their exposure with an EULA that includes a mandatory agreement as a part of the Viewer installation process.

Thus, while there are problems with Section 7, I don’t actually believe they are insurmountable.

Ideally, the issue of confusing Viewer use with Viewer development would best be dealt with through Linden Lab simply redrafting the section to clearly differentiate between the responsibilities of the Developer and the responsibilities of the user (for example, have Point 7a list the responsibilities of the Developer as enumerated items (i, ii, iii, etc), followed by Point 7b giving a enumerated list of responsibilities for the user). Doing so would probably account for around 98% of the gnashing of teeth and wailing currently being evidenced.

That said, and failing any re-write of the TPV, developers still have recourse to the use of an EULA, as mentioned above. If I understand things correctly, doing so would not be in violation with the GPL. Such an agreement / licence statement would likely supersede  statements such as Point 7d in the TPV policy, given that by allowing such a Viewer to connect to the grid, Linden Lab are tacitly acknowledging the developer’s own Licence Agreement with their users.

One also wonders whether Linden Lab will actually be pro-active in blocking Viewers from accessing SL where the developers have not signed-up to the TPV.

That said, at the end of the day, the TPV seems less a matter of legal action and far more a matter of public perception. Take away the inadvertent ambiguity and the rest, and the Policy really hinges on two thing in order to “succeed” in its aim of reducing the risk of malicious Viewers connecting to the grid:

  • The unwillingness of people behind such Viewers to provide proof of identity to LL.
  • The unwillingness of users to go beyond the list of “compliant” third-party Viewers and use a Viewer which might be perceived as being malicious and result in their being banned from the system as a result.

As such, if both of these goals are achieved, or perceived to have been achieved, then the Policy can be regarded as a “success” – even if it does (sadly) come at the cost of some developers continuing with their efforts to provide better and more stable means for users to experience Second Life.

Scripts limits announced

Posted on by Inara Pey

Jack Linden – possibly as a part of his new role as Executive Director, Consumer Products today blogs about the upcoming server-side scripting limits.

These have been the source of much hype, debate, guesswork and outright misinformation (not, I hasten to add, from Linden Lab) for a while now; while it is still somewhat early days, Jack’s post is welcome as it does much to set out LL’s table on the matter, and start the flow of information very positively – allowing for the fact that much still appears to be in a state of flux.

Of course, there are concerns with the approach. While scripting limits are perfectly acceptable and may well help improve sim performance on overworked servers (allowing for the virtual nature of sims themselves), the planned roll-out of the new controls does lend itself to a lot of potential misunderstandings and confusion. In this respect, I certainly hope that Jack and the team keep Phase 1 of the project – Information – uppermost in their minds.

In summary:

  • Linden Lab will be rolling out the project in three broad phases: Information – and Jack’s post can in some ways be seen as the first post in this effort, even though there have been earlier general postings on the subject by the likes of Babbage Linden; Tools – see below; and Enforcement
  • Server 1.38, due out in April will start the ball rolling with the release of script monitoring tools
  • Said tools will allow script usage to be monitored on a per parcel basis but the parcel “owner” / renter; additional tools will be provided to the sim owner / estate managers which will enable the return of objects that are taxing the sim in terms of script loads
  • Script “space” in memory will be assigned to sims in a similar manner to prims: there will be a total limit for the sim as a whole, which can then be allocated to parcels as the land is divided up.
  • Additional script space will be allocated per avatar, with an overall “pool” of resources per sim to handle avatars
  • While Jack’s post does not make this entirely clear, it appears that if the script limit for a parcel / sim is reached, additional scripted items will not work; similarly, if all resources for avatars is used, additional avatars entering the parcel / sim will find attachments do not work.

Many have debated the pros and cons of capping scripts, but the fact remains, whether we like it or not, the servers supporting Second Life all have finite resources, and scripts have never really been monitored, and have become one of the causes of server-side lag, simply because of their overwhelming prevalence.

That said, Jack’s post does leave some cause for concern over potential angst / misunderstandings / over-zealousness down the road:

  • Currently, LSL scripts are capped at 16Kb, while  Mono scripts can use up to 64Kb (but can in theory be a lot smaller than this – the average being around 9Kb according to Jack)
  • However, the new tools will initially only report on the maximum amount of memory a script can use. So, if you have four LSL scripts running, they’ll be reported as taking up 64Kb of memory. But…if you have 4 Mono scripts running, they’ll be recorded as taking up 256Kb of memory – even though the scripts may be a lot leaner than this
  • The monitoring tools will be tweaked later in the year so that Mono scripts will be able to report their actual memory usage – but initially, only the maximum 64Kb per mono script will be reported
  • The upshot of this is twofold:
    1. It gives an incorrect impression that Mono is actually more resource-hungry than LSL
    2. It runs the risk of having people single out Mono users unfairly on the basis that (whether or not parcel / sim script limits are being affected)  “they are hogging resources” because their “script usage” is “higher” – much as we witnessed people getting all het up and shouting about ARC and lag…
  • A third possible outcome of this is that when shopping (and assuming memory usage becomes a “feature” of vendors, people will opt for LSL-scripted items because they appear more memory-efficient

There are other concerns that have been raised – such as scripters being able to use the land tools to test the efficiency of their scripts (given than not all scripts own / rent land, but work in places like sandboxes where the tools – to be included on the About Land window – will not be available to them. However, it is probably this issue of actual versus perceived script efficiency that is liable to cause the greatest upset with this change, unless LL work very hard to fully and properly communicate this change to the community as a whole.

And while script limits may well be a good thing for SL overall (I’m hoping they will have the desired outcome as far as is reasonably possible) – we’ve been shown time and again that when it comes to proactive communications with residents, Linden Lab’s efforts seem to repeatedly fall far wide of the mark.

Azure: assurances and questions

Posted on by Inara Pey

Well, it’s official. As of today, MSL (operated by Anshe Chung) now effectively owns Azure Islands.

What does this mean? Well, overall, it means that a single land owning company now controls some 7.5% of private estates. May not sound a lot, but it is a bit of a clouting stick.

For Azure Island residents, it hopefully means that things will continue more-or-less “as is” under the new management, and both the outgoing Azure management and the incoming MSL team have stressed this, while indicating that perhaps some 5% of Azure residents may have to face relocation as MSL move to break up some of the Azure estates to provide “greater privacy and less lag” (to quote the MSL note to Azure residents).

The Azure team themselves are stating the reason for the transfer is simply that they’re in need of a change after some 5 years in the business – and as I previously noted, Adam Zaius does have his OS Grid interests that must be taking up a lot of time.

Change is a natural part of business. While some Azure residents may be adversely affected by the hand-over, it has to be said that while unfortunate, their disaffection doesn’t spell the end of SL or anything else; one can sympathise, but one isn’t going to chastise the Azure management or anyone else for the woo that some may encounter.

To me, the burning questions remain related to the wider implications of this move. While on the one hand, one cannot blame those behind Azure for wanting to move on to new challenges, there is still something deep down about the timing of this  change that concerns me – although what it is, I can’t rightly say.

Then there is the potential impact on smaller private estate owners. MSL / Dreamland is now a very powerful voice in LL’s ear, and one wonders at possible future implications in this. Again, none may be forthcoming, but given Jack’s penchant for behind-closed-doors deals, one has to wonder.

The entire – topography – of land sales and rentals is changing; the Azure move is in many respects “simply” another part of this. Doubtless some will cheer what appears to be another step in Adam Zaius’ departure from SL, while others will point to the sky and claim chunks of it are falling. I don’t think either is the case – but by the same token, I’m glad I’m no longer in the land business myself.

An Azure Dreamland?

Posted on by Inara Pey

It seems one of the major land businesses in Second Life is about to change hands. A comment posted on the SLU forums quotes the following for a notecard apparently circulated to some Azure residents:

We’ve got some fairly big news for the residents of the Azure Islands, as of March 16th, the Azure Islands will be transferring from us, over to a new management team run by Metaverse Services Limited.

If accurate, this is newsworthy on a number of counts. For a start, “Metaverse Services Limited” appears to be the holding company for Anshe Chung (Ailin Graef) of Dreamland fame, Time magazine celebrity and flying penises notoriety. If Azure is going under Anshe’s banner, then it means that from tomorrow, MSL control a huge swathe of estates and land across Second Life and are potentially in even more of a position of power where matters of policy and behind-closed-doors discussions with LL on land benefits, etc., are concerned.

Secondly, it begs the question as to what is happening to the land business overall in Second Life. Adam Zaius (Adam Frisby), primary owner of Azure island has been staunchly involved in SL almost from the beginning – something that has earned him a reputation as being a “pillar” of the so-called Feted Inner Core (FIC) and the devil incarnate by some, whilst simultaneously viewed upon as a fair and committed land owner, businessman and pioneer to others (notably his residents). Whichever side of the coin one happens to view when looking at Mr. Zaius – it cannot be denied he has built a considerable business enterprise within SL – one that goes beyond Azure itself; and has given a tremendous amount to the platform as well.

That he is now apparently selling-off / transferring / pretty much bailing on the SL land business – and taking into account his growing interest in / commitment to the OpenSim environment, which may be playing a part in this decision – tends to suggest that the entire land business, which has for so long underpinned SL as a going concern, is in far worse state than even the most negative of speculations around it have suggested. Even with his preoccupation with OSGrid development, it is hard to see Mr. Zaius abandoning what must be a healthy revenue stream simply for the hell of it. If he really is a “pillar of the FIC”, does he know something other’s are not privy to? Again, Zaius is not alone in running Azure…What of his partner in the venture?

Of course, this all could be grist for the rumour-mill – but I’ll be quite curious as to what emerges tomorrow.