1. Topics
  2. GPL Cooperation Commitment variations

GPL Cooperation Commitment variations

J Lovejoy
 

Hi all,

I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!

Attached is a compare of the project to corporate variant; and of the individual to project variant. The main difference seem to be:
- in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
- likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
- likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
- there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match


Interested to hear other thoughts. This will still need some expert markup attention!!


Jilayne

?
compare_GPL-CC-1.0_individual-project.docx
?
compare_GPL-CC-1.0_project-corporate.docx

Philippe Ombredanne
 

If this can help, we have tracked in ScanCode all the 15 known text
variations to date:
https://github.com/nexB/scancode-toolkit/search?p=1&q=%22this+Commitment+to+be+irrevocable%22&unscoped_q=%22this+Commitment+to+be+irrevocable%22
--
Philippe

On Thu, Nov 29, 2018 at 7:54 PM J Lovejoy <opensource@...> wrote:

Hi all,

I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!

Attached is a compare of the project to corporate variant; and of the individual to project variant. The main difference seem to be:
- in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
- likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
- likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
- there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match


Interested to hear other thoughts. This will still need some expert markup attention!!


Jilayne



--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
Richard Fontana
 

I've thought further about the issue of whether GPLCC, as a possible
future SPDX exception identifier, should cover the three GPLCC
variants (Corporate, Indivdiual and Project), as seemed to be the
consensus on the recent call, or whether instead it should just refer
to the Project version (which was my original proposal).

There's an argument that someone might want to use a convenient SPDX
identifier to reference the non-Project variants when annotating some
source code wholly or partially covered by one of those
commitments. (This is related to some of the arguments Bradley has
been making in connection with the Kernel Enforcement Statement, I
think.) I suspect this will be unlikely, but who knows?

My concern though is the effort to use markup to generalize the
textual differences among the three variants might have the
problematic effect (from Red Hat's perspective) that some unknown set
of additional variants, unauthorized by the GPLCC initiative, could
match to the GPLCC SPDX identifier. To put it simply, I see value in
an SPDX identifier for GPLCC if the identifier can be mapped to from
the three official GPLCC variants, but I see no value in the
possibility of anything else matching GPLCC. I am not clear on whether
the markup can be crafted so precisely that it could only match the
three documents in question. I think the problem I am highlighting
would be tolerable if we (Red Hat) actually cared about having an
identifier for the Corporate and Individual variants, but we really
don't. If SPDX adopts an identifier solely for the Project variant,
let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
for all three variants on https://gplcc.github.io/gplcc and other
informational and promotional materials.

Richard

On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
Hi all,

I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!

Attached is a compare of the project to corporate variant; and of the individual to project variant. The main difference seem to be:
- in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
- likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
- likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
- there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match


Interested to hear other thoughts. This will still need some expert markup attention!!


Jilayne
Alexios Zavras
 

Hi Richard,

Let me try to answer, since I was the one who did the "unifying" markup.
Our goal is obviously to match the three GPLCC variants and (ideally) not match anything else. Unfortunately, the latter part is not 100% achievable, but I feel the stuff we allow on top of the original variants is negligible and too low risk.

For example:

- in only one of the three variants there is a colon after the "Definition" header (i.e., two of them have "Definitions" and one has "Definitions:"). I have marked the colon as optional, so any variant may or may not include it.

- in only one of the three variants there is a notice about the licensing (under CC-BY-SA-4.0) of the text. Again, this is marked as optional in any case.

- a more typical example (found in 3-4 places in the text) are the variants of "I commit" (Individual), "we commit" (Project), or "COMPANY commits" (Corporate). By the simplistic word-by-word current matching, we also allow the grammatically incorrect "I commits", for example. If this is considered to be an issue, I can change the match to consider the whole phrase.

- however, in general, there is no way to eliminate the possibility of matching different variants in different parts of the text. I mean, it will eventually match a "Frankenstein-Commitment" which starts "we commit" (from Project), but on the next paragraph talks about "my copyright" (from Individual, instead of "our copyright"). Or has, at the end, a phrase like "XXX means XXX and its subsidiaries." (from Corporate).

I personally consider this to be low-risk, but it's definitely a case of, as you write, "some unknown set of additional variants, unauthorized by the GPLCC initiative, could match to the GPLCC SPDX identifier".
Given what I described, do you think it's acceptable to have this variant matching?

-- zvr -

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Richard Fontana
Sent: Saturday, 8 December, 2018 07:52
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: GPL Cooperation Commitment variations

I've thought further about the issue of whether GPLCC, as a possible future SPDX exception identifier, should cover the three GPLCC variants (Corporate, Indivdiual and Project), as seemed to be the consensus on the recent call, or whether instead it should just refer to the Project version (which was my original proposal).

There's an argument that someone might want to use a convenient SPDX identifier to reference the non-Project variants when annotating some source code wholly or partially covered by one of those commitments. (This is related to some of the arguments Bradley has been making in connection with the Kernel Enforcement Statement, I
think.) I suspect this will be unlikely, but who knows?

My concern though is the effort to use markup to generalize the textual differences among the three variants might have the problematic effect (from Red Hat's perspective) that some unknown set of additional variants, unauthorized by the GPLCC initiative, could match to the GPLCC SPDX identifier. To put it simply, I see value in an SPDX identifier for GPLCC if the identifier can be mapped to from the three official GPLCC variants, but I see no value in the possibility of anything else matching GPLCC. I am not clear on whether the markup can be crafted so precisely that it could only match the three documents in question. I think the problem I am highlighting would be tolerable if we (Red Hat) actually cared about having an identifier for the Corporate and Individual variants, but we really don't. If SPDX adopts an identifier solely for the Project variant, let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation for all three variants on https://gplcc.github.io/gplcc and other informational and promotional materials.

Richard






On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
Hi all,

I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!

Attached is a compare of the project to corporate variant; and of the individual to project variant. The main difference seem to be:
- in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
- likewise, the associated definition of We or the corporation name,
or the absence of a definition for individual at the end
- likewise, lead-in text for the individual version clarifying it only
applies to their sole copyright
- there is also an additional term that the corporate variant has
about the ability to modify the commitment by posting a new edition -
this is not included at all in the project or individual variants. I
think this could be omitable in some way? if a cooperation did make a
modified version, then it would not match


Interested to hear other thoughts. This will still need some expert markup attention!!


Jilayne








Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
Grant Likely
 

Hi folks,

I'm a little late to this discussion, but I think I should weigh in. To
me this discussion is very odd, at least from the context of the Kernel
Enforcement Statement. I don't think it makes any sense to encode the
KES in an SPDX tag, and I am leaning in the same direction on the GPLCC.
In fact, I think it is actively harmful to do this.

When I proposed and drafted first version of the KES, the intent was to
provide a body of work that effectively says "We think the GPL means
/this/". It was right in the middle of when many of us knew of the
McHardy lawsuits that presented unorthodox interpretations of the GPL,
but none of us could talk about it in public. There was (perhaps oddly)
little in the way of material that any of us could point at to argue
that we generally agree on what the GPL means, and more importantly,
that the interpretations and enforcement activity being presented in
court are outside the widely accepted interpretation.

The KES is a document that can be shown to companies and individuals
that can give them confidence that a GPL licensed project is safe and
well understood. Hopefully it is a document that will be considered by a
court when challenging an infringement action that does not line up with
the interpretation agreed by a large body of the community.

(Insert here comment about I am not a lawyer, followed by dodgy legal
advice -- I approached this problem from the point of view of a
community member, and I have to believe that when a large group of the
community share a common understanding then surely that understanding
carries some weight. Those of you with law degrees can comment on how
naïve I'm being)

The KES was not intended to change the interpretation of the GPL. The
GPLv2 is exactly the same license as it always was. What the KES does,
or attempts to do, is claim that what the GPL /means/ is well
understood, and that it has always meant that. The last bit is really
important. McHardy, or anybody else, doesn't get to claim that the GPL
on their code is interpreted differently than the GPL on the code I've
contributed.

I think putting the KES or GPLCC into a SPDX tag undermines that exact
arguement. By encoding them into SPDX tags, it seems to argue that there
are two different classes of GPL. Vanilla GPL, and Super Special Blessed
GPL when the project has adopted the KES or GPLCC. This is actively
harmful to solving the problem the KES and GPLCC are trying to solve.

Without a really strong use case for how KES and GPLCC tags would be
used, I strongly oppose both of them.

I'll leave aside the arguements about logistics of adding a new tag to
the kernel flags, or about not every contributor to the kernel has
signed the KES. James and Jilayne have argued those well and I don't
need to rehash those arguments.

Cheers,
g.

On 08/12/2018 06:51, Richard Fontana wrote:
I've thought further about the issue of whether GPLCC, as a possible
future SPDX exception identifier, should cover the three GPLCC
variants (Corporate, Indivdiual and Project), as seemed to be the
consensus on the recent call, or whether instead it should just refer
to the Project version (which was my original proposal).

There's an argument that someone might want to use a convenient SPDX
identifier to reference the non-Project variants when annotating some
source code wholly or partially covered by one of those
commitments. (This is related to some of the arguments Bradley has
been making in connection with the Kernel Enforcement Statement, I
think.) I suspect this will be unlikely, but who knows?

My concern though is the effort to use markup to generalize the
textual differences among the three variants might have the
problematic effect (from Red Hat's perspective) that some unknown set
of additional variants, unauthorized by the GPLCC initiative, could
match to the GPLCC SPDX identifier. To put it simply, I see value in
an SPDX identifier for GPLCC if the identifier can be mapped to from
the three official GPLCC variants, but I see no value in the
possibility of anything else matching GPLCC. I am not clear on whether
the markup can be crafted so precisely that it could only match the
three documents in question. I think the problem I am highlighting
would be tolerable if we (Red Hat) actually cared about having an
identifier for the Corporate and Individual variants, but we really
don't. If SPDX adopts an identifier solely for the Project variant,
let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
for all three variants on https://gplcc.github.io/gplcc and other
informational and promotional materials.

Richard






On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
Hi all,

I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!

Attached is a compare of the project to corporate variant; and of the individual to project variant. The main difference seem to be:
- in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
- likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
- likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
- there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match


Interested to hear other thoughts. This will still need some expert markup attention!!


Jilayne
J Lovejoy
 

Richard,

You stated:
If SPDX adopts an identifier solely for the Project variant,
let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
for all three variants on https://gplcc.github.io/gplcc and other
informational and promotional materials.
But, is Red Hat intending on using the SPDX identifier in source files of Red Hat projects that have adopted the project variant or SPDX documents?


Jilayne



On Dec 7, 2018, at 11:51 PM, Richard Fontana <rfontana@...> wrote:

I've thought further about the issue of whether GPLCC, as a possible
future SPDX exception identifier, should cover the three GPLCC
variants (Corporate, Indivdiual and Project), as seemed to be the
consensus on the recent call, or whether instead it should just refer
to the Project version (which was my original proposal).

There's an argument that someone might want to use a convenient SPDX
identifier to reference the non-Project variants when annotating some
source code wholly or partially covered by one of those
commitments. (This is related to some of the arguments Bradley has
been making in connection with the Kernel Enforcement Statement, I
think.) I suspect this will be unlikely, but who knows?

My concern though is the effort to use markup to generalize the
textual differences among the three variants might have the
problematic effect (from Red Hat's perspective) that some unknown set
of additional variants, unauthorized by the GPLCC initiative, could
match to the GPLCC SPDX identifier. To put it simply, I see value in
an SPDX identifier for GPLCC if the identifier can be mapped to from
the three official GPLCC variants, but I see no value in the
possibility of anything else matching GPLCC. I am not clear on whether
the markup can be crafted so precisely that it could only match the
three documents in question. I think the problem I am highlighting
would be tolerable if we (Red Hat) actually cared about having an
identifier for the Corporate and Individual variants, but we really
don't. If SPDX adopts an identifier solely for the Project variant,
let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
for all three variants on https://gplcc.github.io/gplcc and other
informational and promotional materials.

Richard






On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
Hi all,

I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!

Attached is a compare of the project to corporate variant; and of the individual to project variant. The main difference seem to be:
- in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
- likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
- likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
- there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match


Interested to hear other thoughts. This will still need some expert markup attention!!


Jilayne
Richard Fontana
 

We're not specifically planning to use the hypothetical SPDX identifier in source files -- basically we just haven't considered the issue. Currently, I know of one or two Red Hat-maintained projects that are using SPDX identifiers in source files, but we haven't reached the point of generally recommending this; for one of those two projects the desire to use SPDX identifiers came from the developers. 

I think there is a decent chance we will begin recommending use of "SPDX-License-Identifier:" (or, at the very least, SPDX identifiers in source files) at some point in the foreseeable future. On my team we've certainly had a number of discussions about it. I am definitely personally moving towards seeing it as a good idea. However as you can imagine that would be a big step for us :-) If that were to happen, we would certainly want to use the hypothetical future SPDX identifier for GPLCC in source files of those projects adopting GPLCC.

As for using the hypothetical GPLCC identifier in SPDX documents, we currently have no foreseeable plans to generate or make use of SPDX documents, but that too is a topic we continue to explore.

Richard



From: "J Lovejoy" <opensource@...>
To: "Richard Fontana" <rfontana@...>
Cc: "SPDX-legal" <spdx-legal@...>
Sent: Wednesday, December 12, 2018 5:32:34 PM
Subject: Re: GPL Cooperation Commitment variations

Richard,

You stated:
>  If SPDX adopts an identifier solely for the Project variant,
> let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
> for all three variants on https://gplcc.github.io/gplcc and other
> informational and promotional materials.

But, is Red Hat intending on using the SPDX identifier in source files of Red Hat projects that have adopted the project variant or SPDX documents?  


Jilayne



> On Dec 7, 2018, at 11:51 PM, Richard Fontana <rfontana@...> wrote:
>
> I've thought further about the issue of whether GPLCC, as a possible
> future SPDX exception identifier, should cover the three GPLCC
> variants (Corporate, Indivdiual and Project), as seemed to be the
> consensus on the recent call, or whether instead it should just refer
> to the Project version (which was my original proposal).
>
> There's an argument that someone might want to use a convenient SPDX
> identifier to reference the non-Project variants when annotating some
> source code wholly or partially covered by one of those
> commitments. (This is related to some of the arguments Bradley has
> been making in connection with the Kernel Enforcement Statement, I
> think.) I suspect this will be unlikely, but who knows?
>
> My concern though is the effort to use markup to generalize the
> textual differences among the three variants might have the
> problematic effect (from Red Hat's perspective) that some unknown set
> of additional variants, unauthorized by the GPLCC initiative, could
> match to the GPLCC SPDX identifier. To put it simply, I see value in
> an SPDX identifier for GPLCC if the identifier can be mapped to from
> the three official GPLCC variants, but I see no value in the
> possibility of anything else matching GPLCC. I am not clear on whether
> the markup can be crafted so precisely that it could only match the
> three documents in question. I think the problem I am highlighting
> would be tolerable if we (Red Hat) actually cared about having an
> identifier for the Corporate and Individual variants, but we really
> don't. If SPDX adopts an identifier solely for the Project variant,
> let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
> for all three variants on https://gplcc.github.io/gplcc and other
> informational and promotional materials.
>
> Richard
>
>
>
>
>
>
> On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
>> Hi all,
>>
>> I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!
>>
>> Attached is a compare of the project to corporate variant; and of the individual to project variant.  The main difference seem to be:
>> - in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
>> - likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
>> - likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
>> - there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match
>>
>>
>> Interested to hear other thoughts.  This will still need some expert markup attention!!
>>
>>
>> Jilayne
>>
>>
>>
>>
>
>
>
>
>
>


Richard Fontana
 

I guess I will further say that if the SPDX group would like to informally condition adoption of GPLCC-1.0 (or whatever) as an exception identifier on some assurance that Red Hat will actually use it in one of the ways contemplated by SPDX (on the thinking that SPDX identifiers are not worth adopting unless they are actually used), we could use that as an opportunity to try to get at least those Red Hat-maintained projects adopting GPLCC to use SPDX-License-Identifier in source files. :-)  

Richard

From: "Richard Fontana" <rfontana@...>
To: "J Lovejoy" <opensource@...>
Cc: "SPDX-legal" <spdx-legal@...>
Sent: Wednesday, December 12, 2018 5:49:16 PM
Subject: Re: GPL Cooperation Commitment variations

We're not specifically planning to use the hypothetical SPDX identifier in source files -- basically we just haven't considered the issue. Currently, I know of one or two Red Hat-maintained projects that are using SPDX identifiers in source files, but we haven't reached the point of generally recommending this; for one of those two projects the desire to use SPDX identifiers came from the developers. 

I think there is a decent chance we will begin recommending use of "SPDX-License-Identifier:" (or, at the very least, SPDX identifiers in source files) at some point in the foreseeable future. On my team we've certainly had a number of discussions about it. I am definitely personally moving towards seeing it as a good idea. However as you can imagine that would be a big step for us :-) If that were to happen, we would certainly want to use the hypothetical future SPDX identifier for GPLCC in source files of those projects adopting GPLCC.

As for using the hypothetical GPLCC identifier in SPDX documents, we currently have no foreseeable plans to generate or make use of SPDX documents, but that too is a topic we continue to explore.

Richard



From: "J Lovejoy" <opensource@...>
To: "Richard Fontana" <rfontana@...>
Cc: "SPDX-legal" <spdx-legal@...>
Sent: Wednesday, December 12, 2018 5:32:34 PM
Subject: Re: GPL Cooperation Commitment variations

Richard,

You stated:
>  If SPDX adopts an identifier solely for the Project variant,
> let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
> for all three variants on https://gplcc.github.io/gplcc and other
> informational and promotional materials.

But, is Red Hat intending on using the SPDX identifier in source files of Red Hat projects that have adopted the project variant or SPDX documents?  


Jilayne



> On Dec 7, 2018, at 11:51 PM, Richard Fontana <rfontana@...> wrote:
>
> I've thought further about the issue of whether GPLCC, as a possible
> future SPDX exception identifier, should cover the three GPLCC
> variants (Corporate, Indivdiual and Project), as seemed to be the
> consensus on the recent call, or whether instead it should just refer
> to the Project version (which was my original proposal).
>
> There's an argument that someone might want to use a convenient SPDX
> identifier to reference the non-Project variants when annotating some
> source code wholly or partially covered by one of those
> commitments. (This is related to some of the arguments Bradley has
> been making in connection with the Kernel Enforcement Statement, I
> think.) I suspect this will be unlikely, but who knows?
>
> My concern though is the effort to use markup to generalize the
> textual differences among the three variants might have the
> problematic effect (from Red Hat's perspective) that some unknown set
> of additional variants, unauthorized by the GPLCC initiative, could
> match to the GPLCC SPDX identifier. To put it simply, I see value in
> an SPDX identifier for GPLCC if the identifier can be mapped to from
> the three official GPLCC variants, but I see no value in the
> possibility of anything else matching GPLCC. I am not clear on whether
> the markup can be crafted so precisely that it could only match the
> three documents in question. I think the problem I am highlighting
> would be tolerable if we (Red Hat) actually cared about having an
> identifier for the Corporate and Individual variants, but we really
> don't. If SPDX adopts an identifier solely for the Project variant,
> let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
> for all three variants on https://gplcc.github.io/gplcc and other
> informational and promotional materials.
>
> Richard
>
>
>
>
>
>
> On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
>> Hi all,
>>
>> I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself!
>>
>> Attached is a compare of the project to corporate variant; and of the individual to project variant.  The main difference seem to be:
>> - in the use of pronouns (I, We, name of coroporation) - easily accommodated with markup.
>> - likewise, the associated definition of We or the corporation name, or the absence of a definition for individual at the end
>> - likewise, lead-in text for the individual version clarifying it only applies to their sole copyright
>> - there is also an additional term that the corporate variant has about the ability to modify the commitment by posting a new edition - this is not included at all in the project or individual variants. I think this could be omitable in some way? if a cooperation did make a modified version, then it would not match
>>
>>
>> Interested to hear other thoughts.  This will still need some expert markup attention!!
>>
>>
>> Jilayne
>>
>>
>>
>>
>
>
>
>
>
>



1 - 8 of 8