discuss: OCLC Office of Research Open Source License

[Rod Dixon]

I understand your point concerning "object code," but I think OCLC is
attempting to use a meaning for "modifiable code" that closely approximates
the intent of the OSD; namely, that source code be viewed as a form of the
program where changes can be most efficiently
implemented...(i.e."modifiable") ...a fairly straightforward and readable
code, which is rarely the case for widely distributed object code. OCLC
removed the definition of source code from the prior version of the
license...perhaps it should be added back, if there is confusion on this?

I agree that it is unclear what is going on in Section 3.D. regarding what
is being allowed for aggregate works and not for combined works. Is a
"combined work" a derivative work? If so, can OCLC call it that to clear up
some of the confusion? The clause beginning "You are forbidden..." seems to
hurt clear expression more than help. Is it necessary?

- Rod

Rod Dixon
rod at cyberspaces.org
Cyberspaces: Words-Not-Deeds:
http://www.cyberspaces.org/webzine/




----- Original Message -----
From: "Forrest J. Cavalier III" <mibsoft at mibsoftware.com>
To: <license-discuss at opensource.org>
Cc: <mibsoft at mibsoftware.com>
Sent: Monday, September 30, 2002 12:29 PM
Subject: Re: discuss: OCLC Office of Research Open Source License


> This is how combined work is defined...
>
> > A "Combined Work" results from combining and integrating all or
> > parts of the Program with other code. A Combined Work may be
> > thought of as having multiple parents or being result of multiple
> > lines of code development.
> >
>
> Is this definition precise enough to exclude agregate works?
>
> As written, it seems that Agregate works are a subset of Combined
> works.  This indicates to me that Section D restrictions, because
> they would apply to CD complilations for example, are not OSD compliant.
>
> ------------
>
> As another note, I personally do not consider "object code"
> non-modifiable.  In fact, back in the day when assemblers were slow,
> simple flaws in code could be "hand-patched" by replacing the
> defective code with a jump instruction out to unused memory, and
> hand-assembling the code to perform the correct operation and jump
> back.
>
> This hand-patching would save about 25 minutes of time for each bug, with
> the added BIG advantage that the 180 page assembler output would
> remain usable (because subroutine addresses would remain the same.)
>
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3