Spec license

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Spec license

Stephan Eggermont-3
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




Reply | Threaded
Open this post in threaded view
|

Re: Spec license

Henrik Sperre Johansen
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 <[hidden email]> 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
>
>
>
>


signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spec license

philippeback
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 <[hidden email]> 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 <[hidden email]> 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
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Spec license

S Krish

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-aka-morphic-view-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, [hidden email] <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Spec license

stepharo
In reply to this post by philippeback
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, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Spec license

stepharo
In reply to this post by S Krish
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-aka-morphic-view-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, [hidden email] <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Spec license

S Krish

Thx..

Here I repost, an alternative framework to wire up Morphic UI:
* Implicit spec, full layout described spec and table layout based spec options:
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 <[hidden email]> 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-aka-morphic-view-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, [hidden email] <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>
>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: Spec license

Torsten Bergmann
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/099354.html

Reply | Threaded
Open this post in threaded view
|

Re: Spec license

Sven Van Caekenberghe-2
http://forum.world.st/Board-clarification-around-Spec-td4775346.html

On 03 Sep 2014, at 10:24, Torsten Bergmann <[hidden email]> 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/099354.html
>


Reply | Threaded
Open this post in threaded view
|

Re: Spec license

demarey
In reply to this post by Torsten Bergmann

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.


    smime.p7s (5K) Download Attachment
    Reply | Threaded
    Open this post in threaded view
    |

    Re: Spec license

    demarey
    Yes, you should add a slice in the Pharo inbox with your contribution but ... it depends under which license you first published your contribution. If it was MIT, it is fine (and spec is out of law). If it was the double licensing, we will not be able to integrate it into Pharo. We should re-implement this functionality.
    I know these things are boring but we should take care to avoid potential problems in the future.

    Le 4 sept. 2014 à 11:13, Yuriy Tymchuk a écrit :

    Oh wow, it’s amazing how complicated things can get… What you I have to do to have fixes available in Pharo? Send a slice to Pharo inbox? I just want to use dark theme in pharo and don’t have ugly UI parts

    Uko

    On 04 Sep 2014, at 10:52, Christophe Demarey <[hidden email]> wrote:


    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.




    smime.p7s (5K) Download Attachment
    Reply | Threaded
    Open this post in threaded view
    |

    Re: Spec license

    Uko2
    I’ve made fixes long time ago before Ben left.
    + my change is in Pharo image.

    Is this enough?

    Uko

    On 04 Sep 2014, at 11:39, Christophe Demarey <[hidden email]> wrote:

    Yes, you should add a slice in the Pharo inbox with your contribution but ... it depends under which license you first published your contribution. If it was MIT, it is fine (and spec is out of law). If it was the double licensing, we will not be able to integrate it into Pharo. We should re-implement this functionality.
    I know these things are boring but we should take care to avoid potential problems in the future.

    Le 4 sept. 2014 à 11:13, Yuriy Tymchuk a écrit :

    Oh wow, it’s amazing how complicated things can get… What you I have to do to have fixes available in Pharo? Send a slice to Pharo inbox? I just want to use dark theme in pharo and don’t have ugly UI parts

    Uko

    On 04 Sep 2014, at 10:52, Christophe Demarey <[hidden email]> wrote:


    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.




    Reply | Threaded
    Open this post in threaded view
    |

    Re: Spec license

    demarey

    Le 5 sept. 2014 à 09:38, Yuriy Tymchuk a écrit :

    > I’ve made fixes long time ago before Ben left.
    > + my change is in Pharo image.
    >
    > Is this enough?

    I think so. All code contributed to Pharo via Fogbugz is licensed under MIT.
    Problems may come if you did a pull request on the spec git repo after the re-licensing.


    smime.p7s (5K) Download Attachment
    Reply | Threaded
    Open this post in threaded view
    |

    Re: Spec license

    Uko2
    No it was before.

    https://github.com/spec-framework/spec/pull/14

    May 2

    On 05 Sep 2014, at 10:43, Christophe Demarey <[hidden email]> wrote:

    >
    > Le 5 sept. 2014 à 09:38, Yuriy Tymchuk a écrit :
    >
    >> I’ve made fixes long time ago before Ben left.
    >> + my change is in Pharo image.
    >>
    >> Is this enough?
    >
    > I think so. All code contributed to Pharo via Fogbugz is licensed under MIT.
    > Problems may come if you did a pull request on the spec git repo after the re-licensing.
    >


    Reply | Threaded
    Open this post in threaded view
    |

    Re: Spec license

    Ben Coman
    Now I'm glad that I just read [1] which says "Today (15 Aug 2014), Spec is changing its license. Until today, Spec was released under the MIT license." I was just about to again rant about the apparent silent relicensing of Spec on 6 Jan 2014 [2] to the CCPL-A-NC-SA [3] (Creative Commons Public License Attribution-NonCommercial-ShareAlike).  So I'll optimistically consider that was just poorly thought out rather than a cunning plan. 

    Yet this still presents some complication.  The CPPL was the documented license of the Spec git repository from 6 Jan 2014 to 16 Aug 2014 [4].  When BenVR submitted this CPPL licensed code into Pharo, he implicitly relicensed "his" parts as MIT.  However he is unable to similarly relicense the code of a third party contributor like Yuriy.  Only Yuriy can do that.  Now even though Yuriy's code in external Spec repository might be encumbered by the CPPL, it is still "his" code. He retains the copyright for it in all distributions.  He can even relicense his code that portion of it at any time, even if upon distribution it would pick up the CPPL again.  However if all contributors [5] similarly agree that their Spec contributions are MIT licensed in Pharo, then we should be in the clear. Could I ask the board follow up directly with those contributors [5] (off list) to confirm their Spec contributions current in Pharo to date are MIT licensed.  This might be making a mountain out of a mole hill, but that is what keeps the wolves at bay.

    [1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html
    [2] https://github.com/spec-framework/spec/blob/8d8e85934188be486c9e91e5bff44670c451d00d/LICENSE
    [3] http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode
    [4] https://github.com/bencoman/spec/commit/dc7b5ed7bfb129e29c131e9f97b1333f81c4cec9
    [5] https://github.com/bencoman/spec/graphs/contributors


    Uko

    On 04 Sep 2014, at 11:39, Christophe Demarey <[hidden email]> wrote:

    Yes, you should add a slice in the Pharo inbox with your contribution but ... it depends under which license you first published your contribution. If it was MIT, it is fine (and spec is out of law). If it was the double licensing, we will not be able to integrate it into Pharo. We should re-implement this functionality.
    I know these things are boring but we should take care to avoid potential problems in the future.

    I don't think it matters which license Yuriy first published under.  The copyright of _his_ code remains _his_ to relicense whenever he likes.  The CCPL and GPL-like licenses are only applied to "distribution" of modifications _with_ the original code.  The GPL does not "apply" to modifications that are not "distributed".  That is, the GPL does not force you to release source for modifications that you don't "distribute" to others.  Think of it like this.  As Uko was modifying Spec on his machine, his modifications were unencumbered by the CCPL. Yuriy then submitted/distributed a "copy" of his modifications to the github Spec repository, so the CPPL applies to _that_ "copy".  Yuriy's original modifications on his machine remain unencumbered.  He is free to distribute them under another license.  Indeed, I believe he can even relicense his CCPL encumbered "copy" in the external Spec repository, but that is ineffective unless everyone else does the same.


    Yuriy Tymchuk wrote:
    No it was before.
    
    https://github.com/spec-framework/spec/pull/14
    
    May 2
    
    On 05 Sep 2014, at 10:43, Christophe Demarey [hidden email] wrote:
    
      
    Le 5 sept. 2014 à 09:38, Yuriy Tymchuk a écrit :
    
        
    I’ve made fixes long time ago before BenVR left.
    + my change is in Pharo image.
    
    Is this enough?
          

    Did your change end up in Pharo via the CCPL licensed external Spec repository on github?
    Or did you submit it to the MIT licensed PharoInbox?

    I think so. All code contributed to Pharo via Fogbugz is licensed under MIT.
    Problems may come if you did a pull request on the spec git repo after the re-licensing.
        

    All contributions to the CPPL licensed external Spec repository after Jan 2014 are potentially problematic.  In practice, a statement from Yuriy that confirms his Spec contributions are MIT licensed in Pharo is probably sufficient. 

    cheers -ben


    Reply | Threaded
    Open this post in threaded view
    |

    Re: Spec license

    kilon.alios
    Well I can tell you as a lawyer that GPL is a legal nightmare. I am not against anyone using it as a license but legally is far from clear and there is no guarantees under which circumstances is enforceable. 

    Also copyright is tricky, usually someone contributes based on existing code, so code is not independent and is difficult not to have conflict of interests and conflict of copyrights. 

    And on top of that good luck explaining that to a judge, especially one without a good experience in computer law cases. Also license and copyright is two different things unless the license is explicit in surrendering any copyright . 

    The later is also the safest way to do this legal wise, no copyright means less legal trouble. I also speak from experience I have a case of copyright infringement for software between an individual  and a company ( I represent the company) the case has been in courts for over a decade now and the courts have not even dealt with the technical side of who actually wrote the code and still are on the stage of deciding what legal type the work was. 

    So yes be careful and always consult a lawyer if you are company and an individual if you intend making money with the code. 


    On Fri, Sep 5, 2014 at 6:20 PM, Ben Coman <[hidden email]> wrote:
    Now I'm glad that I just read [1] which says "Today (15 Aug 2014), Spec is changing its license. Until today, Spec was released under the MIT license." I was just about to again rant about the apparent silent relicensing of Spec on 6 Jan 2014 [2] to the CCPL-A-NC-SA [3] (Creative Commons Public License Attribution-NonCommercial-ShareAlike).  So I'll optimistically consider that was just poorly thought out rather than a cunning plan. 

    Yet this still presents some complication.  The CPPL was the documented license of the Spec git repository from 6 Jan 2014 to 16 Aug 2014 [4].  When BenVR submitted this CPPL licensed code into Pharo, he implicitly relicensed "his" parts as MIT.  However he is unable to similarly relicense the code of a third party contributor like Yuriy.  Only Yuriy can do that.  Now even though Yuriy's code in external Spec repository might be encumbered by the CPPL, it is still "his" code. He retains the copyright for it in all distributions.  He can even relicense his code that portion of it at any time, even if upon distribution it would pick up the CPPL again.  However if all contributors [5] similarly agree that their Spec contributions are MIT licensed in Pharo, then we should be in the clear. Could I ask the board follow up directly with those contributors [5] (off list) to confirm their Spec contributions current in Pharo to date are MIT licensed.  This might be making a mountain out of a mole hill, but that is what keeps the wolves at bay.

    [1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html
    [2] https://github.com/spec-framework/spec/blob/8d8e85934188be486c9e91e5bff44670c451d00d/LICENSE
    [3] http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode
    [4] https://github.com/bencoman/spec/commit/dc7b5ed7bfb129e29c131e9f97b1333f81c4cec9
    [5] https://github.com/bencoman/spec/graphs/contributors


    Uko

    On 04 Sep 2014, at 11:39, Christophe Demarey <[hidden email]> wrote:

    Yes, you should add a slice in the Pharo inbox with your contribution but ... it depends under which license you first published your contribution. If it was MIT, it is fine (and spec is out of law). If it was the double licensing, we will not be able to integrate it into Pharo. We should re-implement this functionality.
    I know these things are boring but we should take care to avoid potential problems in the future.

    I don't think it matters which license Yuriy first published under.  The copyright of _his_ code remains _his_ to relicense whenever he likes.  The CCPL and GPL-like licenses are only applied to "distribution" of modifications _with_ the original code.  The GPL does not "apply" to modifications that are not "distributed".  That is, the GPL does not force you to release source for modifications that you don't "distribute" to others.  Think of it like this.  As Uko was modifying Spec on his machine, his modifications were unencumbered by the CCPL. Yuriy then submitted/distributed a "copy" of his modifications to the github Spec repository, so the CPPL applies to _that_ "copy".  Yuriy's original modifications on his machine remain unencumbered.  He is free to distribute them under another license.  Indeed, I believe he can even relicense his CCPL encumbered "copy" in the external Spec repository, but that is ineffective unless everyone else does the same.


    Yuriy Tymchuk wrote:
    No it was before.
    
    https://github.com/spec-framework/spec/pull/14
    
    May 2
    
    On 05 Sep 2014, at 10:43, Christophe Demarey [hidden email] wrote:
    
      
    Le 5 sept. 2014 à 09:38, Yuriy Tymchuk a écrit :
    
        
    I’ve made fixes long time ago before BenVR left.
    + my change is in Pharo image.
    
    Is this enough?
          

    Did your change end up in Pharo via the CCPL licensed external Spec repository on github?
    Or did you submit it to the MIT licensed PharoInbox?

    I think so. All code contributed to Pharo via Fogbugz is licensed under MIT.
    Problems may come if you did a pull request on the spec git repo after the re-licensing.
        

    All contributions to the CPPL licensed external Spec repository after Jan 2014 are potentially problematic.  In practice, a statement from Yuriy that confirms his Spec contributions are MIT licensed in Pharo is probably sufficient. 

    cheers -ben