[License-review] [Non-DoD Source] Re: L0-R WAS: moving to an issue tracker

[Karan, Cem F CIV USARMY RDECOM ARL (US)]

> -----Original Message-----
> From: License-review [mailto:license-review-bounces at lists.opensource.org] On Behalf Of Kyle Mitchell
> Sent: Tuesday, June 19, 2018 7:43 PM
> To: Josh berkus <josh at postgresql.org>
> Cc: License submissions for OSI review <license-review at lists.opensource.org>
> Subject: [Non-DoD Source] Re: [License-review] L0-R WAS: moving to an issue tracker
> 
> On 2018-06-19 16:06, Josh berkus wrote:
> > On 06/19/2018 04:12 PM, Kyle Mitchell wrote:
> > > There was lively debate on L0-R's OSD conformance, but most
> > > controversy focused on broader policy concerns.  I read repeatedly
> > > that policy would prevail: that OSI would not approve, even if the
> > > license were OSD-conformant, even if it had approved licenses with
> > > comparable features before.  By sheer endurance---many characters
> > > were typed---and some perseverance---the list went down for a
> > > spell---the group did manage two waves of focused comment directly
> > > on OSD.  But overall, policy stalked conformance and vice-versa,
> > > making each conversation much harder to have.
> >
> > L0-R is a great example of where some format other than email would
> > help a LOT.  Like, I can't tell you whether I personally approve of
> > the license at this point or not, because I've completely lost track
> > of what the current text is, and what the lawyers had to say about the
> > meaning of certain pieces of language.
> 
> FWIW, I tracked my own revisions to the license text in Git from before first submission.
> 
> Whether or not I _should_ be revising also came up in the discussion.  Given the time spent trying to batch up and post numbered
> revisions of both the license text and submission form, I have to admit that rankled.
> 
> In any event, both revision control and discussion make up the process.  It wouldn't do just to use Git, or just to use a message board
> or bug tracker.  And it wouldn't do to use either, if they didn't archive well.
> 
> Good to hear from you, Josh.
> 
> --
> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933

Actually, would argue that using a bug tracker (Git*) would actually be better than a discussion list; if we make each license its own project, then the issues within a project could be for individual questions/problems that need to be clarified for that particular license.  Anyone that wants to figure out what happened on a thread can just read the issue for that thread.  The only real problem I see is if people open up multiple issues on what is actually the same issue; AFAIK, neither GitHub nor Gitlab have a good method of merging issues together.   The mailing list would only be to announce new licenses and where to find their Git* repositories.  Once the text is finalized, it can be tagged in the original project.  If it is approved, then it can also be copied into a separate master project that contains all the approved licenses.

The only real issue I see with this is that if you want to keep up to date on a license, you will need to log into Git* and watch the license, otherwise you'll only get updates whenever you get around to logging into Git* and manually looking at the license text.

Thanks,
Cem Karan