https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397... I think the license might need further improvements. I've taken a look at the commit history, and it looks to me like there is a licensing problem there. I am no lawyer, so don't know what the exact consequences of that are. The (MIT licensed) Pharo code was copied to the repository without including the copyright notice, as is required by the MIT license. For new contributions, you now have the license agreements, and with git it is perfectly clear what is new, and under the new license, and what is old, and can therefore also be used under the old license. And AFAIK MIT license is compatible with GPL. I have no clue as to the license status of changes between the copying and the relicensing. Of course copyright holding contributors can decide to relicense. The contributors to the Spec-* packages in the Pharo/Pharo30 repo seem to be: AlainPlantec AndreiChis BenComan BenjaminVanRyseghem BernardoContreras CamilloBruni CamilleTeruel ChristopheDemarey ClementBera DamienCassou ErwanDouaille EstebanLorenzano GabrielOmarCotelli GuillermoPolito HernanMoralesDurand IgorStasenko LeoGassman MarcusDenker MartinDias NicolaiHess PabloHerrero PavelKrivanek PhilippeBack RobertoMinelli SeanDeNigris SebastianTleye StephaneDucasse SvenVanCaekenberghe TorstenBergmann TudorGirba YuriyTymchuk Stephan
Does it really matter? If the external repository gets successfully relicensed, or Benjamin publishes new improvements as a separate, GPL-licensed change set, the end result is the same; no improvement he makes will make its way back into the versions in Core. I may not know his reasons, but I can certainly respect his wish that no further contributions are included in a core distribution. Whether to maintain/improve the current, MIT-licensed versions in Core without him, or unload it all and point potential users to the external library, is a separate decision. Though, from previous attempts, Iâd say the chances of success of an external UI-builder framework seeing actual use are rather slim. Cheers, Henry On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan@stack.nl> wrote:
https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397...
I think the license might need further improvements. I've taken a look at the commit history, and it looks to me like there is a licensing problem there. I am no lawyer, so don't know what the exact consequences of that are.
The (MIT licensed) Pharo code was copied to the repository without including the copyright notice, as is required by the MIT license.
For new contributions, you now have the license agreements, and with git it is perfectly clear what is new, and under the new license, and what is old, and can therefore also be used under the old license. And AFAIK MIT license is compatible with GPL.
I have no clue as to the license status of changes between the copying and the relicensing.
Of course copyright holding contributors can decide to relicense. The contributors to the Spec-* packages in the Pharo/Pharo30 repo seem to be:
AlainPlantec AndreiChis BenComan BenjaminVanRyseghem BernardoContreras CamilloBruni CamilleTeruel ChristopheDemarey ClementBera DamienCassou ErwanDouaille EstebanLorenzano GabrielOmarCotelli GuillermoPolito HernanMoralesDurand IgorStasenko LeoGassman MarcusDenker MartinDias NicolaiHess PabloHerrero PavelKrivanek PhilippeBack RobertoMinelli SeanDeNigris SebastianTleye StephaneDucasse SvenVanCaekenberghe TorstenBergmann TudorGirba YuriyTymchuk
Stephan
No, it doesn't. We can improve Spec in the core, why wouldn't we be able to? We use it in a lot of the tools, so, there are plenty of samples and documentation exists. One can make sense of what's going on under the hood. Have a look at: (this is for Pharo 3.0) SpecInterpreter>>interpretASpec:selector: and ComposableModel + NewValueHolder. WindowModel is interesting to look into as well. The "famous" NewValueHolder is of interest too. then implementors of defaultSpec provide a lot of specs to give to the SpecInterpreter. Then one wants to look into the Spec-MorphicAdapters to see how Spec maps its view on things with underlying Morphs (e.g. check the MorphicDiffAdapter). We can only benefit by caring about this piece on our side, as there is tremendous potential in being able to change the underlying system (e.g. from Morphic to Bloc for example) in a piecemeal way, without breaking all of the tools. Phil On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
Does it really matter? If the external repository gets successfully relicensed, or Benjamin publishes new improvements as a separate, GPL-licensed change set, the end result is the same; no improvement he makes will make its way back into the versions in Core.
I may not know his reasons, but I can certainly respect his wish that no further contributions are included in a core distribution.
Whether to maintain/improve the current, MIT-licensed versions in Core without him, or unload it all and point potential users to the external library, is a separate decision. Though, from previous attempts, Iâd say the chances of success of an external UI-builder framework seeing actual use are rather slim.
Cheers, Henry
On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan@stack.nl> wrote:
https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397...
I think the license might need further improvements. I've taken a look at the commit history, and it looks to me like there is a licensing problem there. I am no lawyer, so don't know what the exact consequences of that are.
The (MIT licensed) Pharo code was copied to the repository without including the copyright notice, as is required by the MIT license.
For new contributions, you now have the license agreements, and with git it is perfectly clear what is new, and under the new license, and what is old, and can therefore also be used under the old license. And AFAIK MIT license is compatible with GPL.
I have no clue as to the license status of changes between the copying and the relicensing.
Of course copyright holding contributors can decide to relicense. The contributors to the Spec-* packages in the Pharo/Pharo30 repo seem to be:
AlainPlantec AndreiChis BenComan BenjaminVanRyseghem BernardoContreras CamilloBruni CamilleTeruel ChristopheDemarey ClementBera DamienCassou ErwanDouaille EstebanLorenzano GabrielOmarCotelli GuillermoPolito HernanMoralesDurand IgorStasenko LeoGassman MarcusDenker MartinDias NicolaiHess PabloHerrero PavelKrivanek PhilippeBack RobertoMinelli SeanDeNigris SebastianTleye StephaneDucasse SvenVanCaekenberghe TorstenBergmann TudorGirba YuriyTymchuk
Stephan
Will there be any interest in alternative declarative framework, mostly fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et als in 3.0 http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-... I can push this in with the required MIT license sign off as reqd. More importantly, move this framework to a more refactored cleaner state if there is a slight interest in alternatives. On Thu, Aug 28, 2014 at 5:51 PM, phil@highoctane.be <phil@highoctane.be> wrote:
No, it doesn't.
We can improve Spec in the core, why wouldn't we be able to? We use it in a lot of the tools, so, there are plenty of samples and documentation exists.
One can make sense of what's going on under the hood.
Have a look at: (this is for Pharo 3.0)
SpecInterpreter>>interpretASpec:selector: and ComposableModel + NewValueHolder. WindowModel is interesting to look into as well.
The "famous" NewValueHolder is of interest too.
then implementors of defaultSpec provide a lot of specs to give to the SpecInterpreter.
Then one wants to look into the Spec-MorphicAdapters to see how Spec maps its view on things with underlying Morphs (e.g. check the MorphicDiffAdapter).
We can only benefit by caring about this piece on our side, as there is tremendous potential in being able to change the underlying system (e.g. from Morphic to Bloc for example) in a piecemeal way, without breaking all of the tools.
Phil
On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
Does it really matter? If the external repository gets successfully relicensed, or Benjamin publishes new improvements as a separate, GPL-licensed change set, the end result is the same; no improvement he makes will make its way back into the versions in Core.
I may not know his reasons, but I can certainly respect his wish that no further contributions are included in a core distribution.
Whether to maintain/improve the current, MIT-licensed versions in Core without him, or unload it all and point potential users to the external library, is a separate decision. Though, from previous attempts, Iâd say the chances of success of an external UI-builder framework seeing actual use are rather slim.
Cheers, Henry
On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan@stack.nl> wrote:
https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397...
I think the license might need further improvements. I've taken a look at the commit history, and it looks to me like there is a licensing problem there. I am no lawyer, so don't know what the exact consequences of that are.
The (MIT licensed) Pharo code was copied to the repository without including the copyright notice, as is required by the MIT license.
For new contributions, you now have the license agreements, and with git it is perfectly clear what is new, and under the new license, and what is old, and can therefore also be used under the old license. And AFAIK MIT license is compatible with GPL.
I have no clue as to the license status of changes between the copying and the relicensing.
Of course copyright holding contributors can decide to relicense. The contributors to the Spec-* packages in the Pharo/Pharo30 repo seem to be:
AlainPlantec AndreiChis BenComan BenjaminVanRyseghem BernardoContreras CamilloBruni CamilleTeruel ChristopheDemarey ClementBera DamienCassou ErwanDouaille EstebanLorenzano GabrielOmarCotelli GuillermoPolito HernanMoralesDurand IgorStasenko LeoGassman MarcusDenker MartinDias NicolaiHess PabloHerrero PavelKrivanek PhilippeBack RobertoMinelli SeanDeNigris SebastianTleye StephaneDucasse SvenVanCaekenberghe TorstenBergmann TudorGirba YuriyTymchuk
Stephan
Hi skri Glenn is also working for a company and building an alternative to Spec to support mobile and others. What is important is that - we should continue to clean and improve spec and its documentation. - understand and push alternative solutions - so I suggest that you should make sure that other people can use what you are doing and continue to push it. Nothing is curved on stones. I clean Morphic regularly but I will be happy to through away all my work if something better is coming (bloc for example). Stef On 28/8/14 15:21, S Krish wrote:
Will there be any interest in alternative declarative framework, mostly fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et als in 3.0
http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-...
I can push this in with the required MIT license sign off as reqd.
More importantly, move this framework to a more refactored cleaner state if there is a slight interest in alternatives.
On Thu, Aug 28, 2014 at 5:51 PM, phil@highoctane.be <mailto:phil@highoctane.be> <phil@highoctane.be <mailto:phil@highoctane.be>> wrote:
No, it doesn't.
We can improve Spec in the core, why wouldn't we be able to? We use it in a lot of the tools, so, there are plenty of samples and documentation exists.
One can make sense of what's going on under the hood.
Have a look at: (this is for Pharo 3.0)
SpecInterpreter>>interpretASpec:selector: and ComposableModel + NewValueHolder. WindowModel is interesting to look into as well.
The "famous" NewValueHolder is of interest too.
then implementors of defaultSpec provide a lot of specs to give to the SpecInterpreter.
Then one wants to look into the Spec-MorphicAdapters to see how Spec maps its view on things with underlying Morphs (e.g. check the MorphicDiffAdapter).
We can only benefit by caring about this piece on our side, as there is tremendous potential in being able to change the underlying system (e.g. from Morphic to Bloc for example) in a piecemeal way, without breaking all of the tools.
Phil
On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
Does it really matter? If the external repository gets successfully relicensed, or Benjamin publishes new improvements as a separate, GPL-licensed change set, the end result is the same; no improvement he makes will make its way back into the versions in Core.
I may not know his reasons, but I can certainly respect his wish that no further contributions are included in a core distribution.
Whether to maintain/improve the current, MIT-licensed versions in Core without him, or unload it all and point potential users to the external library, is a separate decision. Though, from previous attempts, Iâd say the chances of success of an external UI-builder framework seeing actual use are rather slim.
Cheers, Henry
On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote:
> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397... > > I think the license might need further improvements. > I've taken a look at the commit history, and it looks > to me like there is a licensing problem there. > I am no lawyer, so don't know what the > exact consequences of that are. > > The (MIT licensed) Pharo code was copied > to the repository without including the copyright > notice, as is required by the MIT license. > > For new contributions, you now have the > license agreements, and with git it is > perfectly clear what is new, and under > the new license, and what is old, and > can therefore also be used under the > old license. And AFAIK MIT license > is compatible with GPL. > > I have no clue as to the license status of > changes between the copying and the > relicensing. > > Of course copyright holding contributors can > decide to relicense. The contributors to the > Spec-* packages in the Pharo/Pharo30 repo > seem to be: > > AlainPlantec > AndreiChis > BenComan > BenjaminVanRyseghem > BernardoContreras > CamilloBruni > CamilleTeruel > ChristopheDemarey > ClementBera > DamienCassou > ErwanDouaille > EstebanLorenzano > GabrielOmarCotelli > GuillermoPolito > HernanMoralesDurand > IgorStasenko > LeoGassman > MarcusDenker > MartinDias > NicolaiHess > PabloHerrero > PavelKrivanek > PhilippeBack > RobertoMinelli > SeanDeNigris > SebastianTleye > StephaneDucasse > SvenVanCaekenberghe > TorstenBergmann > TudorGirba > YuriyTymchuk > > Stephan > > > >
Thx.. Here I repost, an alternative framework to wire up Morphic UI: * Implicit spec, full layout described spec and table layout based spec options: http://skrishnamachari.wordpress.com/2014/09/01/reviving-pharo-morphic-view/ Model / View / Controller hooks exists, the additional parts of the 2012 works, needs to be refactored for Pharo 3.0 and will be posted later. Specially the ValueHolder capability for all morph widgets. The framework works on 3 base and minimal support classes on top of the existing morphic framework. On Fri, Aug 29, 2014 at 1:43 PM, stepharo <stepharo@free.fr> wrote:
Hi skri
Glenn is also working for a company and building an alternative to Spec to support mobile and others. What is important is that
- we should continue to clean and improve spec and its documentation. - understand and push alternative solutions - so I suggest that you should make sure that other people can use what you are doing and continue to push it.
Nothing is curved on stones. I clean Morphic regularly but I will be happy to through away all my work if something better is coming (bloc for example).
Stef
On 28/8/14 15:21, S Krish wrote:
Will there be any interest in alternative declarative framework, mostly fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et als in 3.0
http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-...
I can push this in with the required MIT license sign off as reqd.
More importantly, move this framework to a more refactored cleaner state if there is a slight interest in alternatives.
On Thu, Aug 28, 2014 at 5:51 PM, phil@highoctane.be <phil@highoctane.be> wrote:
No, it doesn't.
We can improve Spec in the core, why wouldn't we be able to? We use it in a lot of the tools, so, there are plenty of samples and documentation exists.
One can make sense of what's going on under the hood.
Have a look at: (this is for Pharo 3.0)
SpecInterpreter>>interpretASpec:selector: and ComposableModel + NewValueHolder. WindowModel is interesting to look into as well.
The "famous" NewValueHolder is of interest too.
then implementors of defaultSpec provide a lot of specs to give to the SpecInterpreter.
Then one wants to look into the Spec-MorphicAdapters to see how Spec maps its view on things with underlying Morphs (e.g. check the MorphicDiffAdapter).
We can only benefit by caring about this piece on our side, as there is tremendous potential in being able to change the underlying system (e.g. from Morphic to Bloc for example) in a piecemeal way, without breaking all of the tools.
Phil
On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
Does it really matter? If the external repository gets successfully relicensed, or Benjamin publishes new improvements as a separate, GPL-licensed change set, the end result is the same; no improvement he makes will make its way back into the versions in Core.
I may not know his reasons, but I can certainly respect his wish that no further contributions are included in a core distribution.
Whether to maintain/improve the current, MIT-licensed versions in Core without him, or unload it all and point potential users to the external library, is a separate decision. Though, from previous attempts, Iâd say the chances of success of an external UI-builder framework seeing actual use are rather slim.
Cheers, Henry
On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan@stack.nl> wrote:
https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397...
I think the license might need further improvements. I've taken a look at the commit history, and it looks to me like there is a licensing problem there. I am no lawyer, so don't know what the exact consequences of that are.
The (MIT licensed) Pharo code was copied to the repository without including the copyright notice, as is required by the MIT license.
For new contributions, you now have the license agreements, and with git it is perfectly clear what is new, and under the new license, and what is old, and can therefore also be used under the old license. And AFAIK MIT license is compatible with GPL.
I have no clue as to the license status of changes between the copying and the relicensing.
Of course copyright holding contributors can decide to relicense. The contributors to the Spec-* packages in the Pharo/Pharo30 repo seem to be:
AlainPlantec AndreiChis BenComan BenjaminVanRyseghem BernardoContreras CamilloBruni CamilleTeruel ChristopheDemarey ClementBera DamienCassou ErwanDouaille EstebanLorenzano GabrielOmarCotelli GuillermoPolito HernanMoralesDurand IgorStasenko LeoGassman MarcusDenker MartinDias NicolaiHess PabloHerrero PavelKrivanek PhilippeBack RobertoMinelli SeanDeNigris SebastianTleye StephaneDucasse SvenVanCaekenberghe TorstenBergmann TudorGirba YuriyTymchuk
Stephan
The Spec news page [1] explains the license change and anyone can easily guess that it is caused by Benjamins personal disagreements with Stef. No judgement on that from my side as this is a personal issue between the two and as I like most of us have only a few infos on that from the outside. It is interesting that there is also a new Spec release [2] announced this week although in his last post [3] Benjamin stated "I am quiting the Pharo community, as well as the Smalltalk community". To me it looks like Benjamin want's to punish Stef - but it will affect the community and the idea WE ALL hardly work on ... Sorry but this is a more childish like reaction from his side and not a good way to solve disagreements. I can only talk about this from an outside point of view but I think nobody in our community will profit from Benjamin reaction - it makes it harder for the whole Pharo community to work with Spec and in my opinion it will be not good for Spec framework or Benjamin either.
From what I see now my personal recommendation would be decide within the community if Spec could be a base for the future of our UI and tool building and if so rename and continue in a forked way with the MIT licensed code within the Pharo image so it will not be confused with Benjamins version, license and page.
Looks like currently that this is the only way to continue with it and ensure contributions will stay single licensed/MIT licensed. We can only change the future - not the past... Thx T. [1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html [2] http://spec.st/news/#Spec%202.0.0%20release [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-August/09935...
http://forum.world.st/Board-clarification-around-Spec-td4775346.html On 03 Sep 2014, at 10:24, Torsten Bergmann <astares@gmx.de> wrote:
The Spec news page [1] explains the license change and anyone can easily guess that it is caused by Benjamins personal disagreements with Stef. No judgement on that from my side as this is a personal issue between the two and as I like most of us have only a few infos on that from the outside.
It is interesting that there is also a new Spec release [2] announced this week although in his last post [3] Benjamin stated "I am quiting the Pharo community, as well as the Smalltalk community".
To me it looks like Benjamin want's to punish Stef - but it will affect the community and the idea WE ALL hardly work on ... Sorry but this is a more childish like reaction from his side and not a good way to solve disagreements.
I can only talk about this from an outside point of view but I think nobody in our community will profit from Benjamin reaction - it makes it harder for the whole Pharo community to work with Spec and in my opinion it will be not good for Spec framework or Benjamin either.
From what I see now my personal recommendation would be decide within the community if Spec could be a base for the future of our UI and tool building and if so rename and continue in a forked way with the MIT licensed code within the Pharo image so it will not be confused with Benjamins version, license and page.
Looks like currently that this is the only way to continue with it and ensure contributions will stay single licensed/MIT licensed.
We can only change the future - not the past...
Thx T.
[1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html [2] http://spec.st/news/#Spec%202.0.0%20release [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-August/09935...
Le 3 sept. 2014 à 10:24, Torsten Bergmann a écrit :
It is interesting that there is also a new Spec release [2] announced this week
I can see in the announce: Adds SpecTableLayout, thanks @webwarrior-ws Removes hardcoded colors, thanks @Uko Do the authors of contribution (or their company if the contribution is done at work) agree on the new spec license? If not, it cannot be part of the new spec and could be integrated in Pharo spec. If so, we won't be able to integrate these fixes in Pharo. It woud be good that spec contributors clarify their position. Regards, Christophe.
Hi phil I agree. I cleaned the MorphicAdapters during a recesss from project writing. I should finish the last two: menu and menu group. Stef On 28/8/14 14:21, phil@highoctane.be wrote:
No, it doesn't.
We can improve Spec in the core, why wouldn't we be able to? We use it in a lot of the tools, so, there are plenty of samples and documentation exists.
One can make sense of what's going on under the hood.
Have a look at: (this is for Pharo 3.0)
SpecInterpreter>>interpretASpec:selector: and ComposableModel + NewValueHolder. WindowModel is interesting to look into as well.
The "famous" NewValueHolder is of interest too.
then implementors of defaultSpec provide a lot of specs to give to the SpecInterpreter.
Then one wants to look into the Spec-MorphicAdapters to see how Spec maps its view on things with underlying Morphs (e.g. check the MorphicDiffAdapter).
We can only benefit by caring about this piece on our side, as there is tremendous potential in being able to change the underlying system (e.g. from Morphic to Bloc for example) in a piecemeal way, without breaking all of the tools.
Phil
On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
Does it really matter? If the external repository gets successfully relicensed, or Benjamin publishes new improvements as a separate, GPL-licensed change set, the end result is the same; no improvement he makes will make its way back into the versions in Core.
I may not know his reasons, but I can certainly respect his wish that no further contributions are included in a core distribution.
Whether to maintain/improve the current, MIT-licensed versions in Core without him, or unload it all and point potential users to the external library, is a separate decision. Though, from previous attempts, Iâd say the chances of success of an external UI-builder framework seeing actual use are rather slim.
Cheers, Henry
On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote:
> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397... > > I think the license might need further improvements. > I've taken a look at the commit history, and it looks > to me like there is a licensing problem there. > I am no lawyer, so don't know what the > exact consequences of that are. > > The (MIT licensed) Pharo code was copied > to the repository without including the copyright > notice, as is required by the MIT license. > > For new contributions, you now have the > license agreements, and with git it is > perfectly clear what is new, and under > the new license, and what is old, and > can therefore also be used under the > old license. And AFAIK MIT license > is compatible with GPL. > > I have no clue as to the license status of > changes between the copying and the > relicensing. > > Of course copyright holding contributors can > decide to relicense. The contributors to the > Spec-* packages in the Pharo/Pharo30 repo > seem to be: > > AlainPlantec > AndreiChis > BenComan > BenjaminVanRyseghem > BernardoContreras > CamilloBruni > CamilleTeruel > ChristopheDemarey > ClementBera > DamienCassou > ErwanDouaille > EstebanLorenzano > GabrielOmarCotelli > GuillermoPolito > HernanMoralesDurand > IgorStasenko > LeoGassman > MarcusDenker > MartinDias > NicolaiHess > PabloHerrero > PavelKrivanek > PhilippeBack > RobertoMinelli > SeanDeNigris > SebastianTleye > StephaneDucasse > SvenVanCaekenberghe > TorstenBergmann > TudorGirba > YuriyTymchuk > > Stephan > > > >
participants (8)
-
Christophe Demarey -
Henrik Johansen -
phil＠highoctane.be -
S Krish -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Torsten Bergmann