Hello list,
on a recent SOB meeting someone recalled the idea of adding a 'license' field to method stamps. I proposed this maybe a year ago, but at that time, it was seem to have a short life period, because of upcoming Spoon release, which contains a full method history and supports a much better organized method history/author/license tracking.
In our current state, when we have a /trunk , we need, however some kind of assurance that all submissions going to trunk is license-clean. So, it is like that proposed change gives us a quick & fast recipe how to assure that.
Please review the mantis entry: http://bugs.squeak.org/view.php?id=6993
And lets discuss openly, the pros and cons of this change.
Hello Igor,
This idea is interesting. Would you describe a typical usage scenario? It could be all right as long as one doesn't have to retype (or being reminded) the license each and every time.
However, the new community development model manifesto has a section about the license. The trunk on the web has a link to this manifesto. There's so much one can do to protect himself. But when shall it stop?
Even a pop-up Window stipulating that the upcoming commit would be under MIT license with an "I agree" button would probably not stand any better. A paranoid mind could easily think that a malicious person could as well insert proprietary code and commit. That would be no easier to determine this until it blows into our face.
Ian.
2009/7/22 Igor Stasenko siguctua@gmail.com:
Hello list,
on a recent SOB meeting someone recalled the idea of adding a 'license' field to method stamps. I proposed this maybe a year ago, but at that time, it was seem to have a short life period, because of upcoming Spoon release, which contains a full method history and supports a much better organized method history/author/license tracking.
In our current state, when we have a /trunk , we need, however some kind of assurance that all submissions going to trunk is license-clean. So, it is like that proposed change gives us a quick & fast recipe how to assure that.
Please review the mantis entry: http://bugs.squeak.org/view.php?id=6993
And lets discuss openly, the pros and cons of this change.
-- Best regards, Igor Stasenko AKA sig.
On Wed, Jul 22, 2009 at 4:38 PM, Ian Trudelian.trudel@gmail.com wrote:
Hello Igor,
This idea is interesting. Would you describe a typical usage scenario? It could be all right as long as one doesn't have to retype (or being reminded) the license each and every time.
However, the new community development model manifesto has a section about the license. The trunk on the web has a link to this manifesto. There's so much one can do to protect himself. But when shall it stop?
Even a pop-up Window stipulating that the upcoming commit would be under MIT license with an "I agree" button would probably not stand any better. A paranoid mind could easily think that a malicious person could as well insert proprietary code and commit. That would be no easier to determine this until it blows into our face.
Ian.
2009/7/22 Igor Stasenko siguctua@gmail.com:
Hello list,
on a recent SOB meeting someone recalled the idea of adding a 'license' field to method stamps. I proposed this maybe a year ago, but at that time, it was seem to have a short life period, because of upcoming Spoon release, which contains a full method history and supports a much better organized method history/author/license tracking.
In our current state, when we have a /trunk , we need, however some kind of assurance that all submissions going to trunk is license-clean. So, it is like that proposed change gives us a quick & fast recipe how to assure that.
Please review the mantis entry: http://bugs.squeak.org/view.php?id=6993
And lets discuss openly, the pros and cons of this change.
-- Best regards, Igor Stasenko AKA sig.
2009/7/23 Ian Trudel ian.trudel@gmail.com:
Hello Igor,
This idea is interesting. Would you describe a typical usage scenario? It could be all right as long as one doesn't have to retype (or being reminded) the license each and every time.
(for usage, please see my other replies).
However, the new community development model manifesto has a section about the license. The trunk on the web has a link to this manifesto. There's so much one can do to protect himself. But when shall it stop?
Even a pop-up Window stipulating that the upcoming commit would be under MIT license with an "I agree" button would probably not stand any better. A paranoid mind could easily think that a malicious person could as well insert proprietary code and commit. That would be no easier to determine this until it blows into our face.
Right. Actually everythig , including author initials is built on top of a good will of one who filling/providing a correct & trustful information. So, i don't see how we could protect ourselves from malicious intents in this regard.
If you think in that way, then maybe its not worth it at all.
Ian.
2009/7/22 Igor Stasenko siguctua@gmail.com:
Hello list,
on a recent SOB meeting someone recalled the idea of adding a 'license' field to method stamps. I proposed this maybe a year ago, but at that time, it was seem to have a short life period, because of upcoming Spoon release, which contains a full method history and supports a much better organized method history/author/license tracking.
In our current state, when we have a /trunk , we need, however some kind of assurance that all submissions going to trunk is license-clean. So, it is like that proposed change gives us a quick & fast recipe how to assure that.
Please review the mantis entry: http://bugs.squeak.org/view.php?id=6993
And lets discuss openly, the pros and cons of this change.
-- Best regards, Igor Stasenko AKA sig.
2009/7/22 Igor Stasenko siguctua@gmail.com:
Right. Actually everythig , including author initials is built on top of a good will of one who filling/providing a correct & trustful information. So, i don't see how we could protect ourselves from malicious intents in this regard.
If you think in that way, then maybe its not worth it at all.
That was my point, Igor. Most Open Source projects have the license used on their website and a header with the license in each file. That's it. Plain and simple.
Ian.
2009/7/23 Ian Trudel ian.trudel@gmail.com:
2009/7/22 Igor Stasenko siguctua@gmail.com:
Right. Actually everythig , including author initials is built on top of a good will of one who filling/providing a correct & trustful information. So, i don't see how we could protect ourselves from malicious intents in this regard.
If you think in that way, then maybe its not worth it at all.
That was my point, Igor. Most Open Source projects have the license used on their website and a header with the license in each file. That's it. Plain and simple.
unfortunately, we don't have a kind of granularity named 'source file', where you can put the 2-3 kb size header with license comment . :) We have MC, .cs , .st , .pr , .source , .changes , .image (+ DeltaStreams will appear someday ) they are all files, but in detail, they could contain a mix of properly licensed & other code.
Ian.
2009/7/23 Igor Stasenko siguctua@gmail.com:
That was my point, Igor. Most Open Source projects have the license used on their website and a header with the license in each file. That's it. Plain and simple.
unfortunately, we don't have a kind of granularity named 'source file', where you can put the 2-3 kb size header with license comment . :) We have MC, .cs , .st , .pr , .source , .changes , .image (+ DeltaStreams will appear someday ) they are all files, but in detail, they could contain a mix of properly licensed & other code.
Naturally. I am just trying to put things into perspective here, if only for better understanding. Another important thing is that every developer working on community trunk MUST agree to commit with MIT license before being granted access to this repository.
The tests and inbox repositories are certainly different considering it has no access restriction. The license is clear to me and I have even suggested to be added to the manifesto, which was then added. But it's still necessary to read the manifesto in order to learn how to use the repositories.
Your idea to stamp classes with extra information is still interesting. It would have been great to stamp MC instead but they tend to include a lot more than only delta...
Ian.
On 2009-07-23 12:05, Igor Stasenko wrote:
2009/7/23 Ian Trudelian.trudel@gmail.com:
2009/7/22 Igor Stasenkosiguctua@gmail.com:
Right. Actually everythig , including author initials is built on top of a good will of one who filling/providing a correct& trustful information. So, i don't see how we could protect ourselves from malicious intents in this regard.
If you think in that way, then maybe its not worth it at all.
That was my point, Igor. Most Open Source projects have the license used on their website and a header with the license in each file. That's it. Plain and simple.
unfortunately, we don't have a kind of granularity named 'source file', where you can put the 2-3 kb size header with license comment . :) We have MC, .cs , .st , .pr , .source , .changes , .image (+ DeltaStreams will appear someday ) they are all files, but in detail, they could contain a mix of properly licensed& other code.
Shouldn't/ couldn't License be a object or trait that all object inherit from ? Or a method in Object that you must override to relicense ?
At the method level I'm not sure what to do....
Karl
Ian.
Am 22.07.2009 um 23:38 schrieb Ian Trudel:
Even a pop-up Window stipulating that the upcoming commit would be under MIT license with an "I agree" button would probably not stand any better. A paranoid mind could easily think that a malicious person could as well insert proprietary code and commit. That would be no easier to determine this until it blows into our face.
+1
Cheers, Bernhard
On Thu, 2009-07-23 at 00:28 +0300, Igor Stasenko wrote:
Hello list,
on a recent SOB meeting someone recalled the idea of adding a 'license' field to method stamps. I proposed this maybe a year ago, but at that time, it was seem to have a short life period, because of upcoming Spoon release, which contains a full method history and supports a much better organized method history/author/license tracking.
In our current state, when we have a /trunk , we need, however some kind of assurance that all submissions going to trunk is license-clean. So, it is like that proposed change gives us a quick & fast recipe how to assure that.
Please review the mantis entry: http://bugs.squeak.org/view.php?id=6993
And lets discuss openly, the pros and cons of this change.
Thanks for bringing this up Igor. After discussing it in the meeting I find I have questions and concerns about this proposal.
It is my understanding that once you load this change and then accept the license query that every method modification results in labeling the license of the method as MIT. Is there any way to override this?
Let's say I'm working on some code that is not license clean and am preparing to package it separately so it can be removed from the core image. In that work I may have to modify some methods to clarify the separation from other code. While doing so I'm tagging methods as MIT when in fact I may have no right to make that change.
As an alternate scenario let's say I'm developing a new proprietary product and decide I wish to test it with the most recent version of Squeak to be sure that I can release it using that version when it is ultimately released. I find a problem or two and fix them and save a new version of the package. Assuming at some earlier point I had installed the method stamp change and agreed to the MIT license and time went by and I simply forgot about it, then I could have just unintentionally mis-licensed my changes and not even be aware of it.
Also, don't class declarations need licensing?
Ultimately I believe that marking this at the method annotation level is entirely the wrong granularity and the wrong timing. In my opinion this should be done at the package level and at the point when a package version is saved or uploaded. Could we not add some annotation to packages for this and have the opportunity at the time when a package comment is recorded to make choices about licensing?
Ken
Am 22.07.2009 um 23:45 schrieb Ken Causey:
Ultimately I believe that marking this at the method annotation level is entirely the wrong granularity and the wrong timing. In my opinion this should be done at the package level and at the point when a package version is saved or uploaded. Could we not add some annotation to packages for this and have the opportunity at the time when a package comment is recorded to make choices about licensing?
+10
Cheers, Bernhard
Interesting idea.
Thoughts:
Maybe not in utilities, but in an author class, like Pharo. Check the pharo thread about author.
if it is free text, how do you harvest the same licenses mispelled (mit, MIT, Mit), or with spaces (Public license, Apache, APL, Apache Public License, ApachePublicLicense, etc)
What are the pros against the message of "everything commited to ... it is by default MIT" in a visible place on the repository.
Cheers, Miguel Cobá
On Wed, Jul 22, 2009 at 4:28 PM, Igor Stasenkosiguctua@gmail.com wrote:
Hello list,
on a recent SOB meeting someone recalled the idea of adding a 'license' field to method stamps. I proposed this maybe a year ago, but at that time, it was seem to have a short life period, because of upcoming Spoon release, which contains a full method history and supports a much better organized method history/author/license tracking.
In our current state, when we have a /trunk , we need, however some kind of assurance that all submissions going to trunk is license-clean. So, it is like that proposed change gives us a quick & fast recipe how to assure that.
Please review the mantis entry: http://bugs.squeak.org/view.php?id=6993
And lets discuss openly, the pros and cons of this change.
-- Best regards, Igor Stasenko AKA sig.
2009/7/23 Miguel Cobá miguel.coba@gmail.com:
Interesting idea.
Thoughts:
Maybe not in utilities, but in an author class, like Pharo. Check the pharo thread about author.
if it is free text, how do you harvest the same licenses mispelled (mit, MIT, Mit), or with spaces (Public license, Apache, APL, Apache Public License, ApachePublicLicense, etc)
it depends on our own policy, which we will introduce. If we state that we accepting a submissions only with 'MIT' (all capital) and reject all others, then rest is not our problem.
What are the pros against the message of "everything commited to ... it is by default MIT" in a visible place on the repository.
it gives us an another lever of control on submitted code in order to lessen the probability that submitted code will be under wrong license.
Cheers, Miguel Cobá
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Ian Trudel -
Igor Stasenko -
Karl Ramberg -
Ken Causey -
Miguel Cobá