[OpenAFS] is YFS a "derived work"?

Jeffrey Altman jaltman@your-file-system.com
Tue, 02 Oct 2012 12:18:16 -0400


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCC6FAEEBF67E1C1462C9D075
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ted:

Before making accusations are that clearly wrong.  Please go speak with
an attorney.

I am intrigued by how you can consider Network Identity Manager a
derived work of OpenAFS.  It doesn't have a single line of code that
references AFS in it.  Nor is NIM even distributed with OpenAFS (not
that being distributed with OpenAFS places it under the IPL1.0).

The IPL1.0 only governs software modules[1] that are derived from
software modules in OpenAFS that are licensed under the IPL1.0.  It
doesn't govern software modules that are original development nor does
it govern software that is derived from external sources.  As an
example, aklog is shipped as part of OpenAFS but is not an IPL1.0
module; it is MIT licensed.  The OpenAFS plug-in for NIM is shipped with
OpenAFS but is licensed under the MIT license and contains components
that are copyright Secure Endpoints and MIT.

Unlike the Gnu Public License variants, the IPL1.0 is not viral.  It
does not infect other components.  The license was explicitly written by
IBM to permit IBM to continue selling IBM AFS and import contributions
that were made to OpenAFS by third parties.

Your File System Inc. adheres to the requirements of the IPL1.0 where it
is applicable.  It has pushed vast quantities of code changes upstream
which fall under the IPL1.0 and we will continue to do so.  Source code
modules that are owned outright by YFSI do not need to be pushed
upstream nor do they need to be distributed to customers.

What amazes me most about your statements is that you are so
willing to bite the hand that has fed you for the last twelve years.
Assuming that you obtain the YFSI owned code developed so far, kill off
any chance of YFSI investors recouping their expenses, and encourage me
and the rest of the team to walk away from OpenAFS forever,

  who is going to support the code for you?

  who is going to write the rest of it?

Its not like there are many options to find millions of dollars of
additional investment and the technical expertise necessary to perform
the work.  I sure haven't be able to capture a Leprechaun and his kettle
of gold nor have I discovered a cloning machine.  Perhaps that is
because you already have.

In the end if lawsuits begin to be filed everyone is going to lose.
Especially the end users that will be forced to spend vast sums to
migrate their data to lesser solutions.

A side note, when Peter Scott and I created the AFS Redirector for
Windows we intentionally selected the BSD license to publish the work.
We wanted the source code to be free to be used by others to learn from
and derive new products.  There are no other open source kernel file
system for Windows for people to learn from other than the samples
Microsoft provides in the Windows driver kits.  Pete and I are both
proud of the fact that the afsredir.sys file system framework driver was
adopted by Maginatics for their MagFS Enterprise Cloud file system.
http://maginatics.com/

Jeffrey Altman

[1] The IPL1.0 does not provide a definition for a "module".  However,
on 1 November 2000 when OpenAFS was formed the very first this that was
done was to apply the IPL1.0 on a source file by file basis.  The
reasoning was that the license applied on a file by file basis.
Subsequent contributions of new functionality were imported into the
OpenAFS source tree on that basis.


On 10/2/2012 9:12 AM, Ted Creedon wrote:
> http://opensource.org/licenses/ipl-1.0
>=20
> IBM PL 1.0 states:
>=20
> /Contributions do not include additions to the Program which: (i) are
> separate modules of software distributed in conjunction with the Progra=
m
> under their own license agreement, and (ii) are not derivative works of=

> the Program. /
>=20
> All software I've received in conjunction with the Program are
> derivative works, including the NIM and Windows Client.
>=20
> YFS needs to demonstrate that it is an Original Work and doesn't look t=
o
> me like it is.
>=20
> Its one more Contribution.
>=20
> What is the opinion of the Elders?
>=20
> Ted
>=20
> On Mon, Oct 1, 2012 at 9:53 PM, Troy Benjegerdes <hozer@hozed.org
> <mailto:hozer@hozed.org>> wrote:
>=20
>     Let's look at this another way...
>=20
>     If someone actually bothers to file an IP lawsuit of any sort
>     regarding AFS,
>     then I think this would be the most credible sign of success I coul=
d
>     possibly
>     imagine.
>=20
>     And then, in that case, if there were an issue, there would be
>     sufficient
>     community resources to re-write offending code, or re-purpose/exten=
d
>     things
>     like Arla, or the linux kernel kafs client.
>=20
>     What would be the downside of someone 'forcing' YFS back into the o=
pen
>     source domain? By that time, there should be plenty of customers wa=
nting
>     support contracts that it won't matter.
>=20
>     On Mon, Oct 01, 2012 at 10:21:54AM -0700, Ted Creedon wrote:
>     > The IP (intellectual property) in YFS seems to be derived from
>     AFS's IP.
>     >
>     > If that case can be made, IBM or any other entity could force YFS=

>     back into
>     > the open source domain.
>     >
>     > The "look and feel" of YFS may also be a problem - see "Broderbun=
d" or
>     > better yet their attorney's web page.
>     >
>     > http://www.quinnemanuel.com/attorneys/stern-claude-m.aspx
>     >
>     > My direct experience is from a dispute Tektronix had with
>     ParcPlace over
>     > Smalltalk licensing back in the '80's.
>     >
>     > AFS may be able to claim infringement against other file systems
>     because of
>     > its prior art (but its unpatented?).
>     >
>     > Which brings up a point, has IBM or CMU protected AFS's IP in any=
 way?
>     >
>     > Tedc
>=20
>=20


--------------enigCC6FAEEBF67E1C1462C9D075
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQaxPNAAoJENxm1CNJffh4LewIAM3sZyCqnSYsF+QaSHi81PbS
gS62eQ08JBUq4Q76pVojWpAICv2jhFj0t9tTXr4JeO7bX3wo8zkn8VCA9037G2q/
6a3RXdtP+i2Qy1nvOssE5bobwVbCJv5jZCK2/lxI4f/6PG/mee5S1QOmznrXd+iC
nK5DTL6gH838VSOXIEoJY07O3E+IPGYlMSf28zXaLE4wCje2A2JQk3aNezRMobME
dsmZOdg1vLcTRUGmN0dm34XAciIIdD2aKNzE+jMkbMEpd7ewxHwISUf1PpgoK+yX
K8FznZYp0a8AFhW8pL2G+VkwBwE3ykyuIp2SfIAsQlHcDM+EQ8JQJbL0leYynXQ=
=ihfw
-----END PGP SIGNATURE-----

--------------enigCC6FAEEBF67E1C1462C9D075--