<<I would have to recheck the license to be certain, but AFAIK it
said that OGC content be clearly indicated whereever it is used.
>>
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.
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.
<<
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.
<<
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.
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.
<<
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.
<<
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.
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.
Lee
