----- Original Message -----
From: <[EMAIL PROTECTED]>
>
> I don't remember that.  I thought it just demanded that OGC be
"clearly
> indicated"  If it required actual "in line" references then 90%+ of
all
> vendors would be in non-compliance for print products, since most
people use
> a single OGC declaration for all their OGC in a single commercial
product.
>

It doesn't require in line references, but you must be able to have a
means
of identifying what is OGC where it is displayed, which is why most
print products do something like "everything in bold", or
"everything in a shaded box" etc. ...

At least that is why I have understood from the various discussions
here about section 8.
8. Identification: If you distribute Open Game Content You must
clearly
indicate which portions of the work that you are distributing are
Open Game Content.


> Moreover, except for public performance exceptions, most copyright
violations
> occur through fixed form reproduction of copyrighted content.
Merely display
> of data would not be sufficient to assume that some new derivative
work was
> being created simply because it was being displayed in temporary
form.  So,
> I'd imagine that as long as the database file itself had a good OGC
> declaration, and as long as your front end is pretty generic and
doesn't have
> any OGC derivative code embedded in it, then your front end might
night be
> OGC, and you wouldn't need the front end to necessarily flag the
data it was
> displaying as OGC/non-OGC.  The license for creation of OGC
derivative
> copyrighted materials would apply primarily to the fixed form copy
of the
> data, and that would be the database file itself.
>

But the front end becomes part of the overall product the moment OGC
content is distributed along with it. (AFAIK). Which means the front
end must then adhere to the OGL. Which states you must clearly
identify any OGC used.

Which by displaying any of the OGC from the text file, I would take
that to be a use of OGC.

If however the database is distributed compleatly independantly
to the text file then there would be AFAIK no problem.

> <<
> > If I declared a text file to be 100% OGC, and then had a front
> > end which displayed that text file along with other data, I would
> > AFAIK have to identify in some way the OGC been displayed.
> > >>
>
> Why?  Displays can, in some instances, violate public performance
provisions
> of copyright law, simply displaying data is not, per se, creating a
new
> derivative work in fixed form.  The user doesn't need to have every
instance
> of every displayed piece of OGC data declared as OGC on the fly.
The fixed
> form OGC needs to be declared as such, but, provided the software
developer's
> intention was not in public performance, I don't think that one
could claim
> any substantive copyright violation.  The fixed form data would be
licensed,
> and the dynamically displayed data would not per se be fixed form
data.
>

I didn't think it was a case of creating derivitive work, I thought it
was
a case of if you are using and displaying OGC work then you must
abide by the OGL?

>
> <<> My reasons for saying I would need to id it in the front end, is
> > that in theory the text file is like the appendix idea which was
> > previously discussed and dismissed.
> > >>
>
> Actually, if you read some of the posts on that, the appendix
suggested was
> really inexact.  I think it _is_ possible to do a digital appendix
where it
> is 100% clear, word-for-word, position for position, what is and is
not OGC.
> That was _not_ the type of appendix that was discussed.  The
appendix
> discussed was, I thought, merely the extraction of all OGC from the
parent
> document, without sufficient information for the reader to make a
1:1
> correlation between data in the appendix and where it appeared in
the main
> document.
>

That may be the case, I've not yet read all the emails on this list.

> In any case, the appendix discussion didn't really address data that
is being
> temporarily displayed rather than data that had been rendered in
fixed form.
>

But if the main way the user will view the data is through the front
end, how could that be considered temporary? In theory the
user has no need to open the database in order to use the program,
and would thus need some way to identify the ogc displayed.

I can think of cases where this wouldn't be the case, and maybe thats
why we are disagreeing, we're both thinking of slightly different
software packages that use the db??

>
> <<> I could be wrong and usually are :P but I was under the
> > impression that OGC had to be clearly distinguished
> > where ever it be used.
> > >>
>
> Again, I don't remember the OGL being so precise as to demand "in
line"
> declarations.  One OGC declaration for the entire distributed
commercial unit
> should suffice.
>

Thats correct in that you don't have to declare it as OGC inline, but
there must be a way to identify it as such.

>
> <<> so in the case above you would say "text file abc.txt is
> > 100% OGC. Also any text that is displayed by the
> > program in a shaded box is OGC."
> > >>
>
> I may be wrong.  Maybe I need to go check the case law in this area,
since
> I'm not an IP lawyer, but I thought that, public performance
restrictions
> aside, display of data in a fleeting medium as opposed to a fixed
medium
> doesn't, per se, constitute creation of a derivative work that might
violate
> somebody's copyrights.
>

I've got no idea, but I do know that by using OGC you effectivley give
up all your rights under normal copyright law if you use the OGC under
the OGL.

But I could be way off mark with that...

> Since IANAL, I too could well be wrong.  I haven't read some of the
fixed
> form cases in a while.  I think the ones I remember involved video
games.
>

I think we'll wait to see what others on the list make of these last
few
emails. Hopefully they can help us sought out which is, I would say
right and wrong, but then in law I guess their is no right and wrong
its
more grey and not so grey :P

I hope your right though, because that would make things easier for
software projects :) :)

Gary.



_______________________________________________
Ogf-l mailing list
[EMAIL PROTECTED]
http://mail.opengamingfoundation.org/mailman/listinfo/ogf-l

Reply via email to