G'day all,
[Sorry for breaking the thread -- digest strikes again...]
Like RMS, I strongly dislike "Open Source" as an umbrella term, and strongly
prefer "Free (as in Freedom)" or "Libre" (e.g. LibreOffice): The underlying
concepts are massively, massively different.
Before I go any further, Lua's use of the MIT license has been a key reason
why it has thrived in some key areas, such as game scripting. If it was
GPL (probably v2; perhaps, more recently, v3), then some key early-adopter
companies would (very likely) not have adopted it. This has been a feedback
loop -- Lua has been enriched by its wider audience.
The GPL combination of Copyright + License is a brilliant piece of legal
engineering, since Copyright as a starting point is so uniform and clear
because of the Berne convention. The GPL is all about encouraging, but
also being able to force, if necessary, a source-code-sharing culture.
With GPL, if you "combine" some GPL code with your code, the entire linked
(statically or dynamically) result MUST be licensed with the same GPL
license that was in the library. This is non-negotiable. In particular,
you MUST grant exactly all the privileges and restrictions of the original
GPL component, including explicitly licensing your entire program for all
downstream users, as follows:
You explicitly grant all the privileges and restrictions of the
GPL code that you used, and to all other code linked in the same
package, to all clients/users of your code. This license grant
is non-revocable, once given. Furthermore, you must apply the
same GPL license to all "down-stream" clients of your source
code.
The "strength" of the linkage between some GPL-controlled source code,
and the end-user, can vary widely, and so there is some interpretation
that needs to be looked at here. For example. "GNU Grep" is GPLv3
licensed, yet users can run the binary without incurring any license
restraints on their work (perhaps Grep being invoked in a Bash script).
Any end-user of the GNU Grep utility, however, has the right to receive the
source code for that binary utility, under the provisions of the GPL.
The Free Software Foundation also recognised that there were cases
where the full "Copyleft" demands of the GPL were too onerous, or perhaps
there was no benefit since an outside entity (library) already covered nearly
all of the territory. Thus, the "LGPL" "Lesser" GPL license was created and
is used in some situations, such as the support code for the GNU Compiler
Collection (GCC) itself. The LGPL demands that modifications made to the
LGPLed-library itself must be made available, with the same LGPL license
attached to the changes, but does not demand that other parts of the program
must adopt the LGPL.
If an application (library) calls on libraries with multiple licenses, it is
the responsibility for the the application's owner/publisher to ensure that
there are no conflicts between any of the components (using a matrix?).
--
Okay, enough on general licenses; some brief comments on Tecgraf stuff:
CD explicitly "depends on" IM, and IUP explicitly "depends on" CD and IM.
Therefore, all worries regarding licenses in CD potentially flow up into
IUP.
Therefore, I repeat an earlier plea: Please, please separate the top-level
projects (e.g. CD), which are currently packaged into a single
dynamically-linked library (e.g. .dll or .so, etc) into separate modules,
at least initially based on licence considerations (e.g. tuio -- GPL).
This separation would mean that there would be much more clarity, than at
present, regarding what license conditions an end-user would be exposing
themselves to -- they can explicitly avoid GPL libraries by not linking to
them, and/or not "require()"ing them in a Lua script.
I would also urge that the top-level README at least mention that the
product has components with different licensing requirements, and that
the top-level LICENCE file enumerate all the licenses in use in the module,
along with expressly naming MIT for the code not covered by the enumerated
list. For cumulative projects (CD requires IM, and IUP requires CD+IM),
the top-level LICENSE file (e.g. for IUP) either explicitly enumerates the
requirements inherited from the lower projects, or else very strongly
points out the scale and importance of licenses in those other packages.
And finally, as before, I would like to see the libraries brought up to
be top-level targets in the Makefile, as is mostly true within IUP, but
should be applied to IM and CD, so that an "EXCLUDE_TARGETS" or perhaps
also an "INCLUDE_TARGETS" macro could be used at the top level of the
project Makefile.
--
cheers,
s-b etc.
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
