On Thu, Mar 15, 2012 at 11:05 AM, Marco Donnarumma devel@thesaddj.comwrote:

thanks for the hint Bryan, that might apply. In this case, porting the code to Max or Max4Live is not legal, unless I specify an additional exception for it, is it correct?

so now, to make it spicier, I found this FAQ:

If a library is released under the GPL (not the LGPL), does that mean that
any software which uses it has to be under the GPL or a GPL-compatible
license?

Yes, because the software as it is actually run includes the library.

is this a show-stopper for porting of the XS into a proprietary environment?

p.s. I would be happy if it was.

On Thu, Mar 15, 2012 at 9:34 AM, Bryan Jurish < moocow.bovine@googlemail.com> wrote:

...

moin Marco,

sounds like a case for the "system library exception" to me; see here:

http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

... my take is that for a (Pd|Max|...) patch, the dataflow interpreter (Pd, Max, or what have you) represents the required "system library" for use of that patch, so the copyleft doesn't kick in. If you're the copyright holder, you can also always add explicit "linking exceptions" to GPL'd code, but I think that shouldn't be necessary in this case, since interpreter (Pd|Max|...) and program code (patch) are cleanly separated.

marmosets, Bryan

On 2012-03-14 13:48, Marco Donnarumma wrote:

...

hey folks,

I'm not going to port anything to Max, but someone expressed interest in porting the Xth Sense in Max.

Now, apart from my personal view about this, which is a diplomatic "I'd rather not, thanks. Port the patch you need to Pd instead".

what are the license issues here? The XS framework in Pd will be GPL. Can a Max software be GPL? What about copyleft then?

I found this but it's not clear. and I thought there could not be GPL software written in Max because the interpreter is closed-source. http://www.cycling74.com/forums/topic.php?id=1139

and this is nothing new but good and clear resource: http://www.blogherald.com/2009/07/07/the-basics-of-the-gpl/

thoughts, previous cases?

-- Bryan Jurish "There is *always* one more bug." moocow.bovine@gmail.com -Lubarsky's Law of Cybernetic Entomology

-- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK

Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com | http://www.thesaddj.com |
http://www.flxer.net
Director: http://www.liveperformersmeeting.net

On 15/03/12 20:48, Bryan Jurish wrote:

...

 so now, to make it spicier,
 I found this FAQ:
 ~~~~~~~~~~~~~~~~~
 If a library is released under the GPL (not the LGPL), does that
 mean that any software which uses it has to be under the GPL or a
 GPL-compatible license?

 Yes, because the software as it is actually run includes the library.
 ~~~~~~~~~~~~~~~~~

 is this a show-stopper for porting of the XS into a proprietary
 environment?

Well, I wouldn't say that Max is "using" XS in this sense, but rather that Max acts as the interpreter for XS.

if it is distributed as a Max patch, and run under Max, this is probably true.

But generally this is not how an end user runs a Max executable ... they do not have Max on their machine, the executable they receive includes all required to run it. There are no Max "system libraries" to call, and they do not have a "Max interpreter" on their system. This is very much part of the whole closed source model that Max uses ... people making patches in Max for somebody else very often do not wish to give them the patch but prefer to keep it private, and even if they also give them the patch code they generally don't want to require that person to buy Max before they can use it so they provide the executable as well.

...

p.s. I would be happy if it was.

I'd say, but I am not a lawyer, that it certainly is partly the case - GPLed libraries can't be part of standalone executables that are distributed to another party. They can be used by someone who owns Max and uses it to produce such executables for their own use only. They can be part of a Max patch that is distributed for use within a Max environment.

Sorry if that's bad news for you... as Stallman would very likely not hesitate to point out, __any__ kind of restriction on what your users can or cannot do with your software makes that software less free, and is therefore generally a Bad Thing (at least for the FSF and those who share its interests and goals).

Yes ... to _use_ for anything, by anybody, without restriction. But distribution of executables is very deliberately restricted (in a way I personally think is very appropriate), and must be accompanied with the full, properly licensable and reusable under GPL, code for the _whole_ executable.

With this in mind the motivation to port to Max may evaporate.

If it's any consolation, I suspect that the legal issues get quite a bit murkier if we consider "binary" distributions of the (XS+changes) package (if such things exist; I seem to recall having heard about them at some point), since these would assumedly include some part of the Max "system libraries" as well. There's probably a GPL clause which handles that as well (java class libraries might behave similarly), but I can't seem to turn it up at the moment.

Such binary distribution is very much part of the Max closed source model.

Simon

On 16/03/12 22:37, Bryan Jurish wrote:

On 2012-03-16 05:58, Simon Wise wrote:

...

But generally this is not how an end user runs a Max executable ... they do not have Max on their machine, the executable they receive includes all required to run it. There are no Max "system libraries" to call, and they do not have a "Max interpreter" on their system.

No more does the usual windoof user have a Borland or VisualC compiler installed, nonetheless it's totally legitimate (from the GPL side) to compile GPL code with one of these closed-source, commercial software packages and distribute the resulting executables, provided only that the source code for the *program* remains under GPL -- the GPL doesn't claim that because someone used Borland C to compile a GPL'd program and shared the result that Borland C must be GPL: that would be absurd...

The relevant difference between a compiled C program and a Max executable is that the C libraries that the compiled C program links to dynamically are on the users system, and installed quite separately from the GPL program ... these are the exception referred to in the GPL as system libraries ... however _all_ libraries linked statically and included with the compiled C program must be open source and compatibly licensed if you want to distribute the resulting binary if _some_ of it is built using GPL code.

In the case of a Max executable the Max libraries, and the other Max objects that were in the patch, are not on the users system ... they are included as part of the executable. If parts of that executable are GPL and parts are incompatible with GPL then you may use it yourself (for example to run on another computer for which you do not have a Max license) but the GPL does not allow you to distribute it (for example give it to the person you wrote it for, so they can use it on a machine that does not have a Max license).

Such commercial C compilers also often include local utility libraries with very lax redistribution conditions, so that their users can legally do things like that. The Max license might deal with compiled executables differently or incompatibly; I don't know.

exactly - this ensures that the required libraries can be built and distributed as system libraries, or are perhaps in a form that is compatible with your main license and can be linked statically.

Max however ensures the opposite. The internal Max objects are very much not licensed with "lax redistribution conditions", nor are the parts of Max you will be linking with. You must buy Max to use it to interpret a Max patch directly, or to save/compile a patch as an independent executable. You can however run this saved Max executable without buying Max, or having any Max libraries in your system, or having any Max interpreter or virtual machine or whatever.

In both cases this is intentional, not something that is an accident of the implementation details. And it is quite unlike running a java app on a local java VM, or linking with a closed source library you have either been given or have purchased a license for and then installed locally.

I believe it is only distributing a saved executable which includes GPL code that is not allowed. Distributing a Max patch where some of the components are GPL (and which will be interpreted by Max locally) is probably fine. It seems reasonable to me to consider those GPL components in isolation when they are simply part of a patch which is in itself the source code for an interpreter.

But distributing the saved executable is the usual practice in the Max way of doing things, if you are making something for somebody else.

...

...

...

p.s. I would be happy if it was.

I'd say, but I am not a lawyer, that it certainly is partly the case - GPLed libraries can't be part of standalone executables that are distributed to another party.

... unless the "corresponding source" of those executables is itself made available under the GPL... with which we're back to system libraries.

But the corresponding source cannot be made available ... parts of the source correspond to parts of the internal Max code, or to closed-source Max objects, and these parts are not available to be distributed ... the binary parts derived from this non-distributable code is included in the executable and is in no way a "system library" ... it is not on the users system independently, it is only present inside the executable in question! ... And this binary is not a compiled version of the patch ready to be "interpreted" by Max ... there is no interpreter installed locally to run it, yet it runs fine and quite independently.

You can, I think, distribute a Max patch which has some GPL objects in it (as long as you comply with the GPL for those objects and any restrictions on other objects). Then anyone can run it using Max as the interpreter, or compile it for their own use. But you cannot distribute an executable derived from some GPL code which is statically linked to some incompatible code. This is equally true of the output of a C compiler ... if the executable that results from compiling GPL code includes libraries that are incompatible with the GPL (rather than linking to external system libraries) then you cannot distribute the result.

...

...

Sorry if that's bad news for you... as Stallman would very likely not hesitate to point out, __any__ kind of restriction on what your users can or cannot do with your software makes that software less free, and is therefore generally a Bad Thing (at least for the FSF and those who share its interests and goals).

Yes ... to _use_ for anything, by anybody, without restriction. But distribution of executables is very deliberately restricted (in a way I personally think is very appropriate), and must be accompanied with the full, properly licensable and reusable under GPL, code for the _whole_ executable.

I agree -- in the case of C code it's pretty clear what is meant by "library", "linking", "using", etc., and of course what sort of creatures the "system libraries" are. For other languages, those terms get murky very quickly. I still think that a system library / interpreter / compiler exception might be made to apply, provided that the package source remained GPL, without trying to infect Max; but it seems to come down to a question of "linking" vs "interpreting/compiling".

The GPL in no way "tries to infect" any other code. That would be impossible anyway. A binary that is built from mixed GPL and more liberally licensed but compatible code must be accompanied by its complete source code - original licenses remain intact, not just the GPL parts.

This certainly restricts the ways that GPL code can be used significantly more than some other licenses do, since if you can't distribute your whole code then you can't use any GPL code. Projects may of course be tempted to restrict themselves to compatible code so that they are able to make use of the large body of existing GPL code.

...

With this in mind the motivation to port to Max may evaporate.

Hmm... if we can keep up the debate on GPL arcana for another few weeks, I'd say it almost certainly will ;-)

From the comments by the person who wrote the code it would seem he would prefer it if that motivation did evaporate. That was probably related to the reason he chose GPL as the license for his code in the first place.

The GPL is very clear in its intentions ... obviously any project that does not wish to restrict the use of their code in this way should not choose GPL (and should not make use of GPL code), and anyone looking for code to use without these restrictions should either look for code more liberally licensed, offer to buy a suitable license from the authors of some other existing code, or write their own code.

I don't think this is GPL arcana ... rather it is the very up front and explicit intention of the license, and presumably many coders who use it.

Trying to find loopholes to avoid this intention _is_ arcane and beside the point outside a courtroom, and hopefully doomed to failure inside one. Asking a coder to change the license if you suspect they don't care for this restriction and just applied GPL as some kind of default without even reading the preamble is reasonable, but don't be surprised if they do in fact care.

Simon

On 15/03/12 17:34, Bryan Jurish wrote:

... my take is that for a (Pd|Max|...) patch, the dataflow interpreter (Pd, Max, or what have you) represents the required "system library" for use of that patch, so the copyleft doesn't kick in. If you're the copyright holder, you can also always add explicit "linking exceptions" to GPL'd code, but I think that shouldn't be necessary in this case, since interpreter (Pd|Max|...) and program code (patch) are cleanly separated.

A Pd patch is usually distributed as a patch which is then interpreted by a locally installed Pd in the sense you describe ... but with Max distribution is usually as executables which include the parts of Max required for them to run, and perhaps other Max objects in the patch which may or may not be open source. Max is expensive and a license covering each machine running it as a patch is required, but Max is not needed on the machine to run the programs distributed this way. Max is certainly not a system library if it is not on the local system.

Max could be viewed as a compiler in this case, with the resulting binary package the "output". But now this whole executable would seem to be linked to the GPL code, and distribution must be accompanied by its whole source code etc according to the GPL. But since large parts of that source is closed that is not possible.

This is in contrast to many compilers where the built-in functions are distributed separately as system libraries and these must installed on the local machine independently of the distributed GPL program which links to them (as system libraries).

Certainly porting a Pd library to Max, then using it and any executables you make yourself is very much within the GPL.

Distributing that port ready to use in Max, along with its source code of course, is fine as long as any other code used doing the port is ok to distribute according to the GPL.

I'd think that distributing a Max patch which includes parts of the ported library is ok, again as long as it is accompanied by all the code you used in the port etc, for the reasons you stated above.

But if that patch is saved as an executable you can only use it yourself, on as many machines as you like ... you cannot give the executable to someone else.

So a GPL library does not fit with the closed source distribution model used by Max.

(but of course IANAL)

Simon