On Mon, Sep 26, 2011 at 11:20:13AM -0400, Hans-Christoph Steiner wrote:

Welcome to Pd! This is a nice entry, showing up with a patch to fix a
bug :-D.

Thanks, nice to meet you. I may as well put these C skills to use, eh?

The whole canvas_key thing is pretty messy, so I think your
patch is probably as good as its going to get. I'll apply it. Patches are definitely very welcome :-D.

Thanks for being so responsive.

In the future, please submit them to the patch tracker, the 'git format-patch' format is preferred:

http://puredata.info/dev/patchtracker

Well, I wasn't yet convinced that the patch was in its final form -- the inlined diff was intended for discussion. :)

FWIW, I'd seen reference to the patch tracker while browsing through http://puredata.info/dev. There's a decent amount of documentation there for potential contributors to orient themselves, though like most wikis the world over, some of the material is out of date.

If I figure out further improvements, I will submit final patches to the patch tracker according to the project's preferred procedures.

Ideally, I would like to eliminate the "#ifdef __APPLE__" altogether. That's probably not possible. My second choice would be to keep only the higher keyval numbers, since that's what my current system needs. But maybe I've been going down the wrong path this whole time...

Curiously, the official Pd 0.43 OS X binary does not have any problems on Snow Leopard with regards to cursor keys. I only get these problems when building from source.

I tried compiling from the 0.43 source tarball. (I tried first to find a git tag corresponding to 0.43; "git tag -l" didn't find anything, but I'm not a git power user and maybe I'm missing something.) Building with the "new" build system required the "fix launching on Mac OS X" patch (3360aba7). (Building with the "old" build system failed spectacularly and I wasn't sure how to proceed.)

Compiling the 0.43 sources produced a binary that doesn't handle cursor keys correctly. So, something about my Snow Leopard build environment is causing the problem...

Hmm, I had ActiveTCL 8.6 installed... but disabling that didn't help. (Aside: It's a pain to hide everything that Tcl installs.)

Any ideas? How does my system differ from the system which was used to build the official 0.43 OS X binary?

Marvin Humphrey

Le 2011-09-25 à 09:29:00, Marvin Humphrey a écrit :

The patch below fixes the problem. I don't know if it's the right solution, though.

Pd doesn't _have_ to pass keynums around like that. If the Tk code were sending Up/Down/Left/Right names as given by Tk's bind's %K (uppercase), then you wouldn't have to replicate in g_editor.c things that Tk already does as part of its portability layer.

Afaik, %K and %N are portable, whereas %k is not portable. It's not a matter of whether it's a number or not (%N is also a number), it's a matter of whether the number is consistent on all platforms or not.

There might be slight compatibility differences in %K/%N too, but just the unavoidable ones ; whereas %k could even change from keyboard to keyboard on the same platform... there's not much of a guarantee on it.

DesireData used %K all over, except for the Keyboard View feature which really had to use %k, if I recall correctly.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

On Sep 27, 2011, at 11:47 PM, Marvin Humphrey wrote:

On Tue, Sep 27, 2011 at 11:50:07AM -0400, Mathieu Bouchard wrote:

...

Le 2011-09-25 à 09:29:00, Marvin Humphrey a écrit :

...

The patch below fixes the problem. I don't know if it's the right
solution, though.

Pd doesn't _have_ to pass keynums around like that. If the Tk code
were sending Up/Down/Left/Right names as given by Tk's bind's %K
(uppercase), then you wouldn't have to replicate in g_editor.c things that Tk
already does as part of its portability layer.

Ha, interesting.

The patch below, which also achieves correct behavior of cursor keys
under Snow Leopard, is an alternative to the patch supplied earlier. This one
has the advantage of removing the "#ifdef __APPLE__" code from src/ g_editor.c, as the normalization is now achieved via Tk. However, I don't yet
understand all the ramifications, just as I did not with the last patch.

Marvin Humphrey

The question with this patch then, is does it work fine on GNU/Linux
and Windows? I really think the whole key handling code in both Tcl
and C needs rewriting rather than patching. Perhaps matju's answer is
the way forward, making it based on the %K bind var rather the %k.

I added a couple more keys to your origin one:

.hc

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

On Sep 28, 2011, at 1:23 AM, Marvin Humphrey wrote:

On Wed, Sep 28, 2011 at 12:43:06AM -0400, Hans-Christoph Steiner
wrote:

...

The question with this patch then, is does it work fine on GNU/ Linux and Windows?

I don't know. I'm experienced with cross-platform development and I
have a Windows 7 dev environment available via a Bootcamp partition, so in
theory I could check. It seems likely to work, but it has not been
verified. It's a PITA to power down OS X and fire up Windows, so I don't do it very
often. No X Windows box immediately available, either.

I don't see any unit tests. Are there any?

There isn't really any unified test method. I think the zexy library
has some, and someone else recently starting writing a test framework
in Lua. But regular automated unit tests is something that we sorely
need.

What we do have is a farm of dev/build servers which you can get ssh
access to.

http://puredata.info/docs/developer/PdLab

.hc

...

I really think the whole key handling code in both Tcl and C needs rewriting rather than patching.

I'm not prepared to offer an opinion on that, as I'm not yet
sufficiently familiar with the code base.

If we were to make such an attempt, I'd suggest preserving the
existing interface while changing the implementation. And of course it would
seem wise to secure the blessing of Mr. Puckette in advance as to the general
approach.

...

Perhaps matju's answer is the way forward, making it based on the
%K bind var rather the %k.

That seemed logical to me and I attempted to figure it out, but came
up short. Grepping the source for "%k" didn't turn up anything. Grepping for
"%K" turned up the pd_bindings.tcl file, and I hacked from there.

...

I added a couple more keys to your origin one:

Nice!

Marvin Humphrey

News is what people want to keep hidden and everything else is
publicity. - Bill Moyers

---

From: Richie Cyngler glitchpop@gmail.com To: Marvin Humphrey marvin@rectangular.com Cc: pd-list@iem.at Sent: Sunday, September 25, 2011 3:16 AM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

Hey Marvin,

If you drag select an object or group of objects you can use the "nudge" functionality with cursor keys, you can also hold shift for block moves. So that functionality is already there.

In regards to a key, like enter, to "complete" an object I think that's a great idea. I was just thinking the same thing actually.

I'm using Pd-l2ork, and control-Enter toggles between creating the object and editing the text in the box.

I thought Pd-extended had this same key binding, but Pd as installed from the debian package in Wheezy does not.

-Jonathan

Oh wow, command+enter works for me! Thanks Jonathan my workflow just got a whole lot smoother! Marvin I'm on OSX 10.6.8 running Pd-extended. Drag select and cursors keys are also working for me. Maybe give Pd-extended a try?

On Mon, Sep 26, 2011 at 4:26 AM, Marvin Humphrey marvin@rectangular.comwrote:

On Sun, Sep 25, 2011 at 10:51:56AM -0700, Jonathan Wilkes wrote:

...

I'm using Pd-l2ork, and control-Enter toggles between creating the object and editing the text in the box.

I thought Pd-extended had this same key binding, but Pd as installed from the debian package in Wheezy does not.

None of these combinations provide that behavior on Pd Vanilla built from latest git on OS X 10.6:

control-Enter command-Enter option-Enter shift-Enter

I could live with control-Enter instead of <ESC> (especially since I've rewired my caps lock key to control at the OS level using the Keyboard system prefs) -- though <ESC> works so well for switching modes in Vim. :)

Marvin Humphrey

----- Original Message -----

From: Marvin Humphrey marvin@rectangular.com To: Richie Cyngler glitchpop@gmail.com Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at Sent: Sunday, September 25, 2011 7:19 PM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

On Mon, Sep 26, 2011 at 08:34:26AM +1000, Richie Cyngler wrote:

...

Oh wow, command+enter works for me! Thanks Jonathan my workflow just got a whole lot smoother! Marvin I'm on OSX 10.6.8 running Pd-extended. Drag select and cursors keys are also working for me. Maybe give Pd-extended a try?

Thanks, but if I become a serious user, I hope to make substantial contributions to Pd at some point, and for various reasons my preference is to contribute to a BSD-licensed project over one that is licensed under the GPL.

If you are planning on making substantial contributions to Pd Vanilla, you should consider making a few "test" contributions to gauge the amount of time and energy it will take you to get patches accepted; something like a patch for getting this <control-enter> key binding would be a good start.

Also, realize that any substantial changes you make may sit in the patch tracker for some time-- it's not easy getting them accepted, nor communicating with Miller if they don't.  Additionally, if they are big, desirable improvements to the Pd community they may find their way into Pd-extended anyway.

-Jonathan

(Not trying to start a discussion, just explaining why I will continue to use Vanilla for now.  If someone absolutely must ask why, I expect to reply offlist in the interests of being a good guest.) :)

I was under the impression that Pd-extended consisted of augmentations to Vanilla.  Is it actually a fork?

Marvin Humphrey

On 26/09/11 12:54, Marvin Humphrey wrote:

Well, controlling entities for open source projects have to be responsive to their communities. If they are not, they get forked, or people move on to other things.

... or this "community" makes arrangements to be able to contribute to a codebase which is more widely accessible, while keeping that codebase in reasonable sync with the more tightly monitored and controlled original, and pushes those contributions upstream whenever possible.

That way you may get the best of both worlds - a more volatile extended version, with features added by this "community", and a more stable vanilla version which adopts some of these features when integrating them fits with the long term plans and/or the available time of this "controlling entity" (and of course when they are available in a suitable license - which any patch offered upstream should be).

But this is not a suggestion for the future, it is the arrangement that has been in place for some years now ... as the one that seems to suit both the "community" and the "controlling entity" that you refer to.

Then you can also choose which version to use, depending on whether you want the extra features, or you can't use the licenses in the extended version, or you want to maximise portability, etc etc. And if you wish to offer patches you can push them to the extended version, have them integrated with the other "community" work, then propose them as working, tested and perhaps popular for the vanilla version ... or you can propose patches directly to the vanilla version and wait for the outcome.

Simon

----- Original Message -----

From: Marvin Humphrey marvin@rectangular.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Monday, September 26, 2011 12:54 AM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

On Sun, Sep 25, 2011 at 05:33:22PM -0700, Jonathan Wilkes wrote:

...

If you are planning on making substantial contributions to Pd Vanilla,

I wouldn't say I'm "planning" on it -- more that I'd like to keep that option open.

...

you should consider making a few "test" contributions to gauge

the amount of

...

time and energy it will take you to get patches accepted; something like a patch for getting this <control-enter> key binding would be a good

start.

Indeed, I've already started that process, by negotiating the shape of the patch to come and building consensus.  :) There's been some question as to what key combo should be used.  It seems that [modifier]-Enter is already in use and people are happy with it, so I'll go that direction despite my mild personal preference for <ESC>.

A patch which has consensus support from the community probably has a better chance at being applied, even under BDFL governance.  :)  But consensus can be costly to achieve depending on the project's culture...

...

Also, realize that any substantial changes you make may sit in the patch tracker for some time -- it's not easy getting them accepted, nor communicating with Miller if they don't.

Well, controlling entities for open source projects have to be responsive to their communities.  If they are not, they get forked, or people move on to other things.

It's been forked-- four times (AFAIK).  Nova, DesireData, Pd-extended, and Pd-l2ork.  Two of those forks-- Nova and DesireData-- had explicitly stated goals which basically boiled down to being more responsive to the Pd community (in addition to many other things).

I believe the author of Nova moved on to developing parallelism for Supercollider, which will probably become a core part of Supercollider well before any revision of his 7-year old tooltip patch ever gets included in Pd Vanilla.  So as a perfect example of your theory, yes-- Pd gets forked, and/or people move on to other things!

Pd-extended and Pd-l2ork are extant.  There there has been some effort to lessen the number of core differences between Vanilla and Pd-extended.

But it's also generally true that large, boil-the-ocean patches are costly to review, especially for stable projects with large user bases, and so contributors are well-advised to bear that in mind and prepare small, easily-digested morsels when possible.

...

Additionally, if they are big, desirable improvements to the Pd community they may find their way into Pd-extended anyway.

So long as contributions to Vanilla are integrated into Pd-extended in a way that adheres to the provisions of Vanilla's BSD license, then there's no problem. :)

The three clauses of the BSD license used by Pd Vanilla are compatible with both the GPL v2 & v3

-Jonathan

Cheers,

Marvin Humphrey

----- Original Message -----

From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Monday, September 26, 2011 3:27 AM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-09-26 07:59, Jonathan Wilkes wrote:

...

The three clauses of the BSD license used by Pd Vanilla are compatible with

both

...

the GPL v2 & v3

but not the other way round.

Yes, in fact-- that's how compatibility works.  All the terms of both versions of the GPL v2 and v3 are compatible with the entire three-clause BSD license.  There are of course many ways for an author to come to a conclusion about what is the best license for a piece of software, but none of them have to do with the compatibility of the two licenses with each other.

As a separate issue-- if a piece of software is licensed under foo, and the author only accepts patches that are licensed under foo, then obviously you should license the patch under foo if you want to get it accepted.

so if you want your patches to be included into Pd proper, then they must (legally) be BSD3.

The main restriction here is that you cannot take or revise someone else's code that is licensed under the GPL and decide to _change_ the license to something else.  The GPL does not allow that.

You can take code you have written yourself which is licensed under the GPL for one project, and license it separately under the three-clause BSD or some other license for another project (or even sell specific licenses to a person or company).

any patch for puredata posted to the patch tracker, is silently assumed to be BSD3 my miller (see the list archives for his quote) unless explicitely stated otherwise.

Is there a way to add a blurb under "Add artifact" that addresses this?

-Jonathan

asdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AKWYACgkQkX2Xpv6ydvSuYwCeLINkVFyNQJcOOlx0ZTLyUomE 5EUAmgI48IMGMQqWc1YLUDzl5aBn4bVp =ZF9H -----END PGP SIGNATURE-----

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Le 2011-09-26 à 17:26:00, Marvin Humphrey a écrit :

On Mon, Sep 26, 2011 at 08:40:22AM -0700, Jonathan Wilkes wrote:

...

...

so if you want your patches to be included into Pd proper, then they must (legally) be BSD3.

The main restriction here is that you cannot take or revise someone else's code that is licensed under the GPL and decide to _change_ the license to something else.  The GPL does not allow that.

Unless you are the copyright holder, you can't *change* the license of BSD3 code, either.

That's a misconception stemming from the concept of effective license of a combination of pieces : if half of the software is under BSD3 and half of the software is under GPL3, then complying with GPL3 will automatically make you BSD3-compliant as well. However, you can still take the BSD3 part of it and combine it with proprietary code and ship as a tamper-protected EXE if you like, as long as no GPL code remains, because the BSD3 code hasn't magically changed license by its contact with GPL code.

It might also have to do with propaganda about some licenses being « viral » in non-defined terms, leading people to dream awake about fictional laws that would allow a license-switch that hasn't been formally approved by all the copyright holders.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Marvin Humphrey marvin@rectangular.com; "pd-list@iem.at" pd-list@iem.at Sent: Monday, September 26, 2011 10:49 AM Subject: pd forks WAS : [PD] Keyboard shortcuts for "nudge", "done editing"

[...]

To be fair, after that tooltips patch was submitted, Miller expressed his problem with how the patch was implemented.  No one ever bothered to follow up on that, so yes, that patch made no progress.

To be fair, the submitter of the patchasked for clarification on Miller's ambiguous expression of his problem, and IOhannesrepeated the question four months later.  The last response before closing the patch comes five years later before the patch is closed.

The patch was also refactored and submitted again, which I noticed and refactored it yet again, doing most of the changes on the tcl end and making the tip content generate automatically so that all internal objects and most externals give useful feedback without anyone having to make any further changes or even do any work.

So I don't know, maybe this development process works, and by the time the next tooltips patch rolls around you'll be able to check your email within the tip, and build patches inside the tip with infinite undo/redo, as well as initbang/closebang within the tip.

-Jonathan

On Sep 27, 2011, at 11:34 AM, Mathieu Bouchard wrote:

Le 2011-09-25 à 22:59:00, Jonathan Wilkes a écrit :

...

It's been forked-- four times (AFAIK). Nova, DesireData, Pd- extended, and Pd-l2ork. Two of those forks-- Nova and DesireData--
had explicitly stated goals which basically boiled down to being
more responsive to the Pd community (in addition to many other
things).

Have you ever looked at Nova ?

It's never been a branch of Pd in any sense, and it's never been
compatible with Pd except in very superficial ways : even MAX is
more Pd-like than Nova.

...

The three clauses of the BSD license used by Pd Vanilla are
compatible with both the GPL v2 & v3

Integrating GPL code with BSD code makes GPL the overall dominant
license, as in it has all the clauses of BSD and makes the most
restrictions. The BSD license still applies to any portions still
under BSD license.

The pdextended license (GPL) doesn't say to which parts of the
programme it applies, and all the copyright/license notices I can
find (in a bêta of 42) are all BSD. Changes & additions to BSD code
don't have to be under the BSD license, thus if it's not stated,
it's somewhat harder to make any assumptions...

That kind of license fuzz is tolerated because pd developers have no
expectation that lawyers ever have to put their nose in the
project... and even if they did, they would not have the background
to know how to fix it, or know which advice they can trust. I think
that this is true of many (if not most) open/free projects.

Pd-extended as a whole is under the GPLv3, that's the easiest way to
think about it. Some sections of it are under the BSD License, some
under the Tcl License (which Pd was originally), some under GPLv2, etc.

My personal thoughts on the license of what is in pd-extended.git are
more vague. Yes, the intention is for much/most of that code to
contributed back to Pd, but my only distribution of the whole thing is
part of the Pd-extended package, which is GPLv3. So if you want to be
sure, consider it GPLv3.

.hc

News is what people want to keep hidden and everything else is
publicity. - Bill Moyers

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, September 27, 2011 12:14 PM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

On Sep 27, 2011, at 11:34 AM, Mathieu Bouchard wrote:

...

Le 2011-09-25 à 22:59:00, Jonathan Wilkes a écrit :

...

It's been forked-- four times (AFAIK).  Nova, DesireData,

Pd-extended, and Pd-l2ork.  Two of those forks-- Nova and DesireData-- had explicitly stated goals which basically boiled down to being more responsive to the Pd community (in addition to many other things).

...

Have you ever looked at Nova ?

It's never been a branch of Pd in any sense, and it's never been

compatible with Pd except in very superficial ways : even MAX is more Pd-like than Nova.

...

...

The three clauses of the BSD license used by Pd Vanilla are compatible

with both

...

...

the GPL v2 & v3

Integrating GPL code with BSD code makes GPL the overall dominant license,

as in it has all the clauses of BSD and makes the most restrictions. The BSD license still applies to any portions still under BSD license.

...

The pdextended license (GPL) doesn't say to which parts of the

programme it applies, and all the copyright/license notices I can find (in a bêta of 42) are all BSD. Changes & additions to BSD code don't have to be under the BSD license, thus if it's not stated, it's somewhat harder to make any assumptions...

...

That kind of license fuzz is tolerated because pd developers have no

expectation that lawyers ever have to put their nose in the project... and even if they did, they would not have the background to know how to fix it, or know which advice they can trust. I think that this is true of many (if not most) open/free projects.

Pd-extended as a whole is under the GPLv3, that's the easiest way to think about it.  Some sections of it are under the BSD License, some under the Tcl License (which Pd was originally), some under GPLv2, etc.

I guess by "Pd-extended as a whole" you are including externals (since you mention the Tcl license, which I only ever saw in an external library).  In that case, add LGPL to the list (iemlib if I'm remembering correctly).

-Jonathan

My personal thoughts on the license of what is in pd-extended.git are more vague.  Yes, the intention is for much/most of that code to contributed back to Pd, but my only distribution of the whole thing is part of the Pd-extended package, which is GPLv3.  So if you want to be sure, consider it GPLv3.

.hc

---

News is what people want to keep hidden and everything else is publicity.          - Bill Moyers

On Sep 27, 2011, at 1:50 PM, Mathieu Bouchard wrote:

Le 2011-09-27 à 10:45:00, Jonathan Wilkes a écrit :

...

I guess by "Pd-extended as a whole" you are including externals
(since you mention the Tcl license, which I only ever saw in an
external library). In that case, add LGPL to the list (iemlib if
I'm remembering correctly).

Hans can't possibly relicense externals either. Which part of
Pdextended is « Pdextended as a whole » ? That is, under which
circumstances can the GPLv3 license ever apply to whatever in
pdextended, and not just the license of each specific piece of
source code in there ?

No one is talking about relicensing. BSD, MIT, Tcl, LGPL, etc. are
compatible with GPLv3, that means you can include code with those
licenses into a GPLv3 project and that is allowed. Then the whole
project is GPLv3.

If you are only worried about snippets of code, then you only have to
worry about what the copyright and license of the code you take.

.hc

"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.

On Sep 27, 2011, at 4:53 PM, Mathieu Bouchard wrote:

Le 2011-09-27 à 16:41:00, Hans-Christoph Steiner a écrit :

...

No one is talking about relicensing. BSD, MIT, Tcl, LGPL, etc. are
compatible with GPLv3, that means you can include code with those
licenses into a GPLv3 project and that is allowed. Then the whole
project is GPLv3.

You mean that the whole project is GPLv3-compatible, or that it is
GPLv3 ?

If it is the latter, then when do the GPLv3's obligations ever apply
to me when I do whatever with Pd-extended ?

I think you need to read up on how licenses work, its a bit off topic
here. But yes, Pd-extended is GPLv3 as a whole.

.hc

Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith

On Tue, Sep 27, 2011 at 12:14:00PM -0400, Hans-Christoph Steiner wrote:

Pd-extended as a whole is under the GPLv3, that's the easiest way to
think about it. Some sections of it are under the BSD License, some
under the Tcl License (which Pd was originally), some under GPLv2, etc.

My personal thoughts on the license of what is in pd-extended.git are
more vague. Yes, the intention is for much/most of that code to
contributed back to Pd, but my only distribution of the whole thing is
part of the Pd-extended package, which is GPLv3. So if you want to be
sure, consider it GPLv3.

OK, then:

Since "Pd-extended as a whole is under the GPLv3", if I ever supply a patch against Pd-extended.git, I must assume that the GPLv3 applies to it if I "want to be sure".

It sounds as though if I want to avoid producing GPLv3 code, I need to steer a wide berth around Pd-extended.

Also, it sounds as though "if you want to be sure", no code which was ever derived from Pd-extended can ever be merged upstream into Vanilla without violating the GPL.

If I can't "be sure" that other Pd contributors won't claim that the GPL applies to contributions I'm making that are intended for the Vanilla's BSD core, that makes it a lot less attractive to contribute to this project.

Marvin Humphrey

On Sep 28, 2011, at 8:12 AM, Simon Wise wrote:

On 28/09/11 19:31, Marvin Humphrey wrote:

...

On Tue, Sep 27, 2011 at 12:14:00PM -0400, Hans-Christoph Steiner
wrote:

...

Pd-extended as a whole is under the GPLv3, that's the easiest way to think about it. Some sections of it are under the BSD License, some under the Tcl License (which Pd was originally), some under GPLv2,
etc.

My personal thoughts on the license of what is in pd-extended.git
are more vague. Yes, the intention is for much/most of that code to contributed back to Pd, but my only distribution of the whole
thing is part of the Pd-extended package, which is GPLv3. So if you want
to be sure, consider it GPLv3.

OK, then:

Since "Pd-extended as a whole is under the GPLv3", if I ever supply
a patch against Pd-extended.git, I must assume that the GPLv3 applies to it
if I "want to be sure".

... unless it is to one of the many files that are licensed with the
BSD style pd-vanilla license, or unless you are adding new files -
where you could of course license then as you please, as long as
that license allows it to be distributed along with the other stuff
in the usual pd extended manner. As matju noted there are lots of
suitable areas to contribute to if you wish to avoid the GPL,
including most of the parts which are extensions of the vanilla
codebase.

...

It sounds as though if I want to avoid producing GPLv3 code, I need
to steer a wide berth around Pd-extended.

or rather if you wish to avoid GPL you should avoid the libraries
and other stuff licensed with GPL, and you can't be sure they are
not GPL without looking at the license notices on the files yourself.

...

Also, it sounds as though "if you want to be sure", no code which
was ever derived from Pd-extended can ever be merged upstream into Vanilla
without violating the GPL.

... only code from those parts that are GPL licensed, and this is
presumably the desire of the authors of those parts ... though of
course anything written by a single person, or a small group, could
of course be offered (by the authors only) as a patch under the
usual vanilla license if they wished. I think this has happened from
time to time, nothing stops an author distributing their own work
under several different licenses, depending on the context.

...

If I can't "be sure" that other Pd contributors won't claim that
the GPL applies to contributions I'm making that are intended for the
Vanilla's BSD core, that makes it a lot less attractive to contribute to this
project.

By "if you want to be sure" I read ... the contents of pd-extended
is believed by those distributing it to be compatible with GPL3, so
they say you can use it in any context that GPL3 is usable, provided
you comply with the conditions of the license - including of course
all the attribution requirements.

Many parts are more widely usable than the GPL allows, but you would
need to check the license for that part before doing so ... the only
thing that the distribution claims is that its contents are all
compatible with GPL3.

I think a library was dropped recently because the license was too
restrictive for GPL3.

Well said. The library in question is pidip, it had an additional
clause about no military or repressive use, which is not GPL
compatible, but is BSD compatible.

.hc

Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith

On Sep 28, 2011, at 11:16 AM, Mathieu Bouchard wrote:

Le 2011-09-28 à 20:12:00, Simon Wise a écrit :

...

Many parts are more widely usable than the GPL allows, but you
would need to check the license for that part before doing so ...
the only thing that the distribution claims is that its contents
are all compatible with GPL3.

I just downloaded Pd 0.42.5-extended binary for Ubuntu 10.10 and
clicked about Pd. It says :

« Pd is copyrighted but is free for you to use for any reasonable
purpose under the GNU GPL version 3 . Follow the link for more
details about the license: »

and then when clicking, it says « Parts of this package can be used
under Pd’s BSD license » at the top, not saying which part. Clicking
on that link you get :

« This software is copyrighted by Miller Puckette and others. The
following terms (the "Standard Improved BSD License") apply to all
files associated with the software unless explicitly disclaimed in
individual files: »

So, it does not acknowledge of any BSD code that isn't copyrighted
by Miller, while not saying right away that Miller is the guy who
holds the copyright to the core (not counting expr~), and it's
confusing people by claiming GPL3 status in a way that would make
people believe that the core part is GPL3 too.

If you read the terms of the other licenses, you will see that Pd- extended is complying with them. Their license files are intact and
included. If not, its a bug, and that should be added to the bug
tracker. For example, the New BSD license does not require that I
post that license info everywhere (the original one did).

.hc

...

I think a library was dropped recently because the license was too
restrictive for GPL3.

Stating what the licensing goals are, is different from stating
which license(s) are in used, in which parts of Pd-extended.

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal,
QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

Le 2011-09-28 à 11:12:00, Jonathan Wilkes a écrit :

Is there a precedent for the phrase "Standard Improved BSD License" for the three-clause BSD?

It seems to be a puckettism that propagated throughout the pd world, including my references to «SIBSD» some years ago.

If not, this needs to be changed to "3-clause BSD License" since there are at least three different licenses BSD could refer to (and 2 of them could be standard and improved...)

gnu.org has different terminology : http://www.gnu.org/philosophy/bsd.html

but it seems to be dating back to when Stallman invented the 3-clause BSD (1996-1999).

I know nothing about the history of the 2-clause BSD... I didn't pay attention to its appearance.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

On Sep 28, 2011, at 7:31 AM, Marvin Humphrey wrote:

On Tue, Sep 27, 2011 at 12:14:00PM -0400, Hans-Christoph Steiner
wrote:

...

Pd-extended as a whole is under the GPLv3, that's the easiest way to think about it. Some sections of it are under the BSD License, some under the Tcl License (which Pd was originally), some under GPLv2,
etc.

My personal thoughts on the license of what is in pd-extended.git are more vague. Yes, the intention is for much/most of that code to contributed back to Pd, but my only distribution of the whole thing
is part of the Pd-extended package, which is GPLv3. So if you want to
be sure, consider it GPLv3.

OK, then:

Since "Pd-extended as a whole is under the GPLv3", if I ever supply
a patch against Pd-extended.git, I must assume that the GPLv3 applies to it
if I "want to be sure".

It sounds as though if I want to avoid producing GPLv3 code, I need
to steer a wide berth around Pd-extended.

Also, it sounds as though "if you want to be sure", no code which
was ever derived from Pd-extended can ever be merged upstream into Vanilla
without violating the GPL.

If I can't "be sure" that other Pd contributors won't claim that the
GPL applies to contributions I'm making that are intended for the
Vanilla's BSD core, that makes it a lot less attractive to contribute to this
project.

Marvin Humphrey

I think you are misunderstanding what Pd-extended is. It is a
collection of many subprojects (libraries, docs, etc.), each with
their own authors and licenses. As a collection, it is GPLv3, but
there are many subsections that are licensed BSD, MIT, Tcl, etc. A Pd
library that is licensed BSD and included in Pd-extended is still
available for use under the BSD. You could use it with Pd vanilla,
for example, and everything would be BSD.

Basically, if you avoid contributing to stuff that's included in Pd- extended, that would mean you would avoid contributing to most of
what's used in the Pd world, since Pd-extended distributes it.

.hc

I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.

On Sep 28, 2011, at 10:41 AM, Mathieu Bouchard wrote:

Le 2011-09-28 à 04:31:00, Marvin Humphrey a écrit :

...

If I can't "be sure" that other Pd contributors won't claim that
the GPL applies to contributions I'm making that are intended for
the Vanilla's BSD core, that makes it a lot less attractive to
contribute to this project.

Hey Martin,

As the maintainer and main author of the pd-extended.git, I will you
give you my assurance that the code under pd-extended.git is under a
BSD license. That repo is a fork of the pure-data.git repo of Miller,
it is largely intended as way to develop and feed patches to the
upstream pure-data.git, and as Matju pointed out, the only license
statement in pd-extended.git is Miller's BSD one from pure-data git.

That said, building the actual Pd-extended package uses stuff that is
outside that repo which is definitely GPL. That's the stuff in the
pure-data SVN.

.hc

"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds

On Sep 28, 2011, at 11:08 AM, Mathieu Bouchard wrote:

Le 2011-09-28 à 11:00:00, Hans-Christoph Steiner a écrit :

...

As the maintainer and main author of the pd-extended.git, I will
you give you my assurance that the code under pd-extended.git is
under a BSD license. That repo is a fork of the pure-data.git repo
of Miller, it is largely intended as way to develop and feed
patches to the upstream pure-data.git, and as Matju pointed out,
the only license statement in pd-extended.git is Miller's BSD one
from pure-data git.

That said, building the actual Pd-extended package uses stuff that
is outside that repo which is definitely GPL. That's the stuff in
the pure-data SVN.

Even though from the standpoint of using Pd as one indiscriminate
whole, you can think of it as GPL because that's the «strongest»
license being used, the BSD portions are so large in size that it's
misleading to say that GPL is the license of Pd. That's because it's
very possible to pick the parts of Pd you want to use so that you
only use BSD code, and because the core of the software is under BSD
license.

Yes, it would be misleading to say Pd is under the GPL. I haven't
heard anyone say that. Pd-extended is under the GPL tho.

.hc

"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.

On Sep 28, 2011, at 1:35 PM, Mathieu Bouchard wrote:

Le 2011-09-28 à 11:31:00, Hans-Christoph Steiner a écrit :

...

Yes, it would be misleading to say Pd is under the GPL. I haven't
heard anyone say that. Pd-extended is under the GPL tho.

Sorry. I meant that it's misleading to say that Pd-extended is under
the GPL.

It would be misleading for me to say that it was released under
anything but the GPLv3. If you respect the GPLv3, you are free to do
anything you want with anything in Pd-extended. Not so with other
licenses.

If you think its important to have a catalog of which Pd-extended code
is under which license, please make such a catalog.

.hc

Mistrust authority - promote decentralization. - the hacker ethic

On Sep 28, 2011, at 2:39 PM, Jonathan Wilkes wrote:

----- Original Message -----

...

From: Hans-Christoph Steiner hans@at.or.at To: Mathieu Bouchard matju@artengine.ca Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, September 28, 2011 1:48 PM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

On Sep 28, 2011, at 1:35 PM, Mathieu Bouchard wrote:

...

Le 2011-09-28 à 11:31:00, Hans-Christoph Steiner a écrit :

...

Yes, it would be misleading to say Pd is under the GPL. I haven't

heard anyone say that. Pd-extended is under the GPL tho.

...

Sorry. I meant that it's misleading to say that Pd-extended is under

the GPL.

It would be misleading for me to say that it was released under
anything but the GPLv3. If you respect the GPLv3, you are free to do anything you
want with anything in Pd-extended. Not so with other licenses.

If you think its important to have a catalog of which Pd-extended
code is under which license, please make such a catalog.

Already is-- see [pd META] subpatches and LIBRARY-meta.pd

(Though not complete yet.)

Yeah, those meta files will make the catalog much easier to do, they
could be automatically parsed to generate a catalog to post online, or
wherever.

.hc

                                           http://at.or.at/hans/

On Sep 29, 2011, at 12:38 AM, Marvin Humphrey wrote:

On Wed, Sep 28, 2011 at 11:00:21AM -0400, Hans-Christoph Steiner
wrote:

...

As the maintainer and main author of the pd-extended.git, I will you give you my assurance that the code under pd-extended.git is under
a BSD license. That repo is a fork of the pure-data.git repo of Miller,
it is largely intended as way to develop and feed patches to the upstream pure-data.git, and as Matju pointed out, the only license statement
in pd-extended.git is Miller's BSD one from pure-data git.

Thanks, Hans. Given your constraints, I can't think of a way to
improve upon this setup.

It seems wise that you keep the satellite libraries in a seperate
repository from the core -- that makes it more difficult for code to wander
where it shouldn't or for tight bonds to form.

Of course it would be ideal if there was only one core repository,
not the least because it seems like a lot of work for you to maintain the
fork in the manner that you do -- but it is apparent why that is not feasible.

License proliferation is a costly problem, both in the open source
world at large and within the microcosm of this one project.

In my opinion, using GPLv3 has been the easiest of the options. It
means that we can use code that is licensed with a BSD, MIT, Tcl,
Apache, GPLv2, LGPL, GPLv3, etc.. So its the most compatible to the
code that's out there, meaning thinking about licenses less writing
more code that everyone is free to use :)

.hc

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams

Le 2011-09-28 à 21:44:00, Marvin Humphrey a écrit :

On Thu, Sep 29, 2011 at 12:44:39AM -0400, Hans-Christoph Steiner wrote:

...

In my opinion, using GPLv3 has been the easiest of the options. It means that we can use code that is licensed with a BSD, MIT, Tcl, Apache, GPLv2, LGPL, GPLv3, etc.. So its the most compatible to the code that's out there, meaning thinking about licenses less writing more code that everyone is free to use :)

All I'm gonna say is that I see things from a different angle. :)

I have no idea what the angle is and how that licensing of «overall project» is supposed to work.

I'm lost.

Besides, I just realised that [pd META] says things like «LICENSE GPL v2» or «LICENSE GPL v3» but never «LICENSE GPL v2 OR LATER». Isn't that strange ?

The distinction has to be made between «version 2 only» and «version 2 or later» and between «version 3 only» and «version 3 and later» (even when, in that latter case, there is currently no version after 3).

BTW, there are even cases where it just says GPL without version number.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

On Thu, 2011-10-06 at 15:46 -0700, Jonathan Wilkes wrote:

----- Original Message -----

...

From: Mathieu Bouchard matju@artengine.ca To: Marvin Humphrey marvin@rectangular.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, October 6, 2011 5:44 PM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

Le 2011-09-28 à 21:44:00, Marvin Humphrey a écrit :

...

On Thu, Sep 29, 2011 at 12:44:39AM -0400, Hans-Christoph Steiner wrote:

...

In my opinion, using GPLv3 has been the easiest of the options. It means that we can use code that is licensed with a BSD, MIT, Tcl, Apache, GPLv2, LGPL, GPLv3, etc.. So its the most compatible to the code that's out there, meaning thinking about licenses less writing

more

...

...

code that everyone is free to use :)

All I'm gonna say is that I see things from a different angle. :)

I have no idea what the angle is and how that licensing of «overall project» is supposed to work.

I'm lost.

Besides, I just realised that [pd META] says things like «LICENSE GPL v2» or «LICENSE GPL v3» but never «LICENSE GPL v2 OR LATER». Isn't that strange ?

GPL v2 - LICENSE.txt is the GPL v2 GPL v3 - LICENSE.txt is the GPL v3

Then there are cases like pdogg, where LICENSE.txt is GPL v2 but in README.txt the author writes that the license is LGPL.

...

The distinction has to be made between «version 2 only» and «version 2 or later» and between «version 3 only» and «version 3 and later» (even when, in that latter case, there is currently no version after 3).

How do I figure this out from the files inside a given libdir?

...

BTW, there are even cases where it just says GPL without version number.

I believe those cases are where the only info I had was a statement in a README or somewhere that said "This software is released under the GPL".

The GPL includes the "or any later version" by default, but some people remove that part. The Linux kernel is a notable exception, I believe it says "GPLv2 only". We could adopt the Debian notation for this:

GPLv2+ standard GPL v2 or later GPLv2 standard GPL v2 only etc.

.hc

Le 2011-10-06 à 15:46:00, Jonathan Wilkes a écrit :

Then there are cases like pdogg, where LICENSE.txt is GPL v2 but in README.txt the author writes that the license is LGPL.

Ok, this would be plain wrong, if it were the case. Then the author would have to be contacted, in order to make things clear.

However :

head -1 externals/pdogg/LICENSE.txt

gives :

GNU LIBRARY GENERAL PUBLIC LICENSE

which means LGPL.

...

The distinction has to be made between «version 2 only» and «version 2 or later» and between «version 3 only» and «version 3 and later» (even when, in that latter case, there is currently no version after 3).

How do I figure this out from the files inside a given libdir?

You can't. If it can make a difference for the Pd community, then the authors of those files have to be contacted so that they rerelease the same things with a more precise statement of license than just putting a LICENSE.txt file there.

...

BTW, there are even cases where it just says GPL without version number.

I believe those cases are where the only info I had was a statement in a README or somewhere that said "This software is released under the GPL".

Yeah. That's also the best you could do with the info that you didn't have, but it still means that the info is incomplete.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2011-10-06 à 16:45:00, Jonathan Wilkes a écrit :

Ok, I got confused with "Library" vs. "Lesser"

LGPL v2 = GNU Library GPL LGPL v2.1 = GNU Lesser GPL LGPL v3.0 = most recent GNU Lesser GPL

Is that unambiguous?

yes, of course. (except for the possible « or later »).

Ok, I'll see what I can do.

[...]

Ok.

Btw I exchanged a few emails with Richard Stallman on the topic, but I didn't do it as fast as I could, esp as I didn't get the replies I wanted on pd-list. The main question was whether there was any canonical meaning to saying « pd as a whole is under the GPL3 » and it immediately went into the fact that several bundled things have unclear licenses and how bad it is.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2011-10-11 à 11:37:00, Hans-Christoph Steiner a écrit :

I work to make sure that everything in Pd-extended is GPLv3 compatible.

[...]

Everything in Pd-extended is GPLv3,

I think that it's better to remain picky in the manner of saying things like that, and not confuse GPLv3 and GPLv3-compatible. You could be saying something like « All licenses of all parts of Pd-extended are GPLv3-compatible and it will remain like that ».

This causes less confusion than claiming things about a whole when people don't know what the whole is supposed to mean.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Marvin Humphrey marvin@rectangular.com; "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, October 11, 2011 11:18 AM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

Le 2011-10-06 à 16:45:00, Jonathan Wilkes a écrit :

...

Ok, I got confused with "Library" vs. "Lesser"

LGPL v2 = GNU Library GPL LGPL v2.1 = GNU Lesser GPL LGPL v3.0 = most recent GNU Lesser GPL

Is that unambiguous?

yes, of course. (except for the possible « or later »).

...

Ok, I'll see what I can do.

[...]

...

Ok.

Btw I exchanged a few emails with Richard Stallman on the topic, but I didn't do it as fast as I could, esp as I didn't get the replies I wanted on pd-list.

Is there a need for speed?

The main question was whether there was any canonical meaning to saying « pd as a whole is under the GPL3 » and it immediately went into the fact that several bundled things have unclear licenses and how bad it is.

Try emailing info@fsf.org, I'm sure they can provide some answers.  They'll have more resources-- than a Yeeloong :)

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Marvin Humphrey marvin@rectangular.com; "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, October 12, 2011 1:19 PM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

Le 2011-10-11 à 21:43:00, Jonathan Wilkes a écrit :

...

...

From: Mathieu Bouchard matju@artengine.ca Btw I exchanged a few emails with Richard Stallman on the topic, but I

didn't do it as fast as I could, esp as I didn't get the replies I wanted on pd-list.

...

Is there a need for speed?

Well, I can also do like I don't like to do but I do anyway, which is to wait a few weeks before taking care of email. It always make it look like I'm very serious and interested in the conversation, of course.

...

They'll have more resources-- than a Yeeloong :)

I have no idea what that means.

That means they have a staff of people with various specialties and can pass your email along to the person(s) that can best answer your question, as opposed to one unpaid guy who is probably insanely busy with touring the world giving lectures about free software.

The last I heard Stallman was using a Lemote Yeeloong which is supposedly the first laptop to run using only free software.  However, it's more like a netbook in that it has rather limited cpu resources and is short on memory, hence my joke.

-Jonathan

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2011-09-27 à 21:49:00, Marvin Humphrey a écrit :

On Tue, Sep 27, 2011 at 11:34:43AM -0400, Mathieu Bouchard wrote:

...

The pdextended license (GPL) doesn't say to which parts of the programme it applies, and all the copyright/license notices I can find (in a bêta of 42) are all BSD. Changes & additions to BSD code don't have to be under the BSD license, thus if it's not stated, it's somewhat harder to make any assumptions...

According to "Intellectual Property and Open Source" by Van Lindberg[1] (which I highly recommend), a patch which is offered up on a mailing list or through a patch tracker comes with an implicit grant of license to use it in the project, […]

I understand that if a diff looks like it's not under a different license, it will be taken as being under the same license, regardless of intention... my concern wasn't about who would win in court, but rather about the existence of confusion and disagreements. Keep in mind that I was speculating about what might make Hans claim GPLv3 status while no code bears the notice.

While copyright violations do not result in injunctions unless a litigant appears, I do not believe it is in the interest of any project to neglect the law.

My statement was not an endorsement of negligence...

...

I think that this is true of many (if not most) open/free projects.

I'm not comfortable with that generalization.

Oh, I'm not talking about the ones we're most likely to encounter, that is, the big ones. Most projects are small, and in smaller projects, it's more likely that people don't spend much time challenging their own assumptions about how licenses work. I'm also not endorsing that behaviour...

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

On Mon, Sep 26, 2011 at 11:26:27AM -0400, Hans-Christoph Steiner wrote:

Check out the GUI plugins, they could be a fun way for you to learn Tcl.

Yes, this is actually one of my motivations. :) I went through some of the Pd tutorials a couple years ago, and have meant to get back into it for a while. Then recently, I gained a professional reason to learn Tcl, and it's provided me with an excuse to dive into the Pd source code. :)

You can customize a lot of the way the GUI works using them. Key
bindings are easy. You could check out the completion-plugin to see how it does the Enter key binding, and then just use that to bind to Esc.

http://puredata.info/docs/guiplugins/

http://download.puredata.info/completion-plugin

Unfortunately, this plugin is GPL'd. I cannot create a derivative work from it to supply to Vanilla.

Marvin Humphrey

On Mon, Sep 26, 2011 at 08:29:45PM -0400, Hans-Christoph Steiner wrote:

Wow, that's interesting. I don't often hear that, people using Tcl in
their work.

I write open source code for a living -- Eventful sponsors my work on the Apache Lucy search engine library, and that's where about 75% of my hours go. A volunteer showed up a little while ago who wants to add Tcl bindings for Lucy. I'm teaching myself Tcl so that I can work with this volunteer more effectively.

Sure you can, its a .tcl script, meaning you are giving the user the
source whenever you are giving the user the program. So its even kind
of BSD-ish because you can't give the user a GUI plugin without giving
them the source, so you don't need to do anything else to distribute the source. Pd patches are the same idea.

I am sincerely grateful for the pointer to this plugin and for your generosity with your time and support, but I assume that a miscommunication has occurred and I am not understanding your suggestion properly. I cannot take code from this plugin, make changes to adapt it for Vanilla, remove the GPL tag and replace it with an implicit BSD license by submitting it to the patch tracker. That would not adhere to the original author's license, and it would be a violation of copyright.

If I wish to supply the proposed functionality for Vanilla my options are either to create a new patch from scratch which cannot be considered a "derivative work" of that plugin, or to track down all the original authors of that plugin, persuade them to issue their code under an additional BSD3 license, and then once that process is complete, create a derivative work and submit it.

Best,

Marvin Humphrey

On Sep 26, 2011, at 9:02 PM, Marvin Humphrey wrote:

On Mon, Sep 26, 2011 at 08:29:45PM -0400, Hans-Christoph Steiner
wrote:

...

Wow, that's interesting. I don't often hear that, people using Tcl
in their work.

I write open source code for a living -- Eventful sponsors my work
on the Apache Lucy search engine library, and that's where about 75% of my
hours go. A volunteer showed up a little while ago who wants to add Tcl
bindings for Lucy. I'm teaching myself Tcl so that I can work with this
volunteer more effectively.

Ah, nice deal. I wish Pd paid my bills, but I do spend most of my
paid dev time on free software as part of http://guardianproject.info

Perhaps you might also be interested in making a Pd library for using
Apache Lucy. :)

...

Sure you can, its a .tcl script, meaning you are giving the user the source whenever you are giving the user the program. So its even
kind of BSD-ish because you can't give the user a GUI plugin without
giving them the source, so you don't need to do anything else to
distribute the source. Pd patches are the same idea.

I am sincerely grateful for the pointer to this plugin and for your
generosity with your time and support, but I assume that a miscommunication has
occurred and I am not understanding your suggestion properly. I cannot take
code from this plugin, make changes to adapt it for Vanilla, remove the GPL
tag and replace it with an implicit BSD license by submitting it to the
patch tracker. That would not adhere to the original author's license, and it would
be a violation of copyright.

If I wish to supply the proposed functionality for Vanilla my
options are either to create a new patch from scratch which cannot be considered a "derivative work" of that plugin, or to track down all the original
authors of that plugin, persuade them to issue their code under an additional
BSD3 license, and then once that process is complete, create a derivative
work and submit it.

Ah yes, that is true. Sorry, I forgot and thought you wanted to
distribute a plugin.

.hc

'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf

Le 2011-09-25 à 21:54:00, Marvin Humphrey a écrit :

A patch which has consensus support from the community probably has a better chance at being applied, even under BDFL governance. :)

That's merely a rule of thumb for the average project... it's better to know a bit about Miller than use a rule of thumb.

But consensus can be costly to achieve depending on the project's culture...

Consensus can also be irrelevant, depending on the project's culture.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2011-09-25 à 16:19:00, Marvin Humphrey a écrit :

Thanks, but if I become a serious user, I hope to make substantial contributions to Pd at some point, and for various reasons my preference is to contribute to a BSD-licensed project over one that is licensed under the GPL.

I heard that it's GPL'd too, but I don't know what it applies to. Looking at a checkout of pdextended 42 (the last one in svn), nearly all license notices are BSD. The two exceptions are the notice in [expr~]'s source and about.pd.

In vanilla the only exception is [expr~].

Given that nearly all changes in pdextended are made with the intent of going to vanilla on vanilla's terms, and given that the license of existing code can't just be changed, I cannot really tell which part is covered by GPL3. What is said in about.pd is contradictory to the dozens of other notices.

I was under the impression that Pd-extended consisted of augmentations to Vanilla. Is it actually a fork?

How would you draw the line ? Everybody (and their cats) has their own idea of what the word «fork» ought to be used for. E.g. en.wikipedia says that a fork is the point at which a branch becomes two or more. Random slashdot dudes would say a fork is like a branch except done for... some kind of evil purposes... ;)

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2011-09-26 à 08:34:00, Richie Cyngler a écrit :

None of these combinations provide that behavior on Pd Vanilla built from latest git on OS X 10.6:

control-Enter    command-Enter    option-Enter    shift-Enter

I could live with control-Enter instead of <ESC> (especially since I've rewired my caps lock key to control at the OS level using the Keyboard system prefs) -- though <ESC> works so well for switching modes in Vim. :)

The only thing that has made sense to me is :

Enter for accepting changes made in a box's text and exit that mode ;

Escape for cancelling those changes and exit that mode too ;

Shift-Enter to insert a literal newline in a box's text (currently meaningless because they get replaced by Space by the loader/saver) ;

Those shortcuts don't necessarily apply to the main Edit Mode... I don't recall whether we bound Enter to « switch to text edition ». Escape has no effect in that context, because there's no modal dialogue-like thing to get out of. A text edition in progress is quite « modal » in that particular meaning of the word (but there are several things called «Modes»... e.g. Ctrl+e wouldn't be called « modal »).

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2011-09-27 à 21:35:00, Marvin Humphrey a écrit :

On Tue, Sep 27, 2011 at 01:59:20PM -0400, Mathieu Bouchard wrote:

...

Enter for accepting changes made in a box's text and exit that mode ;

[…]

However, it's also the most invasive modification. If anyone is accustomed to being able to produce a newline with Enter while editing text into Message or Comment boxes, they will have to change their habits.

There is nearly no habit of producing a newline inside of a box, because there is no way to save newlines in pd.

...

Escape for cancelling those changes and exit that mode too ;

Good idea -- that's consistent with Mac GUI design for closing dialog boxes without making changes. I like it!

Also compatible with DOS shortcuts (Any QuickBASIC or TurboPASCAL users ? ;)

Is that also consistent with the traditional behavior of Escape under Windows and X?

Yes... for most X toolkits, I think.

...

Shift-Enter to insert a literal newline in a box's text (currently meaningless because they get replaced by Space by the loader/saver) ;

Newlines seem to be normalized to Spaces for Pd Objects, but that doesn't seem to be the case for either Messages or Comments.

Try reloading your patch... or even Copy+Paste or Duplicate. Newlines get normalised to spaces all of the time, except pd enforces an optional newline after a semicolon. (that is, the newline is not necessary for correct pd syntax, but it gets printed in the box like that anyway... but only after a reload or equivalent).

Using Shift-Enter for newlines doesn't seem like a very intuitive design to me.

It's already used in Skype, but I'm pretty sure that I implemented it before I ever saw Skype, and I'm sure that I copied it from one or several other apps, but I don't remember which ones.

I suspect that a significant fraction of the people who want newlines will never discover the magic key combo.

Those who do discover it will also discover what the patch saver does to their newlines. But I planned this thing with a future patch saver in mind.

...

Those shortcuts don't necessarily apply to the main Edit Mode... I don't recall whether we bound Enter to « switch to text edition ».

Your English is 100x better than my French, but I assume that when you wrote "edition", you meant "editing"?

Perhaps, but I don't know the difference.

So, if I understand correctly, you are suggesting that these key bindings would only take effect while actively editing the text of an Object, Message, or Comment. If that's the case, +1 -- I agree.

Yes, that's it.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

On Wed, Sep 28, 2011 at 06:17:08PM +0800, Simon Wise wrote:

typing into a spreadsheet cell is somewhat analogous, and probably a fairly common activity ...

Nice connection!

generally <enter> saves and exits the cell, while to put a newline into a cell without leaving it is <ctrl><enter> ... not sure what the OSX equivalent is, maybe <cmd><enter>.

I just checked out the Google Docs spreadsheet behavior. I assume that it mimics the interfaces of other popular spreadsheet programs, though I don't know that for sure.

• <enter> and <shift><enter> both save and exit the cell.
• <control><enter> and <cmd><enter> both insert a newline.
• <esc> cancels the change and exists the cell.

I haven't seen anyone object to Matthieu's suggested behaviors for <enter> and <esc>, which are consistent with both behavior and general OS gui conventions, so I think we may have achieved consensus there.

What's left is the basically irrelevant issue of how to insert a newline that's going to be turned into a space later anyway. My inclination is to supply a patch which simply does not support the insertion of newlines. If that results in user confusion and support inquiries, a binding for <modifier><return> can be added later.

Marvin Humphrey

On Thu, Sep 29, 2011 at 10:37:45AM -0700, Jonathan Wilkes wrote:

Something I was thinking about for the future is a way to model keyboard input after the efficiency of 'vi' input.  When in "Edit mode" without yet editing the text of an object, one could use "h", "j", "k", and "l" to move the bounding box selection around in the patch.  Then bind "/" to duplicate ctrl-f, and you have a quick way to get around the entire patch without leaving home position.  (Maybe also bind "i" to enter text-editing mode, and "a" to enter text editing mode at the end of the object's text.) Then when in text editing mode or "Run mode", turn off these bindings.

The tricky part is figuring out the most efficient way to make/edit connections.  There is already "auto-connect" behavior for leftmost xlets-- there needs to be a way to make a new connection, remove a connection, move a connection, and possibly make many-to-many connections like [select 0 1 2 3 4] with each outlet going to a new message box.

DesireData has a way to edit connections with the keyboard but I found it takes too many keystrokes.

Perhaps some of those features could be accommodated by having configurable key bindings for the actions in question. You don't have to provide default bindings for all options, either -- just provide hooks, and let the user create key bindings for the actions they care about.

Ever used Logic Audio? I was quite fond of its key binding preferences system when I used it a decade ago.

...

What's left is the basically irrelevant issue of how to insert a newline that's going to be turned into a space later anyway.  My inclination is to supply a patch which simply does not support the insertion of newlines.  If that results in user confusion and support inquiries, a binding for <modifier><return> can be added later.

That will result in user confusion, because when a message box with semicolons gets instantiated it doesn't automatically get newlines added until you save the patch and reopen it, while object boxes add the newlines after instantiation.  Currently the discrepancy can be hidden by always adding the newlines yourself with enter.

Ah, I see.

Source text:

'eep; op; ork; ah-ah;'

Object after instantiation:

eep;
op;
ork;
ah-ah;

Message after instantiation:

eep; op; ork; ah-ah;

Message after close and reopen:

eep;
op;
ork;
ah-ah;

So people who know this and don't want to close-and-reopen require some way to enter newlines while editing text.

That seems like a bug worth fixing, but I don't feel strongly about <shift><enter> one way or another, and if it solves a problem people care about, fine by me.

Marvin Humphrey

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Marvin Humphrey marvin@rectangular.com; Simon Wise simonzwise@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Thursday, October 6, 2011 5:49 PM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"

Le 2011-09-29 à 10:37:00, Jonathan Wilkes a écrit :

...

Something I was thinking about for the future is a way to model keyboard

input

...

after the efficiency of 'vi' input.

The efficiency of vi input is only efficient to vi users.

Well, I like staying in home position as much as possible.  The bindings could be for arrows as well.

Other people want arrows because they're arrows.

Sure.

If not using arrows, then at least, people expect something where at least the up key is above the down key.

...

DesireData has a way to edit connections with the keyboard but I found it

takes too many

...

keystrokes.

Editing the key bindings is the easy part of it...

Right.  The part I'm talking about is this:

[route 0 1 2 3 4 5 6 7]

[s from_rejection_outlet]

How do I make a connection from [route]'s rejection outlet to [s]?  With the current DesireData keyboard system I select [route] and do <ctrl-tab>9 times, then <ctrl-down-array>, then <ctrl-tab> 2 times, then Enter.  Rather than physically clicking a key nine times, I'd like a way to specify the xlet number with the number keys, which could cut the number of keystrokes in half.  (That's what I'm talking about regarding vi efficiency, though it doesn't have to be the exact same key bindings.)

-Jonathan

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Hi Marvin,

It's not really a solution but I've got into the habit of quickly double tapping command-E to switch from edit mode and back again. That will instantiate the object.

Cheers, Joe

On 25 September 2011 19:26, Marvin Humphrey marvin@rectangular.com wrote:

On Sun, Sep 25, 2011 at 10:51:56AM -0700, Jonathan Wilkes wrote:

...

I'm using Pd-l2ork, and control-Enter toggles between creating the object and editing the text in the box.

I thought Pd-extended had this same key binding, but Pd as installed from the debian package in Wheezy does not.

None of these combinations provide that behavior on Pd Vanilla built from latest git on OS X 10.6:

control-Enter command-Enter option-Enter shift-Enter

I could live with control-Enter instead of <ESC> (especially since I've rewired my caps lock key to control at the OS level using the Keyboard system prefs) -- though <ESC> works so well for switching modes in Vim. :)

Marvin Humphrey

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list