7 Mar
2012
7 Mar
'12
10:57 a.m.
Christian Bartsch | Kryoflux LTD. (cb at kryoflux.com) wrote on Tue Mar 6 02:30:32 CST
2012:
Hi Tony,
...
/ 2) Is there any truth to the comments about a
'conflict of interests' if
/>/ somebody wants to devleop both for
your device and the Diskferret?
/
Suggestions like that (the original statement, not your question here)
would you get thrown out of my house for sure. Why would any large, big,
mighty institution be hindered by us to look at a competitive product?
Why would they let us hinder them? If they could get something better
that would be completely free, why would they want to take the solution
that needs to be paid for? How could I stop them from using publically
available sources?
Christian, if there's no anti-compete clause in the license, then please
explain what exactly clauses 3.a.v and particularly 3.a.vi do.
Also, for third party/open-source IPF stuff (other than the potential
for GPL software to be used commercially, already expressly forbidden by
3.a.v), clauses 3.d.i and 3.d.ii would also seem to expressly forbid it?
3.d.ii seems to imply that it violates the license to even convert an
IPF to other formats, which makes IPF images entirely useless as a
general preservation format because of the legal minefield they're stuck in.
This is one of the most deceptive licenses I've ever read; the top
preamble implies it gives the user great freedom but instead it almost
totally locks everything they've done and can do down to "a SPS product
defined by SPS". I'm going to stay far, far away from any products
Kryoflux LTD./SPS puts out unless you seriously rethink your licensing,
since by contributing to the Discferret project I'm apparently already
in violation of it.
No wonder none of the organizations you sold your CTA analyzer to want
anything to do with Phil's product, the license expressly forbids them
from even considering it.
For reference:
2. LICENCE.
I. LICENCE for IPF SUPPORT LIBRARY
SPS hereby grants you (each licensee is addressed as "you") a
non-exclusive, non-transferable licence to use the Technology, on the
following terms and only for private, non-profit purposes (see
Section 3 below).
You may:
...
c. inspect ("understand") the source code (if provided); and
...
3.LIMITATIONS ON LICENCE.The licence grantedin Section 2 is subject
to the followingrestrictions:
a.The Technology is to be used onlyfor non-profit purposesunless
you obtain prior written consent fromSPS.Prohibited for-profit
and commercial purposesinclude, but arenot limitedto:
...
(v) Using the Technology to develop a similar application on any
platform for commercial distribution, except to the extent this
restriction is prohibited by applicable law; or
(vi) Using the Technology in any manner that is generally
competitive with a SPS product as defined by SPS, except to the
extent this restriction is prohibited by applicable law.
...
d. You may not modify, combine commercial applications with the
Technology. You may not prepare derivative works of the Technology,
except to the extent this restriction is prohibited by applicable law.
Derivative works are defined as but not limited to:
(i) Alternative support libraries. We are open to porting to other
platforms, and so third parties doing such is unnecessary and
violates the terms of this licence. If you want to port the
library, please contact us. We will host it on our site and ensure
that only the latest version is being distributed.
(ii) Alternative tools that operate on files of the format as
defined by the Technology. This includes but is not limited to:
mastering tools(tools that enable Content to be written back to
physical media like a floppy disk). Reproducing Content provided
through or by the Technology to any other kind of media, such as
alternative content provider technology(this also covers any kind
of converter with the intention of extracting the Content to held
by any other alternate media format that represents the same
independently working Content). Additions, removals or other
modification of data contained by the images.
...
To anyone who wants to read further, the license text can be seen in
full as "LICENCE.txt" in the "Download the latest software" archives
at
http://www.kryoflux.com/
--
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com
jgevaryahu at hotmail.com
8 Mar
8 Mar
12:48 p.m.
Christian, if there's no anti-compete clause in
the license, then please
I haev read the license, and although IANAL, I was astounded by it. IMHO
anyone who agrees to that needs their head examining!.
As I understand it, you can read such source code as is provided, but
uyou can;'t modify it or compile it, even for your own use.
You can't make 'competing products'. In partciular you can't write
programs to dump the image files back to physical disks. And as I
understand it, the free version fo the scftware won't do this, you have
to pay for that capability.
So if, in the future, the Kryoflux software is no longer available, there
is no legal way to make physcia ldisks from the images. This does NOT
sound like a good idea for preservation to me.
FWIW, I think this part about not developing cometing productis is 100%
ridiculous. My lathe didn't come with a l'license' telling me I could not
make accessories that competed wit hthe offical ones, in fact it's
expected that you will. My HP calculators don't come with licenses
prohibiting me from using them for calculations involved in designign
prodcuts that compete with HP. I've never seen a license agreement for a
compiler that prohibts you from using it to develop other compilers
(including oens for that same language). And so on.
-tony
4:54 p.m.
I haev read the license, and although IANAL, I was
astounded by it.
IMHO anyone who agrees to that needs their head examining!.
I haven't read the whole thing, just snippets jgevaryahu posted here.
But, based on those snippets (and assuming they're accurate, of
course), I think you're overstating the case. For example...
You can't make 'competing products'.
...no, you can't use "the Technology" to make competing products.
jgevaryahu didn't post enough for me to be sure what "the Technology"
means - and I would check if I cared - but I would expect it to refer
to KryoFlux's work and nothing more, in which case this strikes me as
eminently reasonable.
In the stuff jgevaryahu posted, most the restrictions cited are of this
nature. I do see one glaring exception, that being 3.d(ii); if I were
doing data preservation any such clause in the license for a tool would
completely eliminate that tool from consideration for me.
Actually, if I really cared, I'd look into the possibility that their
idea of what constitutes a derivative work disagrees with applicable
copyright law, which might end up leading to simply ignoring that
clause (I'm not sure whether a license gets to redefine
well-estbalished technical terms like "derivative work"). On the other
hand, the potential hassle factor of dealing with an infringement suit
also might lead me to drop the option even then.
It most certainly would cause me to include them out of anything I
might do as an individual. Closed file formats - and this is an even
more egregious form of "closed" than most - are nonstarters for me.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:01 p.m.
On 03/08/2012 07:54 PM, Mouse wrote:
It most certainly would cause me to include them out
of anything I
might do as an individual. Closed file formats - and this is an even
more egregious form of "closed" than most - are nonstarters for me.
I've been trying to stay out of what has become a very "barbed"
thread, but this time I can't resist voicing agreement.
Closed file formats are indeed evil; only the clueless would disagree
with that. But the important part of my point is: Aren't floppy disks
which have no reasonable way of being read, which is the exact purpose
of the product, the very epitome of a "closed file format"?!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
5:30 p.m.
At 07:01 PM 3/8/2012, Dave McGuire wrote:
But the important part of my point is: Aren't
floppy disks which have no reasonable way of being read, which is the exact purpose of the
product, the very epitome of a "closed file format"?!
Yeah, but the companies are long-dead and their developers aren't
on the list, so who else can someone bitch at?
- John
5:42 p.m.
On 03/08/2012 08:30 PM, John Foust wrote:
At 07:01 PM 3/8/2012, Dave McGuire wrote:
I have no problem with the bitching. Just saying replacing one
"closed file format" with another is probably a bad idea.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
But the important part of my point is: Aren't
floppy disks which
have no reasonable way of being read, which is the exact purpose of
the product, the very epitome of a "closed file format"?!
Yeah, but the companies are long-dead and their developers aren't on
the list, so who else can someone bitch at? 
5:52 p.m.
Yeah, but the companies are long-dead and their
developers aren't
on the list, so who else can someone bitch at?
This hold thread has been a waste of typing. It's like a bunch of Jews
and Baptists trying to convert each other.
Actually, that is how all open/closed source arguments are, right?
--
Will
5:57 p.m.
On 03/08/2012 08:52 PM, William Donzelli wrote:
Well, except there are very clear lines between "good" and "bad" in
this case.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Yeah, but the
companies are long-dead and their developers aren't
on the list, so who else can someone bitch at?
This hold thread has been a waste of typing. It's like a bunch of Jews
and Baptists trying to convert each other.
Actually, that is how all open/closed source arguments are, right?
5:53 p.m.
Closed file formats are indeed evil; only the clueless
would disagree
with that. But the important part of my point is: Aren't floppy
disks which have no reasonable way of being read, which is the exact
purpose of the product, the very epitome of a "closed file format"?!
They are indeed. I don't have much to do with such things; if I were
doing data preservation, the whole point of my work would be to replace
such a thing with something that _can_ be read.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
7:43 p.m.
Dave McGuire wrote:
Closed file formats are indeed evil; only the
clueless would
disagree with that.
Anyone making money with products using closed file formats would
probably disagree. Are they all clueless? I don't think so. They're
making a lot more money than I am, so they must have a clue about
something. That doesn't mean that I like or admire them, just that
dismissing them as clueless is unwarranted.
Certainly from an end user's point of view, there is little or nothing
to recommend closed file formats, and it is in the interest of end users
to avoid them like the plague.
But the important part of my point is: Aren't
floppy disks which
have no reasonable way of being read, which is the exact purpose of
the product, the very epitome of a "closed file format"?!
Yes.
7:52 p.m.
On 03/08/2012 10:43 PM, Eric Smith wrote:
Ok, there's the exception of people peddling such things to the
users. They're (possibly) not clueless...but they're certainly sleazy.
Closed file
formats are indeed evil; only the clueless would disagree
with that.
Anyone making money with products using closed file formats would
probably disagree. Are they all clueless? I don't think so. They're
making a lot more money than I am, so they must have a clue about
something. That doesn't mean that I like or admire them, just that
dismissing them as clueless is unwarranted. Certainly from an end user's point of view, there
is little or nothing
to recommend closed file formats, and it is in the interest of end users
to avoid them like the plague.
Yup. And since the vast majority of them are clueless, the sleazy
people who peddle products based on closed file formats end up with a
very nice (for them) situation of vendor lock-in, where your data is
very literally held hostage for a ransom.
Not with MY money, thankyouverymuch!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
8:17 p.m.
I wrote:
Certainly from an end user's point of view, there
is little or nothing
to recommend closed file formats, and it is in the interest of end users
to avoid them like the plague.
Dave McGuire wrote:
Yup. And since the vast majority of them are
clueless, the sleazy
people who peddle products based on closed file formats end up with a
very nice (for them) situation of vendor lock-in, where your data is
very literally held hostage for a ransom.
Not with MY money, thankyouverymuch!
Hmmm, that's some nice data you've got there. You wouldn't want
anything to *happen* to it, would you? You'd better keep it in our
proprietary file format for safety!
8:34 p.m.
On 03/08/2012 11:17 PM, Eric Smith wrote:
I wrote:
Exactly.
We do a bunch of stuff like that, things that make no sense
whatsoever. The one that dawned on me not long ago was the realization
that, every pay period, nearly all of us willingly hand over our
paychecks to what is well known to be the least-trustworthy segment of
society for "safekeeping".
I'd sooner trust it to the crack dealer on the corner. At least his
ilk is sometimes honest about being a criminal.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Certainly from an end user's point of view,
there is little or nothing
to recommend closed file formats, and it is in the interest of end users
to avoid them like the plague.
Dave McGuire wrote:
Yup. And since the vast majority of them are
clueless, the sleazy
people who peddle products based on closed file formats end up with a
very nice (for them) situation of vendor lock-in, where your data is
very literally held hostage for a ransom.
Not with MY money, thankyouverymuch!
Hmmm, that's some nice data you've got there. You wouldn't want anything
to *happen* to it, would you? You'd better keep it in our proprietary
file format for safety!
9 Mar
9 Mar
12:18 p.m.
Closed file formats are indeed evil; only the
clueless would disagree
with that. But the important part of my point is: Aren't floppy disks
which have no reasonable way of being read, which is the exact purpose
of the product, the very epitome of a "closed file format"?!
No, I don't think they are. It's the difference between a genuinely
difficult problem (reading an undocumented floppy disk) and one that's
artificially difficulty (a file format that's 'closed' for legal reasons).
In any case, I don't think this is a good jsutificatio nfor a closed
image file format. The idea of preservation it ot make the data easier to
read/interpret/archive, not to keep the problem at the same level.
-tony
2:02 p.m.
On 03/09/2012 03:18 PM, Tony Duell wrote:
That was not at all the point I was trying to make. It was late and
I was tired; I guess I didn't word it very well.
I was trying to suggest that replacing one "closed file format"
(difficult-to-read floppies) with another is a really bad idea.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Closed
file formats are indeed evil; only the clueless would disagree
with that. But the important part of my point is: Aren't floppy disks
which have no reasonable way of being read, which is the exact purpose
of the product, the very epitome of a "closed file format"?!
No, I don't think they are. It's the difference between a genuinely
difficult problem (reading an undocumented floppy disk) and one that's
artificially difficulty (a file format that's 'closed' for legal reasons).
In any case, I don't think this is a good jsutificatio nfor a closed
image file format. The idea of preservation it ot make the data easier to
read/interpret/archive, not to keep the problem at the same level. 
5:16 p.m.
On 03/09/2012 04:02 PM, Dave McGuire wrote:
I was trying to suggest that replacing one
"closed file format"
(difficult-to-read floppies) with another is a really bad idea.
Well, it takes time and effort, but if the first format is at risk of
becoming unreadable then there is some merit in doing it.
What doesn't make sense to me is going from one closed format to another
when I could go from a closed format to an open one (assuming that the open
one meets my needs equally).
What I'd really like to see in files for preservation - now that storage is
cheap and plentiful - is the spec for the format itself embedded at the
start of the file. If I'm faced with an unknown file format I usually poke
around it with an editor for clues as to what it might be, so having the
spec right there in plain English would be useful. (And we've had that
discussion on the list before, and yes, it does rely on future generations
being able to read English and ASCII being a sensible way of recording it)
cheers
Jules
10 Mar
10 Mar
4:28 a.m.
New subject: Closed image formats (was: Discferret Broken?)
The idea of preservation is to make the data easier
to read/interpret/archive, not to keep the problem at the same level.
This is a very important point - if you are archiving disks for
historical reasons, you have to realize that like the original systems,
the tools you are using now will eventually become difficult if not
impossible to use on future "modern" hardware. It then becomes
critical to be able to recover the data by other means.
Another big reason to use a documented format is that you may
want/need to do other things with the data besides write it back to
original format disks ... the original system may not be available
or working. It may not have the means to transfer data other than
by reading it's floppies. You may be trying to extract files from the
disk, or run it under emulation. To do these things, you need to be
able to access the data directly from the image file, and to fully
understand how that data is organized.
Also, don't assume it will be "the same level" - It may be "worse
level"
It may be easier to read data from the original documented-format
disks than to reverse engineer the closed proprietary image file.
This becomes a major issue when all you have left is the image file.
This is why I specifically documented and placed the ImageDisk
file format into the public domain. The ability to do this was one of
my primary motivations in creating the program. Nobody owns the
format, and nobody can ever restrict what you do with it. I strongly
urge anyone who is creating other disk/data imaging systems to
do the same.
--
dave12 (at) Dave Dunfield
dunfield Firmware development services & tools: www.dunfield.com
(dot) com Classic computers: http://www.classiccmp.org/dunfield/
1:22 p.m.
New subject: Closed image formats (was: Discferret Broken?)
The idea of
preservation is to make the data easier
to read/interpret/archive, not to keep the problem at the same level.
This is a very important point - if you are archiving disks for
historical reasons, you have to realize that like the original systems,
the tools you are using now will eventually become difficult if not
impossible to use on future "modern" hardware. It then becomes
critical to be able to recover the data by other means.
Another big reason to use a documented format is that you may
want/need to do other things with the data besides write it back to
original format disks ... the original system may not be available
or working. It may not have the means to transfer data other than
by reading it's floppies. You may be trying to extract files from the
disk, or run it under emulation. To do these things, you need to be
able to access the data directly from the image file, and to fully
understand how that data is organized.
In other words you never know what a future enthusiast or historian may
wish (or need) to do with this data so you make it as easy as possible to
do anything with it.
This is why I specifically documented and placed the
ImageDisk
file format into the public domain. The ability to do this was one of
FWIW, I wronte a simple set of programs to read, image, restore, etc the
disks used by soem older HP calculators, HP41, HP71, etc). I defined a
trivial image file format, which I documetned in the following way :
liffile(5) LIF Utilities liffile(5)
NAME
liffile - HP9114 LIF disk image file
DESCRIPTION
The HP9114 LIF disk image file format was designed as a
simple way to store HP9114 disk images on a larger com-
puter, and to allow programs to be written to process
those images (including writing them back to a physical
disk).
IMAGE FILE & LIF LOGICAL BLOCKS
The file consists of a raw dump of the data blocks on the
disk, in increasing numerical order. There are no headers
or trailers added, either for the entire image or for each
block. That is to say :
Bytes 0 to 255 are LIF logical block 0
Bytes 256 to 511 are LIF logical block 1
Bytes 512 to 767 are LIF logical block 2
and so on
As an HP9114 disk contains 2464 user blocks (organised as
77 cylinders, 2 heads, and 16 sectors per track, with each
sector being 1 block), an image file is always 2464*256,
or 630784, bytes long.
LIF DISK PHYSICAL BLOCKS
The correspondence between the logical block numbers
described in the last section and the physical sector
addresses on the disk is also straightforward. The cylin-
ders on the disk are numbered from 0 to 76. the 2 heads
(sides) are called 0 and 1, and the sectors on each track
are numbered from 0 to 16. Then :
Block 0 is cylinder 0, head 0, sector 1
Block 1 is cylinder 0, head 0, sector 2
Continuing on cylinder 0, head 0, until...
Block 15 is cylinder 0, head 0, sector 16
Block 16 is cylinder 0, head 1, sector 1
Continuing on cylinder 0, head 1 until...
Block 31 is cylinder 0, head 1, sector 16
Block 32 is cylinder 1, head 0, sector 1
LIF Utilities 16-March-2002 1
liffile(5) LIF Utilities liffile(5)
And continuing in this manner for all 77 cylinders
PSEUDO-CODE TO WRITE AN IMAGE TO DISK
Assuming the necessary functions exist to seek the disk
head to a particular cylinder ( seek() ) and to write a
256 byte sector ( writesector () )
) then it is reasonably easy to write a program to trans-
fer a disk image to a physical disk. The following
pseudo-code gives the basic idea :
declare blockbuffer to be 256 bytes long
open(image file)
for cylinder=0 to 76
seek(cylinder)
for head = 0 to 1
for sector = 1 to 16
read next 256 bytes of image file into blockbuffer
writesector(cylinder,head,sector,blockbuffer)
next sector
next head
next cylinder
close(image file)
end
REFERENCES
The logical block structure of a LIF device is given in
Appendix D of the HPIL Module for the HP71 Owner's Manual
The relationship between LIF logical blocks and
physical disk sectors was determined experimentally.
RESTRICTIONS
Although the LIF Utilities for linux are released under
the GNU public license, the only restriction placed on the
use of this image file format is that no (other) restric-
tions may be placed on its use. Anybody is welcome to
write programs using this file format (for example to con-
vert the image files into other formats, or to transfer
between physical disks and the image format) for any com-
puter or operating system, and to distribute these pro-
grams under any license terms they choose.
LIF Utilities 16-March-2002 2
liffile(5) LIF Utilities liffile(5)
AUTHOR
The LIF image file format was designed by Tony Duell,
ard at p850ug1.demon.co.uk
LIF Utilities 16-March-2002 3
In case it's not clear, the term 'any license terms' includes
closed-source. comemrcial software. All you can't do is prevent others
writing simialr programs to handle such files.
my primary motivations in creating the program. Nobody
owns the
format, and nobody can ever restrict what you do with it. I strongly
urge anyone who is creating other disk/data imaging systems to
do the same.
As do I.
-tony
9 Mar
9 Mar
12:15 p.m.
I haev read the license, and although IANAL, I
was astounded by it.
IMHO anyone who agrees to that needs their head examining!.
I haven't read the whole thing, just snippets jgevaryahu posted here.
But, based on those snippets (and assuming they're accurate, of
course), I think you're overstating the case. For example...
You can't make 'competing products'.
...no, you can't use "the Technology" to make competing products.
jgevaryahu didn't post enough for me to be sure what "the Technology"
means - and I would check if I cared - but I would
expect it to refer
to KryoFlux's work and nothing more, in which case this strikes me as
eminently reasonable.
In the stuff jgevaryahu posted, most the restrictions cited are of this
nature. I do see one glaring exception, that being 3.d(ii); if I were
doing data preservation any such clause in the license for a tool would
completely eliminate that tool from consideration for me.
Actually, if I really cared, I'd look into the possibility that their
idea of what constitutes a derivative work disagrees with applicable
copyright law, which might end up leading to simply ignoring that
clause (I'm not sure whether a license gets to redefine
well-estbalished technical terms like "derivative work"). On the other
hand, the potential hassle factor of dealing with an infringement suit
also might lead me to drop the option even then.
Well, given the choice between 2 options, one of the which (usign the
DiskFerret) certainyl avoids any legal trouble and the other (using the
Kryoflux) _may_ not, I think I'd pick the former.
It most certainly would cause me to include them out of anything I
might do as an individual. Closed file formats - and this is an even
more egregious form of "closed" than most - are nonstarters for me.
Absolutely.
-tony
4446
days inactive
4449
days old
18 comments
9 participants
participants (9)
-
ard＠p850ug1.demon.co.uk -
dave12＠dunfield.com -
eric＠brouhaha.com -
jfoust＠threedee.com -
jgevaryahu＠gmail.com -
jules.richardson99＠gmail.com -
mcguire＠neurotica.com -
mouse＠Rodents-Montreal.ORG -
wdonzelli＠gmail.com