December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] License agreement - are you kidding me?

by Esteban Lorenzano

so, first of all, I find the way you communicate your arguments a bitâ¦ well, not very polite. second, even Benâs affaire should show you why we value this license agreements. third, French laws are French laws and since the development of Pharo is in a big extent made here (through INRIA), French laws needs to be fulfilled. And no, there are no exceptionsâ¦ we wouldnât be able to operate here without that: French law does not recognise digital signatures, checkbox or anything that comes from the âvirtual worldâ (we have a lot of funny examples of things we decide to to request from other EU countries because if we request it here, we need to send them a contract by mail). four, no copyright is lost. Your code keeps your name, etc. What you lose is the right to take out your code (and to change the licensing of it retroactivelyâ¦). five, nobody forces you to do anything. Iâm really sorry you take this as a personal prosecution (or a personal battle)â¦ while I value all contributions and discussions (and I certainly would like you continue contributing), I find the tone of your reclamation a little bit out-of-the-tone of a real argumentationâ¦ kind of trollishâ¦ so I wonder if you really want to discuss something or notâ¦ cheers! Esteban > On 08 Dec 2015, at 00:47, webwarrior <reg(a)webwarrior.ws> wrote: > > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > > View this message in context: Re: License agreement - are you kidding me? <http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853p486591…> > Sent from the Pharo Smalltalk Developers mailing list archive <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at Nabble.com.

Dec. 8, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] b01122: 50490

by stepharo

Thanks Cyril and others! Stef Le 8/12/15 11:16, Marcus Denker a Ã©crit : >> On 08 Dec 2015, at 11:10, GitHub <noreply(a)github.com> wrote: >> >> >> >> Log Message: >> ----------- >> 50490 >> 17211 FastTable update (see description) >> https://pharo.fogbugz.com/f/cases/17211 >> > This is: > > - Documentation > - Improvement of the speed of examples > - Removes indenting for the headerRow. > - 17117 MouseOver feedback for the rows in FastTable > - 17124 FastTable row placement should be done with integers > - 16882 Dragging methods to another protocol in Nautilus doesn't work every second time > - 16865 When dragging a method over protocols, it doesn't scroll the protocol list > - FTTreeDataSource should update the selection when we collapse/expand an item > - Raise Error in some case instead of doing nothing > - Add a Menu to a basic FTTreeDataSource > - Remove background color Ivar + accessor. ( not used, and the Color ivar from parent class Morph is used to define the "background" color instead. > - When a FastTable send an announcement, the announcement should know which FT announce it. > - Use UITheme current for the seperatorColor in CellMorph. > - Some small fix > > > Thanks to Cyril Ferlicot for doing the sync and for doing many of those fixes and improvements! > (and to http://www.synectique.eu for sponsoring the work, of course) > > Marcus >

Dec. 8, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] b01122: 50490

by Marcus Denker

> On 08 Dec 2015, at 11:10, GitHub <noreply(a)github.com> wrote: > > > > Log Message: > ----------- > 50490 > 17211 FastTable update (see description) > https://pharo.fogbugz.com/f/cases/17211 > This is: - Documentation - Improvement of the speed of examples - Removes indenting for the headerRow. - 17117 MouseOver feedback for the rows in FastTable - 17124 FastTable row placement should be done with integers - 16882 Dragging methods to another protocol in Nautilus doesn't work every second time - 16865 When dragging a method over protocols, it doesn't scroll the protocol list - FTTreeDataSource should update the selection when we collapse/expand an item - Raise Error in some case instead of doing nothing - Add a Menu to a basic FTTreeDataSource - Remove background color Ivar + accessor. ( not used, and the Color ivar from parent class Morph is used to define the "background" color instead. - When a FastTable send an announcement, the announcement should know which FT announce it. - Use UITheme current for the seperatorColor in CellMorph. - Some small fix Thanks to Cyril Ferlicot for doing the sync and for doing many of those fixes and improvements! (and to http://www.synectique.eu for sponsoring the work, of course) Marcus

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by Sven Van Caekenberghe

I don't want to add to this discussion, but when plain errors are written, I have to. I thought you were a lawyer ? http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf << The Parties agree that Supplier has contributed source code (the âSupplierâs Codeâ) for the open source software known as âPharoâ (the âSoftwareâ), and that Supplier retains all rights in and to Supplierâs Code, aside from the rights expressly granted to Distributor in this Agreement. The Parties acknowledge that the Software in its entirety is a collective work containing source code contributions from several authors, and that Supplierâs Code is only a small component part of the Software work as a whole. Supplier hereby grants Distributor a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license to distribute the Software, and specifically the Supplierâs Code therein, to end users, subject to the license agreement commonly known as the âMIT Licenseâ >> Nowhere it says that you lose your copyright !! Furthermore, this is a very simple document with no hidden agenda, it is a consequence of using the MIT license. > On 08 Dec 2015, at 10:54, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > The one thing I dont like about that agreement is that it forces to retreat from the personal copyright if I remember the document correctly. Even though personally I would not mind that for bug fixes and small enhancements where my copyright would not be so much of a big deal. For bigger tools and code that I have put substantial effort and suffered pain to make them work I would not give away my copyright. So I am not seeing myself signing this any time soon either. > > Revealing my real name and some other stuff is not a problem. > > So I can certainly understand some of your frustration webwarrior. > > > > On Tue, Dec 8, 2015 at 10:44 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Dec 8, 2015 at 12:47 AM, webwarrior <reg(a)webwarrior.ws> wrote: > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > > You'd be surprised. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > > Farewell then. > > Phil > > > View this message in context: Re: License agreement - are you kidding me? > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 8, 2015

Re: [Pharo-dev] CollectionValueHolder additions

by stepharo

Hi peter Do you mean instead of having ValueChanged? What would be scenario for ValueRemoved? Stef Le 8/12/15 01:01, Peter Uhnak a Ã©crit : > Hi, > > when (any) ValueHolder changes, a ValueChanged announcement is fired. > > My question: Would it be a good idea to add ValueAdded and ValueRemoved > for CollectionValueHolder? > > Otherwise there's no way to meaningfully observe changes. >

Dec. 8, 2015

[pharo-project/pharo-core] b01122: 50490

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b01122f7148d3f9abdb0bb6ae4f2475650701927 https://github.com/pharo-project/pharo-core/commit/b01122f7148d3f9abdb0bb6a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-08 (Tue, 08 Dec 2015) Changed paths: M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version081_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/matchingFilter_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/searchIn_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/unexpandAllChildOf_.st M Morphic-Widgets-FastTable.package/FTAnnouncement.class/definition.st A Morphic-Widgets-FastTable.package/FTAnnouncement.class/instance/accessing/fastTable.st A Morphic-Widgets-FastTable.package/FTAnnouncement.class/instance/accessing/fastTable_.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/README.md M Morphic-Widgets-FastTable.package/FTBasicItem.class/definition.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/expand.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/expandAndRefresh.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/recentlyChanged.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/unexpand.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/unexpandAndRefresh.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/collpasedButton.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/expandedButton.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/generateButton.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/unexpandedButton.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/collapse.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/collapseAll.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/collapseAndRefresh.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/expand.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/expandAndRefresh.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/initialization/initialize.st M Morphic-Widgets-FastTable.package/FTCellMorph.class/README.md M Morphic-Widgets-FastTable.package/FTCellMorph.class/instance/drawing/drawOn_.st A Morphic-Widgets-FastTable.package/FTCellMorph.class/instance/drawing/seperatorColor.st M Morphic-Widgets-FastTable.package/FTColumn.class/README.md M Morphic-Widgets-FastTable.package/FTDataSource.class/README.md M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/cellColumn_row_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/elementAt_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/headerColumn_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/menuColumn_row_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/newDataSourceMatching_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/numberOfRows.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/table.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/private/readyToBeDisplayed.st A Morphic-Widgets-FastTable.package/FTExamples.class/class/examples/exampleDragAndDrop4.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTree1.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithAllItemsFilter.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithAllItemsSearch.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleexampleOneSubLevelTree.st M Morphic-Widgets-FastTable.package/FTFilterFunction.class/instance/updating/filter.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/accessing/cellColumn_row_.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/accessing/elementAt_.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/testing/needSeparatorBefore_.st A Morphic-Widgets-FastTable.package/FTRootItem.class/instance/accessing/recentlyChanged.st A Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/collapseAll.st M Morphic-Widgets-FastTable.package/FTSelectionChanged.class/README.md M Morphic-Widgets-FastTable.package/FTStrongSelectionChanged.class/README.md M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/README.md M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/drawOn_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateExactVisibleRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateStartIndexWhenShowing_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateVisibleRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/exposedRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/testing/canRefreshValues.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/class/as yet unclassified/with_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/definition.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing colors/backgroundColor.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing colors/backgroundColor_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing selection/selectRowIndexes_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/dataSource_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/drag and drop/startDrag_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/handleMouseMove_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseDown_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseEnterDragging_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseLeaveDragging_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseMove_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseUp_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/defaultColor.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/initialize.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/updating/autoScrollHeightLimit.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/updating/themeChanged.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/handlesMouseOver_.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/mouseEnter_.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/mouseLeave_.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/initialize/mouseOverColor.st M Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/instance/initialization/initializeTable_row_primary_.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/accessing/menuColumn_row_.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/expanding-collapsing/collapseAll.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/updating/indexOfChangedItem.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/updating/updateSelectionWithCollectBlock_.st M Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/accessing/childAt_.st A Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/accessing/recentlyChanged.st A Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/expanding-collapsing/collapseAll.st A Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/updating/selectedRowsIndexesFrom_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50489.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50490.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50489.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50490.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50490 17211 FastTable update (see description) https://pharo.fogbugz.com/f/cases/17211 http://files.pharo.org/image/50/50490.zip

Dec. 8, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50490 Home: https://github.com/pharo-project/pharo-core

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by stepharo

Could we have a synthesis of the discussion? It would be good to have a list of working solutions with pointers. Stef

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by stepharo

I would like to see this code injector too. Stef Le 7/12/15 18:43, Thierry Goubier a Ã©crit : > Hi HernÃ¡n, > > Le 07/12/2015 18:16, HernÃ¡n Morales Durand a Ã©crit : >> Hi Sven >> >> 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>>: >> >> There is still #do:displayingProgress: >> >> There is Job. >> >> In general, the collection API should not be concerned with GUI >> matters, does it ? >> >> >> Believe me when you're executing a large workflow processing 50Gb files >> with 5 other people expecting feedback from the screen, the least of >> your concerns is the purity of collection API. I don't know what other >> coders do, kick your co-workers off the room? Sit to see a blank Pharo >> screen? >> To me the key is to have feedback from the system without having to >> change your 20 iterators in a group of client classes where you NEED to >> see progress. >> >> Anyway I agree with you Collection should not have GUI dependencies, >> that's the reason I took a different approach and that's why I asked >> with an expression like: >> >> SmalltalkImage setDisplayProgressTo: MyClass. >> >> with such kind of expression you never touch the Collection API. You >> just walk MyClass for every enumeration messsage send (of your interest) >> and perform a transformation. Note the same "technique" could be applied >> for logging and/or profiling. > > Yes. The Jejak tracer uses a similar technique. I'd guess others do as > well. > >> We can't have equivalents of all collection methods for displaying >> progress, nor can it be a (semi-) global setting. >> >> >> Sure, that would be the anti-object technology :) >> >> So I implemented a prototype which injects JobProgress code in methods >> using RBParseSearchTree. On uninstall I plan to recover the previous >> version of marked methods. No need to touch the Collection API at all, >> nor a setting. I am sure the same could be done with MethodWrappers but >> RB can manipulate AST nodes. >> >> However if there is a better idea I would love to hear about it. > > Could you put your RBParseTreeRewriter scripts somewhere? I'm interested. > > Technically, you used one of the best solutions out there to reach > your goal. Now, some would suggest aspect-oriented programming, but, > for me, this is a limited, easier to use API over a rewrite engine > like RB or the Metalinks of Marcus. > > Regards, > > Thierry > > >

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by Dimitris Chloupis

The one thing I dont like about that agreement is that it forces to retreat from the personal copyright if I remember the document correctly. Even though personally I would not mind that for bug fixes and small enhancements where my copyright would not be so much of a big deal. For bigger tools and code that I have put substantial effort and suffered pain to make them work I would not give away my copyright. So I am not seeing myself signing this any time soon either. Revealing my real name and some other stuff is not a problem. So I can certainly understand some of your frustration webwarrior. On Tue, Dec 8, 2015 at 10:44 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Dec 8, 2015 at 12:47 AM, webwarrior <reg(a)webwarrior.ws> wrote: > >> Considering that there are a couple of responses and the fact that you >> guys are so easily offended, I will not answer everyone but just state >> couple of theses. >> >> >> 0. I will not reveal my real name, because I value privacy. Nickname is >> sufficient for identification purposes. Any other information (real >> name, address, etc.) is not needed for actually contributing code. Think >> of principle of least privilege. >> >> 1. I could easily make up some human-looking name (Satoshi Nakamoto >> anyone?), but will not do it out of principle (see #0). >> >> 2. Knowing contributor's "real" name would not guard you against any >> possible malicious actions from him, because it can't be verified (see >> #1). One can also make up address, and even signature, if needed, and I >> bet no one would spot it. >> >> 3. I don't buy argument about requirements of some organizations. Linux >> kernel is used in billions of devices and by countless organizations, >> and I highly doubt that contributing to Linux requires anything like >> singing an agreement or whatever. >> > > You'd be surprised. > >> >> 4. Even in paid services checking a checkbox is usually sufficient for >> accepting any license/ToS. > > >> 5. My intentions are mostly of pragmatic nature. To make things that I >> use (and that can be useful to Pharo users) be in upstream. >> >> 6. I don't care whether you drink beer, your political views, or your >> interpersonal relationships (however story with Benjamin shows that >> perhaps everything's not as great as you paint it). These are all >> irrelevant to Pharo development, from my point of view at least. >> >> 7. If you don't agree with my arguments and stick to your rules, go for >> it. I'm in no position to tell you what's the right thing to do. I'll >> just end this discussion and leave. >> > > Farewell then. > > Phil > > >> >> ------------------------------ >> View this message in context: Re: License agreement - are you kidding me? >> <http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853p486591…> >> Sent from the Pharo Smalltalk Developers mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at >> Nabble.com. >> >

Dec. 8, 2015