lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proprietary Software term


From: David Wright
Subject: Re: Proprietary Software term
Date: Thu, 23 Aug 2018 15:21:04 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat 18 Aug 2018 at 22:18:51 (+0200), David Kastrup wrote:
> David Wright <address@hidden> writes:
> 
> > On Sat 18 Aug 2018 at 19:55:01 (+0100), Wols Lists wrote:
> >> On 18/08/18 12:51, David Kastrup wrote:
> >> >> Indeed, that wasn't expressed too well. What I meant is that
> >> >> > CodaMusic's policy to use binary non-released (for some time even
> >> >> > encrypted) file formats strongly discouraged anyone to make a program
> >> >> > use these files.
> >> 
> >> > That's more than just lock-in.  Don't know a good expression, but that's
> >> > more like locked-away (don't know a good expression for it) since the
> >> > format is designed to keep the user from being able to access his own
> >> > information (and/or that of others).  In my book, that's a no-no since
> >> > it renders archiving worthless.
> >> > 
> >> Undocumented proprietary format.
> >> 
> >> I compare WordPerfect with Word ... Word's format seems to change with
> >> almost every release, the changes being in many cases apparently to
> >> interfere with compatibility with other programs.
> >> 
> >> While WordPerfect's format, although proprietary, was well-documented,
> >> with defined extensibility, and a guarantee of compatibility. To the
> >> extent that WordPerfect 6, released in 1994, is to the best of my
> >> knowledge capable of editing and saving - WITHOUT DAMAGING IT - a file
> >> created by the latest version. So any WordPerfect-compatible program
> >> should be able to do the same.
> >
> > "Undocumented proprietary format" doesn't express the intent which
> > "lock-in" does. As David pointed out, patents can be used to protect
> > a proprietary format, only I don't think that, for example, the exFAT
> > filesystem is, in his words, a "strange case".
> 
> A filesystem is not a file format.

Sure. But it's a format, and it may be proprietary, and it may be
undocumented. The distinction I'm making encompasses a wider range of
instances than just *file* formats¹, and concerns itself with intent
rather than mechanism.

Urs mentions encryption being used by CodaMusic (I've never heard
of them) and that clearly shows an intention of lock-in. OTOH Wols
doesn't lay out here the evidence of the reported intent of Word's
changes. (Actually, I thought it was an open format nowadays.)

But as I'm not in the habit of using proprietary file formats,
it's not that easy to come up with good examples I know much
about, so I used a filesystem example instead.

In the past, AIUI it was necessary to obtain a licence to write
a file in a specific GIF format. While that was the case, it
would not be wise to try and circumvent the licence merely by
writing from scratch a program to write the file. Just saying the file
has a "proprietary format", whether documented or undocumented,
doesn't express the intent that "lock-in" does.

One filesystem (yes, filesystem) format that I *am* in the habit of
using, like countless others, is FAT32. Fortunately its MS patent has
been interpreted as meaning that you can create files with long
filenames, or with short ones, without a licence; but to create a file
with both types of filename, you need a licence. Not having one
proved expensive for TomTom.

With the AARD code I mentioned before, the boot was on the other foot
because its perceived intent fell foul of the US anti-trust laws.
I've read that that settlement cost MS $280M.

So that's my point: intent, and not just whether it's documented.

¹ Though as Wols pointed out, a filesystem is just a format in which
to write a particular type of file: a device file. If the file is
described in a hard drive's partition table, it will normally be
termed a "partition". One could make a backup copy with
# dd if=/dev/sdb1 of=/tmp/backup-copy

Cheers,
David.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]