Re: Licensing Issues

[Gregory John Casamento]

Hi Britt,

I'm Gorm's current maintainer.  I'll try to answer your questions as best as I
can.

See below...

--- britt creamer <creambj@yahoo.com.au> wrote:

> 
> First, GNUstep is a fantastic product!  GORM is awesome!  Thanks! 
> 
> However, from the commercial world, there are two issues that I would like
> resolved. 
>   
> First Issue- GNUstep core (or base with back and gui- the basic libraries). 
> I've had many discussions with my Intellectual Property Counsel in which our
> counsel feels "freeware" as "viral", and "it can be a mix bag of goods". 
> This is because of the mixing of free source code with proprietary software
> creates risk: the threat of license violations.  After checking GNUstep
> software (using a grep command searching for Copyright), I found four files
> that represents my legal counsels concerns:
> 
> base/Source/NSNotificationQueue.m         has Copyright 1995, 1996 Ovidiu
> Predescu and Mircea Oancea 
> gui/Images/GNUstep_Images_Copyright    has Copyright 1997 Andrew Lindesay 
> gui/Source/NSBezierPath.m                     has Copyright 1998 Raph Levien 
> gui/Source/tiff.m                                      has 2 Copyrights of
> concern: 1991, 1992, 1993, 1994 Sam Leffler 
>                                                                              
>                            1991, 1992, 1993, 1994 Silicon Graphics, Inc.
> 
> Now my search was not extensive by any means, and I hope to run Black Ducks
> protexIP software on this (one day) for a better reading. The concern of my
> counsel is that even though the most recent Copyrights of the software state
> "Free Software Foundation" (FSF), any other Copyrights in the source code
> entitles ownership to another entity along with FSF.  Thus, they have rights
> and ability to create a lawsuit if (whoever's name is in the code) is
> desiring/seeking compensation for a commercial product using GNUstep.
> 
> Question for First Issue: 
> Is it possible to have all non FSF Copyright names removed from all GNUstep
> code for this concern?

The people who wrote those classes can still put their names on them as the
author.  The FSF should already have the copyright for these files.   It's
simply a matter of changing the header.

All of the people who have contributed to GNUstep should have an assignment on
file with the FSF.   So I don't believe you have anything to worry about.
 
> Second Issue- GORM.  It's a great tool!  

Thank you, from all of us.  (Especially me!) :)

> As an Interface Building tool that
> is licensed under the GPL, my counsel (along with many engineers from many
> other programs) believes that GORM (and tools like GORM) can not be used
> because we (a commercial company) would have to release our proprietary
> software along with releasing GORM, keeping it free.  

This is not the case, for the reason I will explain below.

> In the GPL (GNU General
> Public License) it states under Terms and Conditions for Copying,
> Distribution and Modification….
>
> "0. This License… The "Program", below, refers to any such program or work,
> and a "work based on the Program" means either the Program or derivative work
> under the copyright law: that is to say…
> 
> 3. a) Accompany it with the complete corresponding machine-readable source
> code… complete source code means all the source code for all modules it
> contains…"
> 
> Building a new application with GORM, using the objects (like a button object
> that comes from GORM), and using the definitions listed in the GPL, my new
> application tool would fall under the GPL, in which I am legally bound to
> ship my new applications source code (built by GORM). Unfortunately, my new
> application (being in the commercial world) is proprietary, and I can not
> ship my source code (the GUI interface portion that GORM assisted me in and
> my methods which define the proprietary tool).  And that's my problem.

---
definitions: 
  encode = to archive data or to save flags or variable 
           values in a coded format.
  decode = to unarchive or to retrieve flags or variable 
           values from a coded format.
---

Many objects in GUI and BASE know how to encode themselves.  In the process of
encoding themselves, they encode any data they contain.  So when the programmer
then invokes [NSBundle loadNibNamed:owner:] or one of the other methods used to
load .gorm files in an application, all that happens is that it decodes
(unarchives) the data which is then used to reconstruct the objects.  The
objects are not "from Gorm" but they are simply instances of the classes
already present in the GUI library (which is LGPL) or possibly custom
subclasses that you or others have defined.

Many people make mistakenly believe that .gorm files are object code or
"bundles" which are linked-in when loaded and this is not the case, they are
nothing more than data.  They aren't object code any more than an XML or plist
file is. 

> Question for Issue Two: 
> Is it possible (only for the GORM application) to change the license to LGPL?
> Or 

Given that your previous assertion is based on a false assumption, I'm not sure
that it's necessary.

> Is it possible to change the GPL to allow all Interface Builders (IDE's) the
> ability create new applications in which the user does not have to release
> (to the world, to keep it free) their proprietary code?
>
> I would appreciate any assistance anyone in the GNUstep world could give (or
> within the GNU world). 

If you would like a more in depth understanding of what makes Gorm tick and why
I don't think it's a problem, please email myself and Adam Fedor (the GNUstep
project maintainer).

Of course, you are also free to contact the FSF directly. :)

Please let me know, if you wish me to clarify any of the above.

Thanks, GJC

=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.