New copying license for classes/modules: CGPL

New copying license for classes/modules: CGPL

[Wouter Scholten]

Summary: CGPL license for classes/modules/subroutines




Introduction
============
The GPL/LGPL licenses are not adequate for classes as these must be
compiled into a program, but they are really used in the same way as a
library: to get access to already coded functions. Similarly for non-OO
programming, small utilies can easier be compiled into a program (and
possible altered a bit) than linked with a shared lib (you must make
sure the target system has the lib you use etc). An example would be GIF
decoders and time/date functions.

I therefore suggest a CGPL license which says:
- using the classes (or subroutines, modules, ...) for any product is
allowed, commercial, GPL, LGPL, BSD, etc.

- Any enhancements to the classes must be released freely with source by
uploading to a server like sunsite.unc.edu (this is stronger than the
GPL/LGPL requirement)

- additional classes made in a program using them, need not be released.

There are some other cases where the CGPL should also be used, like
wrappers for libraries. These need to be compiled into a program
although it's clear they are used like a library, but the code must be
compiled into the program. This latter requirement means the LGPL
doesn't work (it becomes automatically equivalent to a GPL).


Rationale
=========
1. It should not be necessary to reinvent the wheel for any programmer.
Creativity should go into the toplevel stuff, not in reinventing the
wheel for the umpteenth time.
2. Now, there's no or almost no incentive for commercial programmers to
release their stuff freely. Now, if we have a CGPL, then they
would/could also
contribute.
3. The top level/creative/specific stuff should fall under the license
one wants (Comm., GPL, LGPL, BSD, whatever)
4. We could have a common base for BSD/GPL versions of programs.
Duplication of efforts between  *BSD and Linux would be lessened.


Which license for what part?
============================
Well, it's your own choice, but CGPL for the really general
things, Commercial/GPL/LGPL/BSD/other for the higher level stuff seems
appropriate. 
Completely CGPL'ing would be possible but only useful in some cases.


What should the license look like?
==================================
Mike Stump suggested:

-  Try the libgcc trick.  Do a standard GPL, then add:
-
-  /* As a special exception, if you link this library with other files,
-     some of which are compiled with GCC, to produce an executable,
-     this library does not by itself cause the resulting executable
-     to be covered by the GNU General Public License.
-     This exception does not however invalidate any other reasons why
-     the executable file might be covered by the GNU General Public
License.
-   */
-
-  to each file, just after the standard opening.  You'll probably want
-  to modify that slightly to target what it is you want to allow. 
Note,
-  once you do this, you cannot incorporate normal GPL or LGPL code,
-  without the copyright holder's explicit blessing.  If you own it
-  (wrote it), then there is no problem.
-
-  It works well for libgcc.a and libstdc++, the runtime libraries for
-  gcc and g++, and has withstood the test of time IMHO.

In the CGPL case, the 'compiled with GCC' should be removed, and 'link
with'
should be replaced.

It should probably look somewhat like this:
GPL +
  /* As a special exception, if you link a complete library made from
these classes/modules/functions with other files,
     or compile these classes with other files to produce an executable,
     this library does not by itself cause the resulting executable
     to be covered by the GNU General Public License. This will be
covered by the license that is implied by the license on the components
not obtained from the library.
     This exception does not however invalidate any other reasons why
     the executable file might be covered by the GNU General Public
License.

     Any enhancements to the classes/library must be released freely
with
     source by uploading to a server like sunsite.unc.edu, immediately
after releasing any program based on these enhanced classes.
   */

i.e., the components used would remain under the CGPL, and the
executable falls
under the same license as the top level stuff (*GPL, BSD,..)

Furthermore, I want to avoid the vagueness of the GPL/LGPL about
releasing source, which can be 'delayed' (see the 'What does the GPL
really say' discussion in comp.lang.ada)

Any suggestions or improvements ?

BTW, I don't like the standard GPL opening for all files. This adds an
enourmous amount of text for mostly small files. Can one say, 'see the
file CGPL explaining the license for this file', where the file CGPL
contains a reference to the GPL, with the addition as above  ?


Wouter

Re: New copying license for classes/modules: CGPL

[Robert Dewar]

Woulter says

<<The GPL/LGPL licenses are not adequate for classes as these must be
compiled into a program, but they are really used in the same way as a
library: to get access to already coded functions. Similarly for non-OO
programming, small utilies can easier be compiled into a program (and
possible altered a bit) than linked with a shared lib (you must make
sure the target system has the lib you use etc). An example would be GIF
decoders and time/date functions.

I therefore suggest a CGPL license which says:
- using the classes (or subroutines, modules, ...) for any product is
allowed, commercial, GPL, LGPL, BSD, etc.

- Any enhancements to the classes must be released freely with source by
uploading to a server like sunsite.unc.edu (this is stronger than the
GPL/LGPL requirement)

- additional classes made in a program using them, need not be released.

There are some other cases where the CGPL should also be used, like
wrappers for libraries. These need to be compiled into a program
although it's clear they are used like a library, but the code must be
compiled into the program. This latter requirement means the LGPL
doesn't work (it becomes automatically equivalent to a GPL).>>


Robert replies

One thing that people seem confused on is that GPL is simply a form of license
used by some people because it suits their purposes. If you are writing a
piece of code, you are the author and copyright holder (assuming no prior
agreements to the contrary), and you can decide how to license it. You can
use the GPL if it suits your purpose, but if it doesn't, you can modify it
in any manner you like. So if you are writing something where you wish to
use a modified version of the GPL, you can go ahead and do it. It is helpful
if you make clear what your modifications are, so that people are not confused.

As to the class issue itself, in Ada of course, the equivalent problem does
not exist, since Ada works with semantic connection using WITH, rather than
by copying text.

However, with Ada, the issue of generics does arise, not because text is
copied, but because the code is copied into your program, and for GNAT we
use a specially modified version of the GPL for the library that makes
clear that generics do not cause a problem:

-- As a special exception,  if other files  instantiate  generics from this --
-- unit, or you link  this unit with other files  to produce an executable, --
-- this  unit  does not  by itself cause  the resulting  executable  to  be --
-- covered  by the  GNU  General  Public  License.  This exception does not --
-- however invalidate  any other reasons why  the executable file  might be --
-- covered by the  GNU Public License.                                      --

So if you have some software that you want to release under your "CGPL",
just go ahead, no debate is required, no agreement from anyone else is
required, and probably the most useful way to advance the discussion is
to release the sotware, and then let users point out any problems.

Re: New copying license for classes/modules: CGPL

[Bertrand Meyer]

Robert Dewar wrote:
 
> However, with Ada, the issue of generics does arise, not because text is
> copied, but because the code is copied into your program, and for GNAT we
> use a specially modified version of the GPL for the library that makes
> clear that generics do not cause a problem:
 
As far as I understand the discussion, the problem will not
arise for Eiffel. The language is designed so that the code of
generic classes need not be duplicated for different
"generic derivations" of the same generic class
(i.e. different types obtained by providing different generic
parameters, as in LIST [BOAT] and LIST [PERSON]).  
Our implementation, and I believe others too, indeed do not
duplicate the code in such cases. Nor is there any need to
"copy the code into your program".

(Please note that this observation includes no criticism or even
mention of Ada; its intention is simply, since Robert Dewar's
message was cross-posted to comp.lang.eiffel, to address his
point insofar as they apply to Eiffel.)

More generally I think that the idea of  adapting the Gnu
Public License to cover reusable O-O components is excellent.

-- 
Bertrand Meyer, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com

Re: New copying license for classes/modules: CGPL

[Joerg Rodemann]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:
  
> As far as I understand the discussion, the problem will not
> arise for Eiffel. The language is designed so that the code of
> generic classes need not be duplicated for different
> "generic derivations" of the same generic class
> (i.e. different types obtained by providing different generic
> parameters, as in LIST [BOAT] and LIST [PERSON]).  
> Our implementation, and I believe others too, indeed do not
> duplicate the code in such cases. Nor is there any need to
> "copy the code into your program".

Well, sorry to raise this topic again, we had a long discussion about that
shortly and it's still continuing, but this seems to point to some problems
we discussed in a concrete situation: how is the Eiffel system going to check
the usage of a class versus its specification (seems we agreed on the term
short-flat form as a similar concept to the Ada spec.) Is the Eiffel system
able to check against the compiled library or is it more likely to leave that
to the linker as in C++? (Sure, you can check against header files there, but
who tells you they are correct, until you link it into an executable?)

Is this a problem and a point for separated interface/implementation way?
Or is there a simple solution? If so how does it work? Certainly you would
not like to include the complete library source, would you?

> (Please note that this observation includes no criticism or even
> mention of Ada; its intention is simply, since Robert Dewar's
> message was cross-posted to comp.lang.eiffel, to address his
> point insofar as they apply to Eiffel.)

> More generally I think that the idea of  adapting the Gnu
> Public License to cover reusable O-O components is excellent.

Agreed: the time is ripe to think about reusing in a larger way. And I would
like to see a much better interoperability between OO-languages as well.

Regards

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: New copying license for classes/modules: CGPL

[Robert Dewar]

Bertrand said

<<As far as I understand the discussion, the problem will not
arise for Eiffel. The language is designed so that the code of
generic classes need not be duplicated for different
"generic derivations" of the same generic class
(i.e. different types obtained by providing different generic
parameters, as in LIST [BOAT] and LIST [PERSON]).
Our implementation, and I believe others too, indeed do not
duplicate the code in such cases. Nor is there any need to
"copy the code into your program".>>

Right, this kind of genericity is easily achieved with shared code. Of course
Ada genericity is quite a bit more extensive, and for example, even in the
simple case of a generic instantiated with two different floating-point
precisions, the only path to efficient code is duplication.

This is ONLY an efficiency issue, there is nothing in Ada which requires
code duplication. Some compilers use macro substitution always, some use
shared code always, some pick and choose, are the user can control which.

Re: New copying license for classes/modules: CGPL

[Robert Dewar]

Bertrand said

<<As far as I understand the discussion, the problem will not
arise for Eiffel. The language is designed so that the code of
generic classes need not be duplicated for different
"generic derivations" of the same generic class
(i.e. different types obtained by providing different generic
parameters, as in LIST [BOAT] and LIST [PERSON]).
Our implementation, and I believe others too, indeed do not
duplicate the code in such cases. Nor is there any need to
"copy the code into your program".>>

I assume though that a good Eiffel compiler can most certainly inline
procedure bodies across file boundaries (or at least that the language
does not preclude this optimization), and this generates the same kind
of GPL licensing concerns as generic instantiation by copying (which is
after all just a form of inlining).

Enforcing assertions in Eiffel

[Joachim Durchholz]

Joerg Rodemann wrote:
> 
> Well, sorry to raise this topic again, we had a long discussion about
> that
> shortly and it's still continuing, but this seems to point to some
> problems
> we discussed in a concrete situation: 

Well, no - I can't imagine what the GPL (a *legal* contract) has to do
with Eiffel assertions (a *technical* contract).

> how is the Eiffel system going
> to check
> the usage of a class versus its specification (seems we agreed on the
> term
> short-flat form as a similar concept to the Ada spec.) Is the Eiffel
> system
> able to check against the compiled library or is it more likely to
> leave that
> to the linker as in C++?

Eiffel assertions are predicates, which in the language context means
boolean expressions. If the proper options are set at compile time these
expressions will be evaluated at the appropriate time; a violated
assertion will raise an exception.
Needless to say that these exceptions shouldn't be called to "fix things
up" in any way - what should be fixed is the code, not the execution. Of
course such an exception might still be caught to prevent disaster, e.g.
in an embedded system to safely shut down the machine or to fall back to
some panic mode of operation, or in an interactive system to report the
error and ask the user to try something different.

One important side note: You can compile each class with its individual
level of assertion checking (preconditions, postconditions, invariants,
and a few other assertion types not relevant on the interface level).
However, precondition checks are done in the caller (at least
conceptually), so even if you use a library compiled with all checks
off, you can still run your code with precondition checking on and
you'll get exceptions if you call that library with (say) wrong
parameters.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Enforcing assertions in Eiffel

[Joerg Rodemann]

Joachim Durchholz (joachim.durchholz@munich.netsurf.de) wrote:
> Joerg Rodemann wrote:
> > 
> > Well, sorry to raise this topic again, we had a long discussion about
> > that
> > shortly and it's still continuing, but this seems to point to some
> > problems
> > we discussed in a concrete situation: 

> Well, no - I can't imagine what the GPL (a *legal* contract) has to do
> with Eiffel assertions (a *technical* contract).

Well, are you trolling? Your statement is certainly true...and my followup
was not about assertions (you Eiffel guys seem to be a bit obsessed but
this thing, aren't you? :) ). What I was to question about was how an
Eiffel system could check against the specification (short-flat form) of
a class if it is already precompiled. The thread I mentioned was this
awfully long one about keeping the spec in a seperate file or not.

I received just one answer via email to my request. I hope Frank Arnaud
does not complain about me quoting it here:

   "It is because there are no really "compiled" libraries in Eiffel. All
   forms of precompiled libraries contain the information which is in the
   source code in another form."

I am still not quite sure what is meant by this exactly, but I have an
idea about what is going on. If there is something more to consider please
clarify. But on the other hand please do not just continue those long
threads about spec/impl and assertions.

Regards

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Enforcing assertions in Eiffel

[Joachim Durchholz]

Joerg Rodemann wrote:
> 
> Joachim Durchholz (joachim.durchholz@munich.netsurf.de) wrote:
> > Well, no - I can't imagine what the GPL (a *legal* contract) has to
> > do with Eiffel assertions (a *technical* contract).
> 
> Well, are you trolling? Your statement is certainly true...and my
> followup was not about assertions (you Eiffel guys seem to be a bit
> obsessed but this thing, aren't you? :) ).

Well, it is the one thing that makes a real difference. Most other
issues of Eiffel-vs-the-rest-of-the-world are largely a matter of style,
but this one is a real screamer.

> What I was to question
> about was how an Eiffel system could check against the specification
> (short-flat form) of a class if it is already precompiled. The thread
> I mentioned was this awfully long one about keeping the spec in a
> seperate file or not.
> 
> I received just one answer via email to my request.

Sorry, I sort of dropped from that thread.

I haven't looked at Eiffel library formats, but from the technical
descriptions I think most library formats contain several compiled
variants of the same code, one variant for each assertion checking level
(there are about half a dozen levels). This can be optimized of course,
and this is probably done; for example, the library could contain code
with all assertion checking on and leave it to the linker to filter out
the assertion checking code (easy enough to do when the library code is
decorated).
Remember Eiffel doesn't have a linker in the traditional sense; several
important optimization steps (in particular inlining) are done only
after pulling together all the required classes.
In fact Eiffel libraries might be nothing more than decorated abstract
syntax trees.

Regards,
Joachim
-- 
Please don't send unsolicited ads. (The @@ is for confusing spambots.)

Re: Enforcing assertions in Eiffel

[Morgan Palaeo Associates]

rodemann@mathematik.uni-ulm.de (Joerg Rodemann) wrote:

^
| But on the other hand please do not just continue those long
| threads about spec/impl and assertions.
v

Personally, I think the debates have been very constructive - I've long been
interested in language philosophy; why languages are designed the way they
are; and reading the Ada/Eiffel debates has inspired me to think through my
own opinions.  Usually I conclude that the ideal is an imaginary language
somewhere between Ada and Eiffel.  Many thanks to everyone who has participated
in the debates to help make comp.lang.ada an exciting place to visit!!

-- Adrian Morgan

Re: Enforcing assertions in Eiffel

[Joerg Rodemann]

Morgan Palaeo Associates (morganpalaeo@peg.apc.org) wrote:
> rodemann@mathematik.uni-ulm.de (Joerg Rodemann) wrote:
> ^
> | But on the other hand please do not just continue those long
> | threads about spec/impl and assertions.
> v

> Personally, I think the debates have been very constructive - I've long been
> interested in language philosophy; why languages are designed the way they
> are; and reading the Ada/Eiffel debates has inspired me to think through my
> own opinions.  Usually I conclude that the ideal is an imaginary language
> somewhere between Ada and Eiffel.  Many thanks to everyone who has
> participated
> in the debates to help make comp.lang.ada an exciting place to visit!!

It seems I have to clarify my statement. I too found those threads quite
interesting. But in the end I noticed at least a lot of repetition of
arguments. From this point of view (as I wrote one line above of the 
quoted lines), my statement was just a reminder to check whether these
arguments had already been mentioned.

Regards

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Enforcing assertions in Eiffel

[W. Wesley Groleau x4923]

> > ....  Usually I conclude that the ideal is an imaginary language
> > somewhere between Ada and Eiffel.  ....

Yes.  We should make a hybrid of Ada and Eiffel and call it
Afel (rhymes with waffle).  (To repeat a bad joke from last month.)

Seriously, I agree that each of these languages has some features
that could improve the other.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Enforcing assertions in Eiffel

[Jon S Anthony]

In article <343174DF.CB2B2112@munich.netsurf.de> Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:

> Remember Eiffel doesn't have a linker in the traditional sense;
> several important optimization steps (in particular inlining) are
> done only after pulling together all the required classes.  In fact
> Eiffel libraries might be nothing more than decorated abstract
> syntax trees.

That's basically the way many (most?) Ada83 implementations worked wrt
to this issue...

/Jon
-- 
Jon Anthony
STL, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

JOVIAL (J3)

[John R. Fluharty, Jr]

I'm looking for a copy of the J3 JOVIAL standard,
either AFM-1024 or MIL-STD-1588.  It's out of
print.  Any have a copy or know where I can get
one (or better yet, a YACC grammar for J3 JOVIAL).