Sven Van Caekenberghe wrote:
On 26 Aug 2014, at 11:50, [email protected] wrote:On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <[email protected]> wrote: On 26 Aug 2014, at 11:22, Esteban Lorenzano <[email protected]> wrote:On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <[email protected]> wrote: So the README now says... spec-framework and all its content is distributed under a dual-license: * MIT license when used as an external library. * GPL v3 license when shipped as part of a programming language or its Integrated development environment. ...and I have just had direct clarification from BenVR that this "prevents Spec to be integrated into Pharo under the MIT license." [1] @Esteban But again: if there is a conflict there are always two solutions, solve it or part ways. Saying the other party made me do it is the same as saying I am right and he is wrong (and this goes for both sides ;-) I am sorry to see Ben depart the community, and reconciliation is always preferred and hoped for, however pending that, the whole community should not be held hostage to a disagreement between two parties. Even though Ben is the major author of Spec, Spec was developed "for" Pharo, and this community have contributed their efforts testing it through its introduction, and building tools on top of it. Against the trust given in making Spec a core part of Pharo, its relicensing presents a threat to the community and the only pragmatic defensive response is to fork. Indeed, this is not even a case of "the other party made me do it". The fork actually occurred moment Spec's license changed from compatible to incompatible with Pharo. We are only cleaning up. This action should be swift and any alternate response should only proceed in parallel and in addition to this. Leaving the current situation as-is unbalances any other discussion. I am concerned that there has been conflict, but I am too remote to consider the details on either side. I see only the effect of Spec being forked away from the community and consider it inappropriate to put the community at risk. The concept of Spec being MIT licensed only as an "external" library for end-user applications is untenable, since there is really no distinction in Pharo. What would be the situation for Moose? Or Phratch? Or PhaROS? Or for my little application that has the the full IDE hidden but still installed for debugging? Effectively the license is GPL for any use by our community. Maybe we should start another thread about this. Because the basic question is not about a license or a name change but about how to work together and about control, specifically for parts and/or developers that are external. I know that this is a complex discussion, but if we in general have problems of working modular than we are in trouble, no ? Sven To better understand the current situation, I did some archeology... 15 Dec 2011 - http://ss3.gemstone.com/ss/Spec.html - MIT License 18 Mar 2013 - http://smalltalkhub.com/#!/~Pharo/Spec - MIT License 06 Jan 2014 - https://github.com/spec-framework/spec - changed to Creative Commons Public License Attribution-NonCommercial-ShareAlike [2] [3] 30 Apr 2014 - Pharo 3 released 10 Aug 2014 - BVR opens issue 13823 [4] for Spec update integration and submits slice [8]. 15 Aug 2014 - BVR closes issue 13823. 16 Aug 2014 - https://github.com/spec-framework/spec - changed to dual license * MIT license when used as an external library. * GPL v3 license when shipped as part of a programming language or its Integrated Development Environment. 18 Aug 2014 - BVR announces his departure to mail list . 18 Aug 2014 - BVR deletes Spec Debugger and Spec Inspector from github repository The earlier license change to CCPL-A-NC-SA is a bit of a surprise, and concerning since this seems to have not been announced to the list, since surely I would have noticed some controversy here. However that is mostly dealt with by Ben committing to the Inbox as the major author implicitly relicensing his contributions under MIT. Presumably that was done in good faith up until the recent conflict, and it should be reasonable to retain Ben's submissions up to and including Slice 13823, and then go our separate ways with grace. However contributions by Camillo, Damien, Uko and webwarrior-ws [6] under an MIT license should be confirmed since their contributions under the CCPL-A-NC-SA cannot be arbitrarily relicensed by someone else's actions. Strangely though, it seems that Slice 13823 is missing from the Inbox. In considering how to manage the subsystem going forward. I don't think we can keep it as an external project called "Spec" - since that risks inadvertent GPL updates leaking into Pharo. I see only two choices: manage it internal to Pharo; or external with a different name. cheers -ben [1] https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f3974c69314b7f [2] https://github.com/spec-framework/spec/blob/8d8e85934188be486c9e91e5bff44670c451d00d/LICENSE [3] http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode [4] https://pharo.fogbugz.com/default.asp?13823 [5] https://pharo.fogbugz.com/default.asp?13824 [6] https://github.com/spec-framework/spec/graphs/contributors [7] http://www.catb.org/esr/writings/homesteading/homesteading/ar01s17.html [8] SmalltalkHub log extract... ---------------------------------------- BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 SLICE-Issue-13823-Spec-Update-BenjaminVanRyseghem.1 Issue 13823: Merge between Spec and Pharo BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Tools-BenjaminVanRyseghem.221 Merge with 40162 BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Tests-SvenVanCaekenberghe.39 12789 RPackage>>#moveClass:fromPackage:toTag: Ignores Tag https://pharo.fogbugz.com/f/cases/12789 12827 Part II : Compiling a method often makes nautilus deselect the package https://pharo.fogbugz.com/f/cases/12827 12522 Package filter input capture all keyboard shortcuts https://pharo.fogbugz.com/f/cases/12522 12812 Class comments missing in package Spec-Tools and Spec-Tests and BlocEditor should be renamed to BlockEditor https://pharo.fogbugz.com/f/cases/12812 BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-MorphicAdapters-BenjaminVanRyseghem.164 Merge with 40162 BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Layout-webwarrior.69 Fixed indentation in SpecTableLayoutAddWithSpec>>#subwidget:spec BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Inspector-BenjaminVanRyseghem.207 Merge with 40162 BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Examples-BenjaminVanRyseghem.78 Merge with 40162 BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Debugger-BenjaminVanRyseghem.225 Merge with 40162 BenjaminVanRyseghem committed to Pharo/Pharo40Inbox 10/08/2014 Spec-Core-BenjaminVanRyseghem.341 Merge with 40162 |
- Re: [Pharo-dev] Roadmap on... Luc Fabresse
- Re: [Pharo-dev] Roadmap on... [email protected]
- Re: [Pharo-dev] Roadmap on... Sven Van Caekenberghe
- Re: [Pharo-dev] Roadmap on... Esteban Lorenzano
- Re: [Pharo-dev] Roadmap on... Sven Van Caekenberghe
- Re: [Pharo-dev] Roadmap on... Esteban Lorenzano
- Re: [Pharo-dev] Roadmap on... [email protected]
- Re: [Pharo-dev] Roadmap on... Sven Van Caekenberghe
- Re: [Pharo-dev] Roadmap on... kilon alios
- Re: [Pharo-dev] Roadmap on... [email protected]
- [Pharo-dev] Spec future (w... Ben Coman
- Re: [Pharo-dev] Roadmap on... Esteban Lorenzano
- Re: [Pharo-dev] Roadmap on... Marcus Denker
- Re: [Pharo-dev] Roadmap on... Serge Stinckwich
- Re: [Pharo-dev] Roadmap on... Alain Rastoul
- Re: [Pharo-dev] Roadmap on tools? stepharo
- Re: [Pharo-dev] Roadmap on tools? Juraj Kubelka
- Re: [Pharo-dev] Roadmap on tools? Esteban Lorenzano
- Re: [Pharo-dev] Roadmap on tools? Esteban A. Maringolo
- Re: [Pharo-dev] Roadmap on tools? Nicolai Hess
