SunMink

Simon Phipps's other Weblog
(a WebMink in the Sun)

Document Freedom Day

The news just went out that March 26 2008 will be the world's first Document Freedom Day, celebrating and championing the cause of true freedom for our data. You may recall that I wrote about this back in 2006 and also gave a speech at the European Commission. I coined the term "Freedom To Leave", referring to the liberty to take your data and go elsewhere uninhibited by DRM, closed interfaces or file formats that require a particular program for faithful reproduction and use.

I believe this to be the new front line in defending the freedoms of computer users. Richard Stallman's four freedoms are now driving the mainstream of software (especially here at Sun), and while software freedom is not yet a given, the next challenge for us is our freedom to own and move our own data anywhere, any time.

Defining Data Freedom

I believe there are multiple dimensions to data freedom.

• There is the personal dimension - being able to take the data I "own" and use it with any software or service that's appropriate.
• There is the historical dimension, ensuring future researchers have access to the electronic information that is driving directions in society today.
• There is the commercial dimension, ensuring that data interfaces remain open, equitable and interoperable so that we have a fair yet competitive marketplace.

Strategically Ignoring Customers

Interesting to see the Microsoft folks making a big deal out of the fact that companies are implementing OOXML features in their software products. I'd hesitate to join them being thrilled at IBM's new-found support for their strategy. Truth is, when there's a monopolist in the market it's impossible to ignore the consequences of even their worst ideas, let alone their good ones. Responding to the needs of locked-in customers who will find themselves using OOXML is a different deal to strategic support.

A much more crucial question, though, is why the folks at Microsoft are so surprised. If you know your customers have a requirement, surely you respond to it? The real question this situation brings to my mind is not "why are IBM implementing OOXML features". It's "why won't Microsoft implement support for ODF at least to the same level as RTF built-in to Office?" Given they have a number of very significant and visible customers demanding that support, it seems to me they are the ones with the explaining to do, not IBM, Google, OpenOffice.org or anyone else.

Verse Remembered on Reading a Certain Posting on Slashdot

Epigram on Singers

Swans sing before they die - 'twere no bad thing
Should certain persons die before they sing.

Samuel Taylor Coleridge, from Verse and Worse

The Go-Between Format

While I was considering the power plugs that appeared in last Friday's posting, it struck me that there was an untold story worth considering there. The plugs are from a replacement power supply I have now used several times for various gadgets. At one end is a block with a dial for me to select a voltage, into which I can insert a mains flex. At the other, the lead terminates in a two-pin female connector. I can then select the tip that works with my gadget and insert it in the end of the lead, selecting the polarity in the process.

It's not perfect, but this device solves the vendor-imposed mismatch by offering an intermediate connector that allows close to an any-any match. Looking at this I realised we may all have lost sight of the problem we set out to solve in 2002 with what's now called OpenDocument Format (ODF).

What we wanted was an equivalent (better!) solution for portability and longevity of editable documents. The way this was being achieved in 2002 was actually not by the plugs themselves (all the various then-undocumented binary formats called ".DOC") but rather by an intermediate format, Rich Text Format (RTF). Weakly specified and widely implemented, this was the way most of us created word-processing documents that we could be reasonably sure would be opened on any platform in any word processor.

While an RTF specification is now available (ironically not in RTF format), the problems it presented - and still presents - make it unusable as an open standard with open source implementations. Why? Well, reasons include:

1. The license is incredibly restrictive;
2. The specification has no participative process to control its evolution so changes at random;
3. It's too weakly specified for rigour in implementation across many platforms;
4. There is no open source reference implementation;
5. Because it has been tracking MS Word for years, there is no one version everyone is implementing.

So I wonder if people have been incorrectly comparing OOXML and ODF? Surely the correct comparison is of ODF with RTF? And surely, regardless of the state of OOXML, the problem remains and ODF is the best solution for it, providing a baseline interchange format we can all use?

Just in case you need inspiration from the plug tips too, see what they say to you in this brief animation my son made.

Choice and Customers

For those of you who were on vacation last week, welcome back! I ran a series of stories last week looking at places around the house where there are multiple "standard" formats for things and what the impact of them is. To recap, I looked at:

• Choice and Light Bulbs, in which I noted that choice that serves the customer involves having as few different connectors as possible and lots of choice of light bulbs in that format.
• Choice and Flash Memory, in which I observed that I wish I didn't have to keep buying memory cards for my different gadgets just because the format in use varied, and how some formats seem designed to actually reduce customer choice.
• Choice and Power Supplies, in which I looked at the power supplies all my gadgets come with and observed there were so many different, vendor-serving choices in play there that I am swamped with power adaptors, but how a solution from an unexpected direction - USB - may be the answer.

Lessons Learned

Spending this time looking round the house for examples of multiple standards has been useful for me. It got me to tidy a load of stuff that had been sprawling across the study, yes. But it also led me to some conclusions about the value of having a choice of standards.

1. There are plenty of examples of a choice of "standards" in our lives (usually validated in some way by a vendor body), but I have yet to find one that actually leads to a benefit to the customer. In the cases I have found, it arises from:
• Vendors trying to create customer lock-in, like Sony and the Memory Stick;
• Subsequent versions of a prior format being developed, like the Memory Stick Pro;
• Vendors trying to reduce their costs, like those choosing to only offer 110v wall wart power supplies;
• Vendors trying to create an after-market, like those selecting custom power plugs in their gadgets so you have to buy their in-vehicle adaptor;
• Vendors operating in a market that is fundamentally divided, like those choosing between SBC and SES sockets for their bulbs.
2. When standards do occur that help the customer, it may be that the fastest path is to avoid involving the vendors directly. Using USB as a power connector standard was not part of the intent of the consortium that defined USB (who were competing with Firewire, leading to an undesirable, vendor-focused choice of standards).
3. No vendor will willingly surrender the ability to create customer lock-in or a taxed after-market. Even in the case of USB as a 5v power standard, it is still taking legislation in Asia to stop vendors being anti-social.

In other words, I have yet to see a case where a choice of standards in a single area delivers benefit to the customer. I can see all the benefits it's bringing to the vendors in the cases above, but it's also causing them unnecessary costs. But customers? No. I remain unconvinced that a choice of standards for a given application does anything for them.

Choice and Power Supplies

Being a gadget guy, I find I end up with a load of power adapters. There are two basic types:

• 'Wall warts' with a build-in mains plug (or sometimes with an integrated mains flex)
• Bricks with a connector to plug in a mains flex

I generally prefer the latter, since as Sin-Yaw observed there are multiple international standards for mains connectors and I prefer not to have to use an conversion dongle for long term use. Additionally, wall warts tend to have a fixed voltage corresponding to the country whose plug they carry (since there are multiple standards even after a century of use) whereas bricks tend to accept any mains voltage. The down-side of bricks is that the connector for the mains flex can vary, but of late the majority have had 2-pin figure-of-8 connectors.

There's enough variability at the mains end, but it's nothing to the variability at the gadget end. While many devices use a 5v supply, it seems no two devices use the same connector and polarity to deliver that 5v supply. As a consequence, when I travel I used to have to carry a whole bag of black spaghetti to be sure everything was powered. There's plenty of choice, and there are standards involved, but it all serves the manufacturers rather than the customers.

I say “used to” because increasingly I am choosing things that charge from a USB lead . I don't think the group that defined USB intended to define a standard for power plugs, but increasingly I am finding that gadgets come with a mini-USB connector so that they can be charged from any USB socket. So my bluetooth headset and mobile phone both use this method, and I no longer need to carry two of the power adapters that used to be in the spaghetti bag.

I now have a growing collection of useful things that work with this USB power standard, all from different places and all interchangeable. So I have a car-socket-to-USB plug, wall-warts for US & UK that deliver USB, and each new gadget that comes with a USB/mini-USB lead makes it easier to leave a cable ready everywhere. And since most power comes through my computer, there are fewer wall-warts left plugged into power sockets acting as electricity vampires.

I hear some Asian countries agree with me and are starting to make laws standardising on this approach, making a USB connector the only approved way to supply power. That restriction on unwanted diversity has to be good for customer choice as well as for energy conservation.

Part 1: Choice and Light Bulbs
Part 2: Choice and Flash Memory

Choice and Flash Memory

I just bought a new camera, a Sanyo digital video that films in HD (720p) and stores onto flash memory cards. My plan is to give video podcasting a try, but as you can tell from the track record on LiveMink that may be hopeful. Still, it's a cool toy and I am having great fun playing with it.

I actually have a load of flash memory cards due to my long-term addiction to digital photography. The problem is, they are all different kinds. There are CompactFlash cards (in three thicknesses), SD cards, micro SD cards, Memory Stick, Memory Stick Duo and a whole load more. I have a nice 1Gb CompactFlash card but it won't fit the new camera, which uses SD cards. So I have had to get a new SD Card.

Why are there so many formats? Well, they seem to be defined by competing manufacturers and different regional vendor consortia. Memory Stick is from Sony, for example, and hardly used at all by other manufacturers. That means I can be sure that if I have a Sony product, replacing it with a product from some other manufacturer will also involve buying new memory cards and perhaps new adaptors to allow them to be plugged into my computer. As a result, once Sony has managed to get a customer the cost to that customer of exercising choice is higher. More than that, there are quite a few accessories that don't support Memory Stick, so my choice as a customer is further constrained.

What I really want as an end-user is many fewer formats. Choice is still good - there needs to be a range of capacities, of storage technologies, of access speeds and so on. But why should there be so many different connector/card formats?

Choice and Light Bulbs

Reading Sin-Yaw's blog about power plugs and the need for a conversion 'dongle' last night, I started wondering what other examples of "a choice of standards" there are. Looking around the house I realised there were quite a few. Since it's a holiday for lots of my readers, I'll take the next few days to tell some stories about what I found.

So let's talk light bulbs. I pulled the box of spares out of the cupboard and took a look. There were red, green, blue spotlights; 60W and 100W bulbs; 25W and 40W candle bulbs; some 6W low-energy bulbs; a great halogen-in-a-bulb that gives a brilliant room-filling light; and plenty more. Having a choice of light bulbs is good. I can decide to put the 25W candle bulbs in the light fittings in the hall, for example, and save energy and money out there. Then I realised that I can't use the 25W candle bulbs in the candelabra in the lounge in place of the 40W bulbs I usually use.

The reason? The lounge fitting takes small bayonet connector (SBC) bulbs, but the hallway fitting takes small edison screw (SES) connector bulbs. Similarly, the reason the low energy bulbs (delivered free of charge at one point by the electricity company) are still in the box is that they have a full-size bayonet connector (BC) but the lights that need them in the kitchen all have a full-size edison screw (ES) connector.

There are similar stories for the rest; the great halogen has an ES connector but the socket where I'd like to use it in the study is BC, for example. The outside light has an ES fitting but all the weather-proof low-energy bulbs I can find that are the right shape for the casing have a BC so I am forced to continue using something incandescent. Having a choice of connectors like this simply leaves me with redundant bulbs in the cupboard. It also means when I buy a new lamp I probably can't use the spare bulbs I already have in stock. A choice of standards for bulb connectors reduces my choice as a customer since I find I am unable to buy bulbs in bulk and unable to use old bulbs in new lamps.

That doesn't mean choice is bad. I want a choice of colours, of energy technologies, of wattages, of shapes, of reflector styles and so on. But I want them all with a common connector so that when I'm shopping I know any bulb will work. Choice that serves the customer is choice of bulb, not of connector.

US OOXML Discussion Now Public

Ten Reasons The World Needs Patent Covenants

Among the things Sun does to protect Free software developers from patent threats is to issue patent non-assert covenants. We did it for ODF, we did it for UBL, we did it for SAML, we did it for WebSSO, and we just did it again for OpenID. The idea has spread a little but needs to spread much more widely. Here's why.

1. It's a blanket promise connected with the technology in question that's not restricted to particular facets or features - it doesn't just have a list of a few carefully-selected patents and leave you to wonder what's not granted. A blanket statement like this just says "no need to look, you're safe, Sun is on your side".
2. It's irrevocable. It's a promise you can rely on for the long term, regardless of changes in Sun and the industry.
3. It's global. No games involving smiles in one country or state and attacks in places that don't hit the news so much or have laws that encourage patent aggression.
4. It's not time-limited for the projects where Sun is able to join the process - there's no "everything before this point" clause. For example, it extends into new features added to future versions of ODF all the time Sun continues contributing to its development, and doesn't end if Sun stops participating.
5. It's reciprocal (we won't sue you if you don't sue the community). That means that we're still able to take action to protect ourselves and the community we participate in, despite providing rock-solid safety for developers and end-users.
6. It builds a web of protection because it is reciprocal. As each new participant offers a similar covenant, the consequences of a patent action on any member of the community become greater and greater, enforcing the peace more strongly.
7. There's no bureaucracy. Some moves in the past have sounded generous but have required some sort of action to register a license or act in some other way that limits redistribution of software that's trying to benefit from the protection.
8. It's simple and clear. There is no game being played and you tell because you can understand the whole thing. It's about as simple as an effecive and binding legal document can be made.
9. There's no "essential claims" language. Most statements like this one include language that says that you only get a "waiver" if you've no choice but to infringe the patent - according to the patent holder, that is, there's no certainty available! This statement sets you free regardless, no judgement call required.
10. It's cheap! You don't have to search your portfolio for relevant patents if you don't want to, you can issue a non-assert covenant just for the cost of typing the document.

Of course, this doesn't help protect against patent trolls directly (although over the long term it will since most patents in an area come from parallel filing), nor does it address the problem of deficient covenants, but I believe a key improvement to the world of standards would be to have all bodies generating software patents require participants in their processes lodge patent non-assert covenants instead of the common current practice of simply requiring a best-effort disclosure.

It's high time standards bodies worldwide caught up with the needs of open source. We need more companies to issue - and expect - patent non-assert covenants, especially since those with the largest patent portfolios have yet to start issuing them, despite their claims of support for open source. Some time soon we'll need to collectively shun "standards" (and indeed vendors) who won't protect developers in this way.

Message to Denmark: Dual Format Standards Are Bad

I gave an interview at JavaOne which seems to be causing a stir because of the way it's being spun in translation in Denmark. The spin seems to be suggesting that I think it's OK to have a dual standard in a country for document formats, both ODF (the open format used by multiple applications including Microsoft Office¹) and OOXML (Microsoft's Office 12 file format).

To be clear, I do not believe that. It's clearly Microsoft's strategy to socialise that idea but it's not an ideal outcome. Having a single, baseline standard for document files is clearly preferable, and because of its complexity and the way it unfairly advantages Microsoft's existing products, OOXML is clearly a very poor choice for a national standard. Thus I would always advocate having a single standard and making that standard ODF. It's good for Norway and others, so why not for Denmark too?

Will that happen in Denmark? Well, the amount of pressure Microsoft is bringing to bear on the Danish government by funding lobbying, media activity, astroturfing and more, I am worried that the legislators will cave and have a dual standard. That may sound pragmatic but in practice that's a disaster for Denmark. Because of the existing market power of the monopolist², Denmark's history, culture and due process will end up in a format that can only be faithfully rendered with Microsoft products³.

My comments were meant to indicate that fear, and any version of them stating I support a dual standard in Denmark or any other place is incorrect. The best future for computer-maintained documents is ODF⁴ and I recommend Denmark follow the trend and standardise on it.

1. Via Sun's free ODF plug-in, although it ought to be a built-in feature of Office if Microsoft are serious about interoperability.
2. The Rambøll report already indicates the scale of the lock-in the country faces - it's assumptions of continued use of MS products are what pushed the cost up for alternatives. It seems to me that suggesting writing this monopoly into the law makes the situation worse, not better.
3. We can already see how impossibly hard OOXML is to implement, from the poor quality of the (partial) translators that people have built and the repeated delays of Microsoft's own Mac implementation. I said more in the audio interview on this subject.
4. Probably with an allowance for added-feature namespaces layered over it to allow products like MS Office to have proprietary features. Having ODF as a baseline does not preclude inclusion of either backward-compatibility capabilities or added-feature support, it just sets an interoperability baseline that does not assume the perpetuation of Microsoft's monopoly.

Adobe Adds Non-Assert

I just got home from a great day at JFokus in Sweden, so this is my first chance to pass longer comment on Adobe's excellent move to turn PDF into a ratified international standard like ODF. I first saw the news in Duane's blog and saw from there that they are sensibly using AIIM as the steward. This approach - waiting for the spec to stabilise before standardisation - is exactly the right thing to do and I understand the balance one needs to make between concern for the existing user base and desire to formalise the established standard. Stephen has one his Q & As on the news which is worth reading, especially for the implication of importance to the ongoing tussle between Microsoft and the rest of humanity over document formats.

When I saw the news, the first thing I went looking for was the details of how Adobe will handle all the patents associated with PDF, since it undoubtedly has a substantial portfolio. On Monday there was nothing at all about that in the announcement or the FAQ, so I asked on Duane's blog. Interestingly Stephen doesn't cover this important topic.

I just got a note from Duane with the very welcome news that Adobe has in fact decided to issue a Covenant not to sue surrounding its patent portfolio for PDF. They've added this fact to the end of the FAQ.This is excellent news since it frees the forthcoming ISO standard for implementation by Free and open source communities. Kudos to Adobe for taking this increasingly normal step with their standard, and to Duane for acting so fast to get it sorted.

Security Blankets

I see David Berlind has been asking for my opinion on Microsoft's new non-assert covenant. Keeping in mind that (a) Kim didn't send me an e-mail to tell me about it, let alone an advance review copy like Andy Updegrove, and (b) I have been in a meeting all day where my boss kept shutting the lid of my laptop each time I tried to go online, here are a few off-the-cuff comments.

To be clear (and to encourage Kim to send me a review copy next time!), I think this is a welcome step from Microsoft that I've been calling on them to take for quite some time. Eve Maler has a good analysis, and this seems to be a generally OK covenant document in the same spirit as the covenants Sun has issued around ODF, SAML and Web SSO. Kim Cameron is to be congratulated both for this specific outcome and for the (undoubtedly difficult) process of pushing Microsoft to this point.

However, it does contain three issues that I'd like to see addressed:

1. First is the phrase "necessary claims". Whenever I see this phrase my lawyer alarm goes off as it immediately involves a judgement call which is the subjective right of the patent holder. It comes accompanied by the question "was our patent really necessary for this implementation? Surely you could have done it this other way and thus not needed it. It's actually not necessary so here's the invoice." I'd like to see that phrase replaced with language to indicate that no patent claims will be made against source code implementing the standard, with no necessity test involved.
2. Second, the phrase "to the extent it conforms" is worrisome. Just as with the earlier language around Office 12 XML, it leaves open the question of who is the arbiter of conformance. It also means that open source is placed under a FUD cloud; development is carried out in public so partial and non-conforming implementations are sure to exist. I'd like to see this replaced with language to indicate that the good-faith intent to implement the standard is sufficient to gain coverage.
3. Third (and most complex to explain) is the asymmetry of the patent peace. The patent grant is limited to necessary claims as I mentioned in 1 above, yet the cancellation of that grant is triggered:

   If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you.

   That means that while Microsoft only grants me "necessary claims" I have to effectively grant them cover on all claims, necessary or not. That asymmetry has to be corrected.

I assume Microsoft will look into all of those, and it's on that basis I'm sending Kim a virtual handshake of congratulations. Let's hope they go back and apply them in the other areas where we are all in doubt, like CallerID and Office 12 XML.

One more thing to note is a rare error by Andy Updegrove. He says IBM was first with a patent non-assert covenant, but I don't agree. IBM made a public grant of 500 specific patents. While that's a fine gesture, it does not give software developers much in the way of a freedom from FUD as they have to analyse and then implement the patented ideas in order to gain protection (and the grant was only to open source developers as I recall). Software patents contain little that's useful to a programmer, so a list of patents is pretty much useless.

Sun's ODF covenant pioneered the idea of a blanket covenant, where the patents are not enumerated. This is absolutely key for open source developers. A list of standards where there's a guarantee that there will be no litigation is very useful. It means a developer can implement secure in the knowledge that those most likely to hold patents - the companies who co-developed the standard - covenant never to attack implementations of the standard.

Microsoft is now following suit. This is what open source needs - freedom from fear of attack, not the donation of unintelligible patents. It's time that became a requirement software standards bodies placed on their participants. To set that direction, we now need IBM to endorse and issue blanket covenants too - how about it, Bob?

Loosely Coupled

As I have been preparing for speaking events recently, I have started to realise that there's a common thread joining all the projects I have been involved in over the last decade. In 1995, I was one of the five instigators of the use of the Java platform at IBM; in 1997 I was IBM's spokesman for the newly emerging XML standard; in 2001 I was involved at Sun in what would become known as Service Oriented Architectures (SOA); today, I have a deep interest in OpenDocument format (ODF).

It may seem surprising that all these are connected, but they are. As I have been explaining now for a decade, the source of many costs in IT infrastructures result from different organisational units with no (or distant) shared management being forced to create technical interdependencies in order to co-operate. The less technology we are forced to share in order to co-operate, the less we will have to pay to get started and the less we will need to pay in the future to maintain - or remove - the ability. We need to stay loosely-coupled - connected by the least possible thread of technology.

What forces us to share technology in order to collaborate? Closedness. When solutions are single-vendor, when they use formats and APIs that aren't open (either by being non-standard or predicating use of a closed technology), using them for co-operative activities couples us to each other at a technology level. The opposite of this, promoting free choice and loose technology coupling, is open standards implemented as open source in open communities.

When we are loosely-coupled in this way, we can make our own decisions about what technologies to use within our own span of control, and you can make your own decisions on all these things, yet we are still able to co-operate over the things that matter to us. So each of the things I listed above express this principle. Java technology decouples applications from platforms; XML decouples data from applications; SOA decouple processing end-points; ODF decouples desktop data from the tool that maintains it. Each of these things potentially enables the freedom to leave.

Loosely-Coupled Workflows

Back in 1997, I was working to evangelise XML as the data format of the future. One of the common questions I was asked was "where should I use XML". I explained back then that XML was ideal as a language for describing data in transit between two groups of people of systems that were not under the same management. What you used in your workgroup or department was up to you, but pervasive networks meant you would increasingly be working with people well outside your authority umbrella. In those cases, a format would be required that minimised the technical coupling encountered during attempts to collaborate.

Use of binary formats led to a need for tight coupling of the parties consuming and creating them as well as of both parties to the entity controlling the format. I asserted back in 1997 that XML promoted the same loose coupling for data as the use of the Java platform allowed for programs. This was a recurrent theme of my keynotes in the late 90s.

Fast forward nine years and it seems we're entering the stage I forecast back in 1997, but for documents. I've been using the term "workflow" recently in discussing the way ISO 26300 OpenDocument (ODF) fits the way people are increasingly working. We've already seen that the concept of a "Service Oriented Architecture" is intellectually appealing (even if it's been hijacked by complexity fiends), and I see no reason why the desire to have organisationally loosely coupled entities co-operate should force them to become technically interdependent.

Best Tool For The Job

Hence my overloading of the term "workflow" (and search for a synonym I can use instead). The truly great thing about Microsoft's flawed announcement last week is that it takes the product and vendor dynamics off the table as obstructions and allows us to focus on what really matters - working together efficiently in a connected, participation age. Everything is going to be able to open and save ISO26300 OpenDocument files in time. Everything. Now we can distinguish between the policy decision about what's flowing between and the pragmatic decision of what's being used within. Loosely-coupled workflows are the answer.

For example, I may choose to use the very promising browser-only Zoho Writer [thanks, Robert] which promises to be able to both open and save OpenDocument files and thus, by giving me the freedom to leave gives me the confidence to stay. Or I may be a writer with special interface needs because of a disability, locked into some version of Microsoft Word because the accessibility device I paid a fortune for only works there due to a lack of accessibility standardisation (which, by the way, is getting fixed fastest on GNOME). Or I may use OpenOffice.org or NeoOffice or something. Who cares. That's my choice, and whatever you have chosen you have no right to dictate what I use.

Networks-Of-Purpose

Meanwhile, the networks-of-purpose within which I participate can still mandate the format I have to use to exchange documents with other network members. Those networks will choose OpenDocument simply because it opens up the widest range of choices, from the crustiest version of Word to the newest, most exciting ideas like Zoho Writer. They will choose OpenDocument because it offers a baseline that will still be readable for decades yet will also provide a baseline on which innovation can be built. And they will choose OpenDocument because it is transparently in the stewardship of a truly open standards process and licensed in a truly no-strings-attached way.

So when you hear me talking about "loosely-coupled workflows" in this context, this is what I mean. I can choose the best tool for the job to do the work, but when the work flows between loosely-coupled partners in my network it won't make us technology-dependent on any given platform, tool or vendor. If loosely-coupled is good enough for SOA it's good enough for documents too.