[squeak-dev] A license in method/comment stamps

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.

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


--
http://mecenia.blogspot.com/

On Thu, 2009-07-23 at 00:28 +0300, Igor Stasenko wrote: 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

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 Stasenko<[hidden email]> wrote:

On Wed, Jul 22, 2009 at 4:38 PM, Ian Trudel<[hidden email]> wrote:

2009/7/23 Miguel Cobá <[hidden email]>:
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á
>
>




--
Best regards,
Igor Stasenko AKA sig.

2009/7/23 Ian Trudel <[hidden email]>:
> 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).

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.




--
Best regards,
Igor Stasenko AKA sig.

2009/7/22 Igor Stasenko <[hidden email]>:
> 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.


--
http://mecenia.blogspot.com/

2009/7/23 Ian Trudel <[hidden email]>: 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.
>
>
> --
> http://mecenia.blogspot.com/
>
>



--
Best regards,
Igor Stasenko AKA sig.

2009/7/23 Igor Stasenko <[hidden email]>:
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.

--
http://mecenia.blogspot.com/

On 2009-07-23 12:05, Igor Stasenko wrote:

2009/7/23 Ian Trudel [hidden email]:
  

2009/7/22 Igor Stasenko [hidden email]:
    

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.


--
http://mecenia.blogspot.com/


    

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