9 Mar
2012
9 Mar
'12
1:03 a.m.
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.
Jonathan, I think you misunderstood what this is about. Before I go into
detail here, it does make sense to see how "the technology" is defined:
"The program's object code, source code and documentation are
collectively referred to as the "Technology"". Please note that there is
no reference to the file format itself.
It just clearly states one thing: You can not take a piece of our
software and use it to make another piece of software, except for the
exclusions listed. It does not say you can not invent something on our
own or work with a CatFerret or DiskWeasel or whatever device comes to
mind. It is also correct that you could not take the capsimg.dll and put
it into a competing product. You can of course write your own code, or
you could - if it's not a commercial thing - just take a look at our
source distribution. It comes with a different (adapted MAME) licence!
Please take a look yourself:
http://www.kryoflux.com/download/ipfdec_source4.2.zip
This was released to make sure the format is a) fully documented, b)
portable and c) data is not buried.
The reasons for the tight restrictions of the original (old) licence
were e.g. some companies selling game compilation CDs of questionable
origin, which usually did not give credit or pay royalties to the
legitimate copyright holders (=game devs). We did not want to support
such things. Not being able to use IPF for these (or extract the data
with our enabler) meant ADFs were used, which usually sported cracker
intros or similar, making people aware of what they had bought.
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, you are not (I think). Unless you take parts of our product
to
enhance a competitive product, all is fine. In other (unpleasant) words:
If you make your own and don't steal, I don't see any problem there.
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.
Absolutely not. If they were using this very same licence (which they
don't, as it excludes commercial use) they could of course use other
products. They just could not put parts of our product into the other.
9 Mar
9 Mar
5:38 a.m.
No, the problem is the redefinition of Derivative Works to include any
images produced by the device using the KF binary software
distribution. Since the binary blob falls under this license, this
means all IPFs (and STREAM dumps too) that were dumped with the KF.
You could say that the license "taints" the IPFs or STREAM dumps.
Personal editions of software like MS Word has similar clauses
regarding commercially produced works, which means a court in the USA
would possibly uphold it. Even though it basically forces vendor
lock-in and makes it illegal to use any tool other than the
vendor-provided ones to convert the files.
So in the end, though the free implementation of IPF in itself is
legal, converting an IPF dumped with the proprietary distribution
(pretty much ANY IPF) is not, because of this redefinition and these
clauses.
I hope this clears things up.
These clauses are probably unenforceable in many jurisdictions.
The license also states it doesn't apply to commercial or
institutional users of the software. Who knows what applies to these
people.
If all you wanted to do is prevent compilation CDs of IPFs,
prohibiting the IPF library from being redistributed should have been
enough. Such a prohibition is in the licenses. I don't see why such a
redefinition of derivative works, and restriction on what you can do
with these "derivative works", was ever necessary.
Again, who knows what's in the commercial and/or institutional license.
--Dave
Sent from my iPhone
On Mar 9, 2012, at 4:07 AM, "Christian Bartsch | KryoFlux Ltd."
<cb at kryoflux.com> wrote:
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.
Jonathan, I think you misunderstood what this is about. Before I go into detail here, it
does make sense to see how "the technology" is defined: "The program's
object code, source code and documentation are collectively referred to as the
"Technology"". Please note that there is no reference to the file format
itself.
It just clearly states one thing: You can not take a piece of our software and use it to
make another piece of software, except for the exclusions listed. It does not say you can
not invent something on our own or work with a CatFerret or DiskWeasel or whatever device
comes to mind. It is also correct that you could not take the capsimg.dll and put it into
a competing product. You can of course write your own code, or you could - if it's not
a commercial thing - just take a look at our source distribution. It comes with a
different (adapted MAME) licence!
Please take a look yourself:
http://www.kryoflux.com/download/ipfdec_source4.2.zip
This was released to make sure the format is a) fully documented, b) portable and c) data
is not buried.
The reasons for the tight restrictions of the original (old) licence were e.g. some
companies selling game compilation CDs of questionable origin, which usually did not give
credit or pay royalties to the legitimate copyright holders (=game devs). We did not want
to support such things. Not being able to use IPF for these (or extract the data with our
enabler) meant ADFs were used, which usually sported cracker intros or similar, making
people aware of what they had bought.
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, you are not (I think). Unless you take parts of our
product to enhance a competitive product, all is fine. In other (unpleasant) words: If you
make your own and don't steal, I don't see any problem there.
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.
Absolutely not. If they were using this very same licence (which they don't, as it
excludes commercial use) they could of course use other products. They just could not put
parts of our product into the other. 
10:52 a.m.
New subject: SPS licence (redefinition)
They have already reacted to use of their products in ways they didn't
like by changing the licensing. If they choose to they could do so in
the future.
What if one wanted to do something as simple as have a tool that
incorporates something derivative in the future to stream their
formattted images to a Discferret, or some future product they wish to
react to? Using the streams to either run an interpreter, or stream out
to media in the future would certainly be a valid use, and if they
didn't like it, they already have demonstrated they are willing to
change their licensing in reaction to it.
IANAL, but the Mame license is not going to give me comfort that if I
wanted to grab someones archive of images, throw together a suite of
tools that I would not have to visit a bunch of licensing verbiage, and
have some understanding of law to be sure noone sent me a cease and
desist order down the line.
People with archives of works from ancient companies already have enough
jackals chasing them of that sort, and don't need this.
As far as MS, the same sort of black cloud hangs over all works that use
something as simple as FAT. again IANAL, but any format that has so
much to interpret and do so correctly in licenses isn't a format one
would want to use to archive their works.
The fact that all this discussion is taking place makes this loosing
proposition.
They are free to make a product with any restrictions or licenses they
wish, but the first thing I'd write if I were to own a KF, would be to
take the archive format to something not related to that product for
archival. The point that David below brings up does make even that an
iffy proposition.
On 3/9/2012 5:38 AM, David Ryskalczyk wrote:
No, the problem is the redefinition of Derivative
Works to include any
images produced by the device using the KF binary software
distribution. Since the binary blob falls under this license, this
means all IPFs (and STREAM dumps too) that were dumped with the KF.
You could say that the license "taints" the IPFs or STREAM dumps.
Personal editions of software like MS Word has similar clauses
regarding commercially produced works, which means a court in the USA
would possibly uphold it. Even though it basically forces vendor
lock-in and makes it illegal to use any tool other than the
vendor-provided ones to convert the files.
So in the end, though the free implementation of IPF in itself is
legal, converting an IPF dumped with the proprietary distribution
(pretty much ANY IPF) is not, because of this redefinition and these
clauses.
I hope this clears things up.
These clauses are probably unenforceable in many jurisdictions.
The license also states it doesn't apply to commercial or
institutional users of the software. Who knows what applies to these
people.
If all you wanted to do is prevent compilation CDs of IPFs,
prohibiting the IPF library from being redistributed should have been
enough. Such a prohibition is in the licenses. I don't see why such a
redefinition of derivative works, and restriction on what you can do
with these "derivative works", was ever necessary.
Again, who knows what's in the commercial and/or institutional license.
--Dave
Sent from my iPhone
On Mar 9, 2012, at 4:07 AM, "Christian Bartsch | KryoFlux Ltd."
<cb at kryoflux.com> wrote:
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.
Jonathan, I think you misunderstood what this is about. Before I go into detail here, it
does make sense to see how "the technology" is defined: "The program's
object code, source code and documentation are collectively referred to as the
"Technology"". Please note that there is no reference to the file format
itself.
It just clearly states one thing: You can not take a piece of our software and use it to
make another piece of software, except for the exclusions listed. It does not say you can
not invent something on our own or work with a CatFerret or DiskWeasel or whatever device
comes to mind. It is also correct that you could not take the capsimg.dll and put it into
a competing product. You can of course write your own code, or you could - if it's not
a commercial thing - just take a look at our source distribution. It comes with a
different (adapted MAME) licence!
Please take a look yourself:
http://www.kryoflux.com/download/ipfdec_source4.2.zip
This was released to make sure the format is a) fully documented, b) portable and c) data
is not buried.
The reasons for the tight restrictions of the original (old) licence were e.g. some
companies selling game compilation CDs of questionable origin, which usually did not give
credit or pay royalties to the legitimate copyright holders (=game devs). We did not want
to support such things. Not being able to use IPF for these (or extract the data with our
enabler) meant ADFs were used, which usually sported cracker intros or similar, making
people aware of what they had bought.
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, you are not (I think). Unless you take parts of our
product to enhance a competitive product, all is fine. In other (unpleasant) words: If you
make your own and don't steal, I don't see any problem there.
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.
Absolutely not. If they were using this very same
licence (which they don't, as it excludes commercial use) they could of course use
other products. They just could not put parts of our product into the other. 
12:42 p.m.
Jonathan, I think you misunderstood what this is
about. Before I go into
detail here, it does make sense to see how "the technology" is defined:
"The program's object code, source code and documentation are
collectively referred to as the "Technology"". Please note that there is
no reference to the file format itself.
I am sure a lawyer could have a field day with this.
To me the description of the file format is part of the 'documetation' of
the product, and by your definiton it is tharefore part of the
'technology'.
In other words, I interrpet your license as meaning that I can't use the
documetnation, including the description of any file formats, to make a
competing product. In aprticualr I can't produce something that reads one
of your inmage files and writes it back to a physical disk.
-tony
4446
days inactive
4446
days old
3 comments
4 participants
participants (4)
-
ard＠p850ug1.demon.co.uk -
cb＠kryoflux.com -
d235j.1＠gmail.com -
jws＠jwsss.com