[ocaml-infra] ocaml.org licensing

Fri Feb 28 18:35:18 GMT 2014

On 28 Feb 2014, at 17:30, Ashish Agarwal <agarwal1975 at gmail.com> wrote:

> Thanks everyone for the many useful comments. We've reached consensus on most points, but here are a few that remain:

Thanks for collating these!

> 
>> On Mon, Feb 10, 2014 at 9:40 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
>> ...
>> My only substantive comment is perhaps point D), regarding the copying of ocaml.org.  We should probably make it sufficiently permissive to allow people to build their own forks of ocaml.org, which would currently be forbidden under the terms described below.  Perhaps a clarification (somehow) or restriction (non-commercial use?) would suffice here without confusing matters too much.
> 
> In my opinion, forks should be discouraged. I agree with Fabrice that 10 websites on OCaml would be great, but not if they are forks of ocaml.org. Different websites should be genuinely different.

I concur.

>> On Mon, Feb 10, 2014 at 6:21 PM, Florent Monnier <monnier.florent at gmail.com> wrote:
>> 
>> (A) Content is released under CC BY-SA version 4.0 or above
> 
> I'm okay with this, and IIRC GPL has this encoded within the license itself. Amir, you expressed the concern that newer versions of CC-BY-SA might not be backwards compatible, making this complicated. However, I doubt a license would be incompatible with its own previous versions.

Things do change within licenses and for one that's had as much consideration and development as the the CC licences, I'm really not keen on changing any of the wording.  Especially as they themselves keep each version separate.  We don't know what we might be opening ourselves up to nor for what benefit.  

Please note that backward compatibility is only one potential problem we may encounter.  It's not possible for me (nor anyone else) to enumerate *all* the potential downsides and it's not clear what the upside is either.  We'd get to use 5.0, then 6.0? Bear in mind that 4.0 would still also apply.

As you yourself say below, "each little word has been thought about by the license's authors, and it has real ramifications" ;) -- I know you're referring to the legal content of the license but I think it's just as applicable to how licenses are applied.

You can get a quick overview of changes between CC licenses from the link below.
http://wiki.creativecommons.org/License_versions

Perhaps I'm being overcautious here but I really don't see any upside to adding "or above" to the licensing scheme, whereas we give ourselves a bunch of "unknown unknowns" if we do.

>>> > (D) Design of the site. All rights reserved by the OCaml.org project.
>> 
>> I would suggest to replace the word "design" by "style guide" or
>> "style manual", because for French speaking people it's quite
>> ambiguous
> 
> In fact, we'll apply this license to specific text or images, so what it applies to won't be ambiguous.
> 
> 
>> Another case, what about people willing to reuse the current "design"
>> of ocam.org far long time after ocaml.org doesn't use this current
>> visual style anymore? you know like all the fan website of nostalgics.
> 
> I'd rather ignore this issue. I think "fair use" rules may apply, which would allow copying for certain reasons anyway. Also, it's very hypothetical. Such permission can be granted when it is requested. Similarly, I'd like to ignore the issue of using small parts of the CSS. It's no one's intention to prevent that, but figuring out how to legally allow it would be one extra complication. Again, I think "fair use" rules might allow it anyway (I'm not sure).
> 
>  
>>> > (E) OCaml logo is released under the UNLICENSE [3].
>> 
>> The UNLICENSE license is a licence for softwares.
>> A logo is not a software.
>> I would suggest to replace in the text of the UNLICENSE license the
>> word "software" by "piece of work"
> 
> I'm hesitant to modify licenses. Often, each little word has been thought about by the license's authors, and it has real ramifications. Thus, should we instead use CC0 for the OCaml logo?

To avoid doubt, I'm fine with either the modified UNLICENSE or CC0.  CC0 is probably 'fit-for-purpose' in this case.

The Unlicense itself is somewhat pieced together based on SQLite and the MIT no-warrantly [1].  It has it's critics but the intent is clear.  As such, each word has not really been thought about so I have very few concerns about changing one of them to make it broader (we'd *only* be applying it to the logo).  Having read far too much about licenses a few weeks ago, I decided that the most important thing was whether a well-intentioned human would understand the meaning (hence suggesting the Unlicense for code samples).

The CC0 [2] wasn't written specifically for software but it attempts to 'fall-back' in the case that putting something in the public domain isn't straightforward.  It's a lot more verbose than the unlicense but perhaps it's better in this case (for the logo).

[1] http://ar.to/2010/01/dissecting-the-unlicense
[2] http://creativecommons.org/publicdomain/zero/1.0/legalcode

ac

> 
> On Fri, Feb 28, 2014 at 11:36 AM, Gabriel Scherer <gabriel.scherer at gmail.com> wrote:
> On Fri, Feb 28, 2014 at 4:33 PM, Amir Chaudhry <amc79 at cam.ac.uk> wrote:
> > Provided it can be done in an automated manner, I don't mind having one page on the site, even if some of the names looks odd.   I'd mention at the top that it's generated from the git log and I wouldn't worry too much about people with different names.  I'm more keen on keeping things automated, even if they're not perfect.
> >
> > To be more specific, I'd put the output of the following on a page (with additional text as above).
> > $ git log --format="%aN" | sort | uniq
> >
> > I count about 50 or so contributors (allowing for duplicates).
> 
> In order to list the Batteries contributor on the slides of a talk, I
> created a .mailmap file. Placing this in the root of the project will
> let git know about duplicates and the "proper name" (and mail adress)
> to use for any given person.
> 
> The format is documented in "git help shortlog", section MAPPING
> AUTHORS. There are various variants, I only used "name <mail> name
> <mail>", with the semantics of "whenever you see the stuff on the
> right, count it as if it came from the person on the left". Relevant
> quote with mail adresses blurred:
> 
> Philippe Veber <philippe.veber at ...> pveber <philippe.veber at ...>
> Philippe Veber <philippe.veber at ...> Philippe <pveber at ...>
> Eric Norige <thelema314 at ... thelema <thelema at ...>
> David Teller <David.Teller at ...> Yoric <David.Teller at ...>
> David Teller <David.Teller at ...> yoric <yoric at ...>
> 
> This is still a manual process, in the sense that I manually iterated
> the process of running the author-listing command, then adding any
> remaining duplicates / redundant nicknames to the .mailmap file. And I
> guess this will need doing again in a few months/years, for the new
> contributors that joined since.
> 
> 
> On Fri, Feb 28, 2014 at 4:33 PM, Amir Chaudhry <amc79 at cam.ac.uk> wrote:
> >
> >
> > On 28 Feb 2014, at 14:28, Christophe Troestler <Christophe.Troestler at umons.ac.be> wrote:
> >
> > > On Thu, 27 Feb 2014 10:39:38 +0000, Anil Madhavapeddy wrote:
> > >>
> > >> On 27 Feb 2014, at 10:35, Fabrice Le Fessant <Fabrice.Le_fessant at inria.fr> wrote:
> > >>
> > >>> Ok, so if we only focus on licensing, I would like to have licenses
> > >>> attached to directories in the GIT directory, i.e. make it easy to
> > >>> know which file is under which license. It is especially important for
> > >>> point (D): whoever wants to customize its own version of the website
> > >>> (for example, for a version of the website translated to another
> > >>> language), but with a different design (with flags, for example :-) ),
> > >>> should know immediatly the parts that shouldn't be used on the new
> > >>> website, and have to be replaced.
> > >>
> > >> I agree with this.  Although it makes the source files uglier, I also
> > >> prefer having an explicit license per-file, since this eases copying
> > >> individual source modules into other projects.  (This doesn't apply to
> > >> documentation, just source code).
> > >
> > > Maybe we can even add the license as a couple of lines to the top of
> > > each file (so it is immediately clear what it is if one presses the
> > > "edit" button).  For example, for .md files, this could be
> > >
> > > <!-- Content is under CC BY-SA 4.0, Code examples under UNLICENSE.
> > >     See LICENSE.md for more details. -->
> > >
> > > "headache" could do most of the work for us.
> >
> > Firstly, I agree that having license info at the top of each source file is better.  It becomes more clearly visible for people who are contributing solely via the web-based workflow (we've had a number of those now).
> >
> > Secondly, what's "headache"?
> >
> > Finally, although this is not purely a licensing issue, I'm concerned about the comment "whoever wants to customize its own version of the website ...".  If this a reference about people (already) wanting to fork the site and maintain other versions then I'm quite concerned.  Licensing shouldn't prevent content re-use but this sounds like the opposite of building a community.
> >
> >
> > >>> Otherwise, I think we (OCamlPro) are good with the current licensing policy.
> > >>
> > >> Great!
> > >
> > > Glad that we are moving forward!
> >
> > Excellent! Thanks.
> >
> > >
> > >>>> The question of *who* the contributors are is very
> > >>>> straightforward as we have git logs of all activity [1].  You can
> > >>>> even see this per page if you wish [2].
> > >>>
> > >>> I think contributors deserve a better place on the website than being
> > >>> in a GIT log. Having a credit page listing all the contributors would
> > >>> be enough. It would be easy for anybody that contributes to add his
> > >>> own name to that page in the same pull-request as the content being
> > >>> pushed.
> > >>
> > >> This will get out of date pretty fast, and also results in a lot of merge
> > >> conflicts if there are multiple outstanding requests.  I recommend just
> > >> autogenerating it using Thomas' Git implementation
> > >> (http://github.com/samoht/ocaml-git).
> > >
> > > We also have not to forget the people¹ who contributed to the
> > > tutorials and who do not appear in the Git log.  Also note that some
> > > people appear several times with different names and some other use
> > > abbreviations that may not be clear (e.g., "MM", "lehy", "mrnt0810").
> > > For the git log, as long as the contribution is good, I do not care
> > > much but for an acknowledgment page, it may look funny.
> >
> > Provided it can be done in an automated manner, I don't mind having one page on the site, even if some of the names looks odd.   I'd mention at the top that it's generated from the git log and I wouldn't worry too much about people with different names.  I'm more keen on keeping things automated, even if they're not perfect.
> >
> > To be more specific, I'd put the output of the following on a page (with additional text as above).
> > $ git log --format="%aN" | sort | uniq
> >
> > I count about 50 or so contributors (allowing for duplicates).
> >
> > Best wishes,
> > Amir
> > _______________________________________________
> > Infrastructure mailing list
> > Infrastructure at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/infrastructure
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at lists.ocaml.org
> http://lists.ocaml.org/listinfo/infrastructure
> 