Re: [Flightgear-devel] GPLing datafiles

[John C. <j4s...@ro...>]

On Mon, 9 Jul 2001, Cameron Moore wrote:

> * j4s...@ro... [2001.07.09 11:39]:
> >
> >
> > On Mon, 9 Jul 2001, Cameron Moore wrote:
> >
> > > I saw a paragraph on a FlightSim.com page[1] tonight about Copyleft (ie.
> > > the GPL) that got me thinking.  The part that struck me was this:
> > >
> > >   "The [GPL] legal terms allow the file to be improved on,
> > >    but it can never be charged for."
> >
> > Thats pretty much a description of the freeware license. I think it's kind
> > of (freeware license that is) petty. Truthfully if a freeware license
> > was violated, there is nobody that will back it up in court. That is to
> > say, who would spend the money to defend it? Certainly not somebody who is
> > worried about somebody else getting rich off a flightsim add on.
> > IMO even though freeware is weak and not likely to be enforced, we need
> > to take the high road and respect the terms.
>
> I don't know where that came from, but I wasn't suggesting breaking any
> freeware licenses.

I know that. I should have stated what I was saying was OT. Really why it
came to mind was that the description of the GPL they had posted was
indicative of the mindset of add on developers in the MS world.


>
> > > Well, that last part is completely inaccurate.  I was going to email the
> > > webmaster about it until I started trying to figure how to explain it,
> >
> > Someone should contact them. It's really misleading. I wouldn't go into
> > great depth, just state that GPL'd bits *can* be charged for. The
> > most important restriction of the GPL is that reused code must be also
> > GPL'd.
>
> I contacted the webmaster.  It's been updated.  You still don't get the
> whole story, but at least the changes are correct.

Cool. To me it sounded like they did zero research on the GPL. FWL
doesn't prohibit making changes and redistributing, just collecting
money.

>
> > > especially as it relates to datafiles (which is what most of the files
> > > are on that site -- models, .AIR files, panels, etc).  The part that I
> > > got stuck on was how to apply the GPL to a datafile such as a .MDL file.
> > >
> > > The GPL says that you can redistribute binaries of a program and charge
> > > whatever you want for it, but you have to provide the source for free.
> > > That requirement gets confusing when you GPL a binary file that has no
> > > real "source code" (in the conventional meaning of the word).
> > >
> > > Well, the FSF has this to say about the matter:
> > >
> > >   ...the GNU GPL can be used for general data which is not software,
> > >   as long as one can determine what the definition of "source code"
> > >   refers to in the particular case.[2]
> > >
> > > So, if we just take the approach that the format in which a file is
> > > distributed in is that files "source code", then the GPL works
> > > beautifully.  Take the following scenario:
> > >
> > > Say we have a GPL'd file named "C172.MDL" in our base package.  The
> > > "source code" is that file.  Any derivative works must be GPL'd and be
> >
> > I don't know if that interpretation would never hold up. MDL files aren't
> > human readable. I don't know how they are prepared but there must be data
> > that gets processed and output in mdl format, even if it goes directly
> > from a builder app to a finished file... Hmm... maybe it would hold up
> > in that case. Unnecessarily obfuscatory if you ask me.
>
> Just because *I* can't open up a .MDL in a hex editor and read it
> doesn't mean someone else can't.  Whether it's ASCII or binary makes no
> difference -- it's still "code" that has meaning.  If you think I'm
> going over the edge, go read some of the 2600 vs MPAA court transcripts.
>

No, you are right.

> But, I do think I was a little off-base on my initial interpretation.
> As someone has already said, if the full functionality is there, I don't
> think the format matters.  Just like taking GPL'd C++ and rewritting it
> in Python.  The new python code must be GPL'd and made available as
> python code, not C++ code.
>

I don't know. That's debatable. In this case you'd be talking about
algorithms and structure. Since you'd be reimplementing it, it could
be argued that its not the same code. Kind of like the old bit
about buying the axe George Washington chopped down the cherry tree with.
"They had to replace the head... and the handle.... but it takes up the
same space!". It's kind of murky, so let's not debate it here.


> > > available for free as a .MDL file.  If someone wanted to sell C172.MDL
> > > on a CD, they could do so, but they must also provide it for free.  I
> > > suppose "binary code" would be any formats other that .MDL that were
> > > derived from the .MDL file, so a .AC file would be a "binary".  You
> > > could distribute that for money, but must provide the .MDL version of
> > > the .AC file for free.  Hmm...that could get hairy if you add features
> > > in the .AC file that can't be translated to the .MDL format.
> >
> > Actually, the AC files are plain text. MDL's (according to `file`) are
> > 32 bit windows DLL's. The current c172 model I'm using (which BTW is
> > derived from the most popular model people repaint) from Wolframs site
> > is in AC format. The answer seems pretty clear, use AC format (assuming
> > we can find one with a compatible license (not likely).
> > Really the whole problem I have had with trying to find a suitably
> > licensed model is that the geometry (so far) always has a freeware
> > license which forbids *ever* charging money. The problem is that
> > FGFS *does* get distributed on CD (in SuSE linux for one) for money.
> > Even if I made "free" and "nonfree" releases, we could never be sure
> > a third party packaged the right goods.
>
> That makes things much easier.  I didn't know that .AC files are ASCII.

Well in light of the above arguments, I'd say that for the technically
disinclined an ASCII format makes for a clearer picture.

TTYL
J

> --
> Cameron Moore
>
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> http://lists.sourceforge.net/lists/listinfo/flightgear-devel
>