Like when windows extended Java then started adding incompatibile methods to the windows Java extension that would be on all windows computers? Or maybe when office used a hidden format to store files so no one could share files without buying a license? They were not great times at all...

It's interesting to compare those two examples in the context of the present copyright controversy. In the Visual J++ case, obviously Sun having copyright control over all Java reimplementations would have given them more leverage than just the trademark (though they were able to kill J++ with what they had).

But in the case of proprietary file formats, or really any non-crypto-based attempt to hinder interoperability, the less control, the better. For example, Microsoft could have hypothetically designed their DOC format for the explicit purpose of creating legal issues, such as by having files consist of a series of API calls to reconstruct the document (like WMF!), so that anyone parsing the document would have to reimplement the APIs. To be fair, the need to do so for actual compatibility would weigh heavily in favor of fair use, whereas the story with Android is somewhat weaker (especially because nobody seems to have told the Federal Circuit that Android actually is compatible with existing Java libraries, rather than the API copying being solely for the sake of programmer familiarity...) Also, there is no real need to use copyright for this purpose in the first place: patents have been shown to be quite effective in locking down file formats (c.f. H.264, x86 instructions) - and don't have fair use - so arguably copyright gives offenders nothing they couldn't achieve by other means. But then, patents are limited-duration and who knows, maybe the law with respect to them will be improved some day. No need to hand out extra tools.

> Like when windows extended Java then started adding incompatibile methods

Visual J++ was a very usable Java. Had Sun failed to sue it out of existence, the world would have had a Java with a good UI stack developers actually used, an IDE that was not unusably slow and buggy, AND almost all packages built for Sun's Java would drop right in without problems. Visual J++ would have created the same effect on the use of Java that Android did, but it would have happened approximately 10 years earlier.

Sun's suit was tremendously destructive of a very useful product that would have helped the cause of Java's wide use. Unnecessary, spiteful, and an own-goal.

EDIT: And less VB, and more Windows applications software running in a managed language runtime, years earlier.

> an IDE that was not unusably slow and buggy

Can't argue about the UI stack in general, but IntelliJ is a dream compared to anything Microsoft have ever produced.

I'm talking about Forte, circa 2000. That's when Sun sued Microsoft over Visual J++.

Forte later became NetBeans and today it is fine but it was rubbish back then especially compared to Microsoft's tool chain.

Oh because what microsoft did with the web standards with IE5 and IE6 did so much for the web world - it only took what, 10 years to undo the damage? Think if they corrupted early Java in the same way? C# would not exist, but Java would likely be a steaming pile of crap.

Interactive Java was a steaming pile of crap. Have you ever used an awt UI? Has anyone ever successfully coded a Swing UI? Java IDEs, other than Visual J++, needed insanely powerful machines just to come up in less than 10 minutes.

This is what it took to make interactive Java successful in Android: Subtract cross-platformness, add a runtime designed for a specific OS architecture, add a nice UI stack, and add modularity to apps that makes component lifecycle useful to running apps efficiently. Among other mods. Android "corrupted" the fuck out of Java which was absolutely nowhere as a language for interactive software.

Oracle should have gotten on the bandwagon.

Btw, Java has a great UI stack, it is part of Android.

I'm sorry if I missed the humor. But yeah, interactive Java is Android Java. It might have been WFC. It surely was never going to be AWT or Swing.

Was the hold Office format hidden? It was delightfully obtuse and even obfuscated IMO, no doubt about that, but not impenetrable, and you can find the docs describing the file format on Microsoft's site now. Could you not get them 10-15 years ago?

Nope. The formats were completely undocumented. Nothing outside of Microsoft could properly import the formats. Sure things tried, but they inevitably always failed in rather dramatic ways.

Joel on Software had article about the file formats several years ago. Apparently big chunks of the files are basically just memdumps. http://www.joelonsoftware.com/items/2008/02/19.html

I know a guy who worked at Microsoft and left to create a .doc reader for some other software. He said the .doc format wasn't even documented inside Microsoft and pretty much no-one could tell you how to parse it, apart from trial-and-error.

The prevailing idea seemed to be that if you wanted conversion of Word documents, let's say to screenshots, to match properly in all cases, the only way was a dedicated (or virtual) machine running Windows+Word and some VBS to automate the conversion.

I don't know if this is still the best way. LibreOffice has came a long way for sure, but still doesn't reproduce Word's layout perfectly (which is still the expectation).

Some differences in rendering or printing would be acceptable - what is not acceptable, however, is unintended corruption of existing documents.

E.g. if I open a word document in libreoffice (to do e.g. review and commenting), save it without any changes to the layout, then I'd expect the original author to have the same document layout as before... and that is not so. The same applies to LibreOffice Calc - opening and saving the document produces changes.

Can't you just have a unit test that verifies that reading and immediately writing a document should keep it completely unchanged, except possibly for metadata?

Im guessing the unit test would fail. So what good would it do to add a failing unit test?

I do not envy those who have spent years of their life trying to reverse engineer .doc and .xls formats... those are pretty nasty.

why were those not great times? Every open source project can be forked. Want to make MyC++Haxor3000 just fork LLVM and start adding the features you want. Same with python, JavaScript, and many other languages.

My understanding with Java is MS had signed a contract with Sun so there were other obligations. From a purely engineering POV though it makes total sense to extend. When I embed a language in my app (lua, JavaScript, whatever) the first thing I do is expose all my functionality.

Buying software for money: no problem. But the special interests that it created (MS is a convicted monopolist) were exploited beyond the pale.

Ok. Shame on me. You win. Checkmate.

But you won't fool me twice. No more support for "innovation" and "intellectual property" of any kind.

You can still ask me to pay for it, but you won't have the copyright industry stick to swing at me if I decide I'd rather get it from an unsupported source because your version only comes with digital restrictions.

Your argument works against your position, since that happened right as copyright laws were strengthened (even making DRM illegal to circumvent), not weakened.