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.johan...@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 <step...@stack.nl> wrote: > > > > https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f3974c69314b7f#commitcomment-7540588 > > > > 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 > > > > > > > > > >
