Ok to further this, assume that in the software code, every single line that
was OGC had a comment around along the following lines.
/* BEGIN OGC */
/* END OGC */
Now I assume that is 100% clearly identifying the OGC. So if I distribute
the source all is well and good. Now the problem is if i distribute a
precompiled binary then this would not be identifying the ogc. But what if i
didnt distribute the binary and just the source. Would this be acceptable?
How would this effect the person who then compiled the source code to use?
Since it once again would then not ID OGC, however they will not be
distributing that so is there a problem?
What if they compiled it and then distributed the binrary? or placed the
binary on a server where people could run it (eg imagine the binary is a
multiplayer game server), where would this stand?
Just thought software is a tricky one since the source could abide by the
OGL but when you translate this to another format, it no longer does. Would
this mean you'd have to change the source so that the translated version eg
binary, so that it identifies the OGC?
bb.
----- Original Message -----
From: "Michael Hahn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 11:34 PM
Subject: Re: [Ogf-l] Software Issues
>
> ----- Original Message -----
> From: "Ryan S. Dancey" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 05, 2001 1:56 PM
> Subject: Re: [Ogf-l] Software Issues
>
>
> > From: "Michael Hahn" <[EMAIL PROTECTED]>
> >
> > > A roguelike game is created, using resources from the SRD. This is
> > > programmed in Java. If I were to state in the license information
> that
> > > "Class files X, Y, and Z contain all OGC in this program. The
> interface
> > > to these class files is published in files A, B and C." would this
> be
> > > acceptable as "clearly indicated?"
> >
> > My opinion is "no". The actual files themselves that contain the OGC
> need
> > to somehow self-identify the content that they contain that is OGC.
> In my
> > opinion, it's not going to be acceptable to put the definition of OGC
> in a
> > separate or easily separable work.
>
> OK. I understand this a bit better now, and can phrase my statement a
> bit more exactly. "The class files X, Y, and Z are OGC, and thier
> interfaces are described in files A, B, and C, which are also OGC." You
> see, java programs come as a group of class files, each of which
> contains one java Class. They can be bundled as a .jar file, but the
> .jar file is the same a zip file - it's a simple archive, and anyone
> with the correct software can seperate X, Y, and Z very painlessly.
>
> > The second problem you have is the derivative works issue, which I've
> been
> > avoiding to try and keep the issue focused on how the OGL applies to
> > sourcecode. The derivative works problem is pretty simple: The Open
> > Source/Free Software community believes that if you use so much as one
> line
> > of code from a copyleft license, your work, in the whole, becomes
> derivative
> > of that previous work and must comply with the copyleft.
>
> Ah, but here, the beuty of java comes to our resure. Each and every
> class file is generated by a completely seperate java source file.
> Therefore, if class files X.class, Y.class, and Z.class are OGC, then
> there is no reason not to make the entirety of X.java, Y.java and Z.java
> OGC as well, thus clearly identing where in the source code the OGC is
> as well.
>
> Michael Hahn
> http://users.csionline.net/~silver
> "Life is what happens in between plans."
>
> _______________________________________________
> Ogf-l mailing list
> [EMAIL PROTECTED]
> http://www.opengamingfoundation.org/mailman/listinfo/ogf-l
>
_______________________________________________
Ogf-l mailing list
[EMAIL PROTECTED]
http://www.opengamingfoundation.org/mailman/listinfo/ogf-l
