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

Re: Defining 'preferred form for making modifications'



(I apologize for the fact that this won't thread.)

>J.D. Hood wrote:
>> On the other hand, if there is a set of different forms
>> each of which is convertible into the others by means of
>> freely available tools then any member of the set is as
>> good as any other.
Andrew Suffield <asuffield@debian.org> wrote:
> What if the program is written using proprietary tools and formats,
> and translated into commented, maintainable C/java for release?

By hypothesis we have free tools that convert the C/java program
into the proprietary format.  So if the proprietary is the format 
you want to use, simply convert it into that format.  You are
happy.

> Richard Braakman <dark@xs4all.nl> writes:
>> I know of one thorny problem in this area: many graphics are distributed
>> as .png or .jpg files, even though their creator probably used a richer
>> format like .xcf.
Thomas Bushnell wrote:
> Is it not obvious that the preferred form is .xcf?

I think it is obvious because we do prefer the informationally
richer format.  My suggestion is that this be made explicit.

Thomas Bushnell wrote:
> No.  It is *human*, and focused on actual, real, genuine, human
> preferences.  This is far better than trying to find a specific
> technical definition of those preferences: much better instead to use
> the actual standard--that is, whatever format is actually
> preferred--rather than attempt (perhaps badly) to find a technical
> definition of the same thing.

The focus on human preferences tends to end up either in subjective
assessments or in speculation about what other people prefer.
Should these questions be settled by conducting surveys?

"Joe Moore" <joemoore@iegrec.org> wrote:
> Unfortunately, there is a class of tools which do not meaningfully
> change source code, but result in an information-theoretical loss.
> indent(1) is a prime example of this class.  Running indent(1) on
> Free Source should not make it non-Source.

In general if you possess both a non-indent(1)ed version of the
program you are distributing and version of the program that you
have run through indent(1), then I want the non-indent(1) ed version.
It is quite possible that the hand-indented version is easier to
read than the version that has been run through indent(1).  If
not then I can run indent(1) on it myself; whereas if you give
me the indented(1) version then I can't get the hand-indented
version back.

> There is also a class of tools which makes source effectively
> unmodifiable, but is not information-theoretically lossy.
> For example, an obfuscator which translates everything to C
> trigraphs.  Running this on Free Source makes it non-Source.

It isn't non-source if there are freely available tools for
transforming it back into the original form.

Tar+gzip is an example of such an obfuscator, but no one thinks
that a gzipped tarball isn't source!

> Finally, there is a very lossy conversion which must be Free,
> and that is linguistic translation.

Nope.  If you are distributing the binary with English UI then
I don't want the source with the UI translated lossily into
Romanian.

You are convincing me that my suggestion wasn't a bad one.

BTW I don't think that a *purely* information-theoretical
definition can be given.  I just think that info-theoretical
concepts might be used in the definition in order to help
provide an objective basis for the preferred-to relation.

--
Thomas Hood








Reply to: