Meeting log: "Meeting Chat" @ Sunday 5th of March 2017

[20:21:55] <Pretorian> Welcome to DCNF monthly meeting, it is 2017-03-05.
[20:22:00] <Pretorian> For simplicity sake, I will be the chairman and Crise has agreed to act as secretary.
[20:22:07] <Pretorian> What we do need is a head count, so just state your names. 
[20:22:09] <Pretorian> Pretorian
[20:22:12] <cologic> cologic
[20:22:59] <Crise> Crise
[20:23:03] <Pretorian> All right
[20:23:04] <Pretorian> There's a few items from the last meeting;
[20:23:11] <Pretorian> Migrate ASCIIDocs to Markdown (Pretorian)
Update DCNF web pages for affiliated projects (Pretorian, Crise)
Propose inclusion of affiliated projects (poy)
Setting up new affiliate project for information on DC projects (Crise, cologic, Pretorian)
Hublist project (Crise, Pretorian)
[20:23:18] <Pretorian> Item 1) Migration
[20:23:26] <Pretorian> This is done, the new files are in the repo.
[20:23:43] <Pretorian> *just the conversion*, I haven't done anything at all with the further.
[20:24:05] <Pretorian> They are the same as the sample I previously noted, Crise
[20:24:26] <Pretorian> I'm not sure if there's anything further to add here, now it's a matter of getting the web pages up, I think.
[20:24:39] <Crise> https://files.dcbase.org/conversion_test
[20:25:05] <Crise> I did some tests, however, as you can see the way pandoc handles table stuff is less than ideal
[20:25:27] <Pretorian> Hm, yeah, the tables look crappy.
[20:25:35] <Pretorian> Maybe that can just be manually updated?
[20:25:44] <Pretorian> If the rest is accurate.
[20:27:06] <Crise> as far as the tables are concerned, the rest is quite accurate (the yaml frontmatter not included)
[20:27:29] <Pretorian> <https://files.dcbase.org/conversion_test/ADC_strict.md> looks all right?
[20:27:44] <Pretorian> Well, better than <https://files.dcbase.org/conversion_test/ADC.md> at least
[20:27:55] <Crise> yeah it does but in that the tables are raw HTML
[20:28:03] <Pretorian> Ah.
[20:28:11] <Crise> because strict markdown does not technically support tables
[20:28:25] <Pretorian> So what do you propose shall be done?
[20:28:32] <Crise> having said that pandocs rendition of phpextra, that does support tables does the same thing
[20:30:04] <Crise> we can take the table markup from the rst version and manually convert it to the markdown syntax the site supports
[20:32:25] <Pretorian> Hm, if I check <https://files.dcbase.org/conversion_tes ... ource=view> then that's the same as is in the .rst file?
[20:33:05] <Pretorian> Tell me what files should be updated and I'll do so.
[20:33:21] <Pretorian> (Presumably the .xml file)
[20:33:59] <Pretorian> (oh, no, the .text file of course)
[20:35:15] <Crise> work on ADC_phpextra.md
[20:35:56] <Crise> that should have markdown closest to the one parsed on the site
[20:36:26] <Pretorian> All right.
[20:36:34] <Pretorian> Let's move on to the next item
[20:36:42] <Pretorian> Item 2) Update DCNF web pages for affiliated projects (Pretorian, Crise)

[20:36:52] <Pretorian> Which I guess is the same or at least a very related item.
[20:37:33] <Pretorian> Did you generate those md files by sucking in the .text file? Or?
[20:37:43] <Pretorian> (sucking in == referencing)
[20:38:58] <Crise> I created them from the dockbook xml
[20:39:04] <Pretorian> How?
[20:40:18] <Crise> pandoc -f docbook -t markdown_phpextra -s ADC.xml -o ADC.md
[20:40:33] <Crise> just change the -t argument to what you want
[20:40:54] <Pretorian> What do you propose is the appropriate way of updating the documents in the future? Directly updating the .md files or the XML or ?
[20:41:16] <Crise> the options related to markdown are: markdown markdown_github markdown_phpextra and markdown_strict
[20:41:24] <Crise> directly updating the md file
[20:41:51] <Crise> after all the whole point of markdown is to be human readable whereas the dockbook isn't
[20:42:04] <Pretorian> So we should really keep a md file in the adc repo and just reference that file in the adc-web repo.
[20:42:47] <Crise> pretty much yes
[20:42:56] <Pretorian> All right, will do so then.
[20:43:03] <Pretorian> What about the rest of the site(s)?
[20:43:33] <Pretorian> Will you do the base templates for those or shall i?
[20:45:28] <Crise> since it is just one page basically I might as well... however, once we get the main adc doc satisfactory we need to go through the same thing with the extensions doc
[20:45:42] <Pretorian> Yes, indeed.
[20:45:52] <Crise> as for the nmdc docs, I forgot how they are formatted
[20:45:56] <Pretorian> It's the same.
[20:46:32] <Pretorian> All right, you'll do it for the main doc done, and I can do it for the other documents once you are done.
[20:46:36] <Pretorian> Let's move on, if that's fine.
[20:46:49] <Pretorian> Item 3) Propose inclusion of affiliated projects (poy)
[20:47:01] <Pretorian> poy isn't here, so we need to postpone this item for this meeting as well...
[20:47:09] <Pretorian> Item 4) Setting up new affiliate project for information on DC projects (Crise, cologic, Pretorian)
[20:47:21] <Pretorian> This isn't really done, I guess.
[20:47:55] <Crise> well I did set up the subdomain just now, but other than that nope
[20:47:59] <Pretorian> It'll be more clear what we should do when we've got the ADC/NMDC pages up.
[20:48:01] <Pretorian> all right, good.
[20:48:04] <cologic> Right, at least on my end -- I've not done much with that.
[20:48:36] <Pretorian> I guess we need to formalize the process, potentially having something automagic?
[20:49:11] <Pretorian> Oh, well, let's make sure we know what needs to be done, WRT web pages (markdown files) etc, before progressing.
[20:49:24] <Pretorian> Let's move on
[20:49:30] <Pretorian> Item 5) Hublist project (Crise, Pretorian)
[20:49:44] <Pretorian> I have begun this project, at <https://hublist.dcbase.org/>
[20:50:04] <Pretorian> A few things are set up at <https://gitlab.com/dcnf/hublist>
[20:50:18] <Pretorian> Particularly the <https://gitlab.com/dcnf/hublist/tree/master>
[20:50:25] <Pretorian> <https://gitlab.com/dcnf/hublist/blob/ma ... st-ref.xml>
[20:50:58] <Pretorian> It is my intention that that XML file shall be available through hublist.dcbase.org/hublist-ref.xml for clients.
[20:52:40] <Pretorian> Additionally, the ability for hublist owners to upload and update their own hublist
[20:52:54] <Pretorian> So we can serve the individual hublists ourselves (in a backup of sorts).
[20:53:31] <Pretorian> The way forward, I think, is to allow access for the website part to the aforementioned file, and then it's a matter of updating clients.
[20:54:25] <Pretorian> I guess people could use <https://gitlab.com/dcnf/hublist/raw/mas ... st-ref.xml> in the interim? Or just have a redirect from hublist.dcbase.org/hublists
[20:54:34] <Pretorian> What do you think?
[20:55:34] <Crise> what do you mean specifically by the ability to upload their own hublists
[20:55:57] <Pretorian> I mean the ability for people to upload the actual hublist xml(.bz2) file.
[20:56:15] <Pretorian> By "people" I mean approved people, of course.
[20:56:24] <Crise> ok
[20:56:40] <Pretorian> But maybe that's venturing into control territory (cologic)?
[20:58:41] <Pretorian> If above is acceptable, and the format is decent (for now), I'll try and get in touch with poy to have it actually implemented.
[20:59:16] <cologic> Arguably, yeah.
[20:59:33] <cologic> But I'm not sure more than exists now.
[20:59:54] <Pretorian> What we can do is set up the framework and eventually pull the plug should an actual issue arise.
[21:00:07] <cologic> Seems like a good approach.
[21:00:18] <Pretorian> All right.
[21:00:20] <Pretorian> Let's move on
[21:00:35] <Pretorian> That concludes all the items from the previous meeting.
[21:00:40] <Pretorian> Does anyone have any additional items that they thought of?
[21:00:45] <Pretorian> Pretorian-1: Tax papers
[21:01:08] <Pretorian> Pretorian-2: Mail from FSFE.
[21:01:44] <Pretorian> (I'll leave a minute or so, so people can state additional items)
[21:01:47] <cologic> cologic-1: RSS feeds
[21:02:36] <Crise> crise-1: letsencrypt challenge error
[21:02:57] <Pretorian> All right, let's go in order.
[21:03:03] <Pretorian> Pretorian-1: Tax papers
[21:03:13] <Pretorian> I have received the tax papers for this year (well, it applies for 2016).
[21:03:20] <Pretorian> They need to be filed July 3rd
[21:03:25] <Pretorian> So there's essentially no rush.
[21:03:45] <Pretorian> But it'll be basically the same as last year, just filling in the amount of fees/donations.
[21:04:09] <Pretorian> I'll try and have it filled in until the next meeting and have it uploaded on the site.
[21:04:34] <Pretorian> We didn't receive any note/mesasge from the authorities last year, so I think the previous year's approach was fine.
[21:04:56] <Pretorian> Unless there's comments, let's move on to the next one
[21:05:02] <Pretorian> Pretorian-2: Mail from FSFE.
[21:05:20] <Pretorian> We *did* receive a mail from FSFE regarding the license questions we had, the full message is as follows
[21:05:35] <Pretorian>  Dear Fredrik,

Thank you for reaching out to us! We apologise for such long delay in
the response to you. Please note that the FSFE is a non-profit
organisation which has no capacity, nor is allowed to give legal advice.
For a more detailed analysis of your situation, please refer to a
respective legal professional in your jurisdiction.

I, nevertheless, try to give you some general guidance on the specific
questions you asked (see in line below).

On 08.01.2017 13:55, Fredrik Ullner wrote:
> We have a website, dcbase.org <http://dcbase.org>, for a non-profit
> organization, Direct Connect Network Foundation (DCNF). The website and
> (most of) its content is available on a (public) Git repository that we
> can automatically publish from (using Bootstrap/Twig). The current
> software we use is licensed under the Creative Commons license (v3.0)
> and GNU GPL (v2). We have noted on our website what content/software we
> use ( https://www.dcbase.org/style/ ). We also have a page with the
> actual license references ( https://www.dcbase.org/DCBase/LICENSE ),
> with noted exemptions.

- [...]

> Can you tell us whether our current setup is acceptable, license-wise?
> It'd be greatly appreciated if you can also review our license
> description, available on the /style/ page linked above? Additionally,
> if you can tell us whether the license exceptions as posted, are legally
> sound.

As I can understand from the set up above, the software underlying your
website is licensed under GPL v.2, while some of the content generated
for the website might be licensed under CC BY 3.0.

In such set up, there is no problem between these two licenses, as these
are compatible with each other[^1], as long as the CC licence is not
used for software. However, it may be worth of stating that GPL in
general can also be used for general data which is not software, as long
as one can determine what the definition of “source code” refers to in
the particular case.

Can you please kindly specify what do you mean by website "style" being
licensed under CC BY 3.0? The design of the website or the underlying
code? Or...?

> 1)As I mentioned, we automatically publish using Twig template files,
> and we are unsure of whether that constitutes as “program input”. Do you
> mind clarifying whether this is ok or not ok?

According to the licence exception, Twig templates are covered by GPL.
The content that is used as input in these templates and the output
these templates generate to display the content are not covered by GPL.
In general, copyright of the program does not automatically extend to
the output that program generates, unless substantial parts of the
output are copied from text in the program[^2].

> 2)The CC license applies to the style of the website, not the content.
> However, we have a copy of the content published together with the
> style. Does that mean that the CC-license applies to the content as well?

The licence should be attached in a way which allows any potential user
to recognise the work or an entire publication as being licensed under a
particular CC licence. You should specify in the licence notice that the
licence is only covering the style of the website, and does not refer to
the whole publication.

Please let us know if you have any additional questions.

Best regards,
Polina

- [^1]: https://www.gnu.org/licenses/license-list.html#ccby
- [^2]: https://www.gnu.org/licenses/gpl-faq.en.html#GPLOutput

[21:06:00] <Pretorian> I'm unsure whether we need any additional questions/follow up, Crise?
[21:06:59] <Pretorian> Crise: Maybe you can read through the response at your own pace (at a later time) and feed me any potential follow up questions (unless you had any specific comments right this moment).
[21:07:07] <Pretorian> (so I'll forward them)
[21:07:08] <Crise> I will read it through properly, but after a cursory glance that should be all we need
[21:07:13] <Pretorian> Great.
[21:08:13] <Pretorian> I have just now forwarded the mail, in case you want to address them yourself (otherwise I'm happy to be the middle man).
[21:08:19] <Pretorian> Let's move on.
[21:08:29] <Pretorian> cologic-1: RSS feeds
[21:08:31] <Pretorian> cologic?
[21:09:25] <cologic> Yes, so I have a small script which reads, orders by time, and outputs (currently in an arbitrary format, but could just as easily be JSON, some kind of XML, etc) project feeds.
[21:09:58] <cologic> I'm not sure how Crise wants to integrate this into the website and thus what approach works most conveniently for him. Crise?
[21:11:11] <Crise> well ideally the script would be smart enough to group multiple files from the same project into a sub array (and yes json is the ideal format)
[21:11:43] <cologic> Okay, JSON it is.
[21:12:08] <Crise> the best case scenario would be if we can reliably also parse version information but that might be a little tricky considering the feeds themselves are not set up for that
[21:13:02] <cologic> When you say multiple files -- the atomic units it can easily deal with are either (1) RSS feeds; (2) RSS posts; or (3) human-defined aggregations of RSS feeds corresponding to a project. (4) some kind of version parsing, etc would be possible, too, just slightly less trivial (which to be clear is fine; this is a very short script as-is).
[21:14:33] <Crise> well the desired format for the multidimentsional array would be project > version > files, so three levels deep, with associative keys for the first two... but the version could be dropped if it proves complicated
[21:14:59] <cologic> Okay, so the main thing of interest here is actual releases of software?
[21:15:41] <Crise> yeah... I think that if we want blog posts etc. that can be a different script that just dumps rss feed that only contains that stuff
[21:16:08] <cologic> Okay, that seems reasonable.
[21:16:33] <cologic> Alright, I'm happy to move on if no one else has things they want to add on this topic.
[21:16:45] <Pretorian> The current Twitter feed is (well, was) basically just posting releases (and the occasional blog post).
[21:17:05] <cologic> Right, most of the feeds I have from there and elsewhere do.
[21:17:15] <cologic> But a couple are just blogs -- e.g., the DC++ blog.
[21:17:41] <Pretorian> The Kinniku bot in here (from Yorhel) posts also here (including the forum).
[21:17:47] <Crise> we probably want to keep releases and blog posts in separate units if we can manage that so we don't have mixed content json objects for the site to parse
[21:17:53] <cologic> Yeah, that's easy enough.
[21:18:10] <cologic> And that aspect of website integration is why I wanted to make sure I asked Crise.
[21:18:51] <Crise> the site (ie. Twig) can do loops and conditionals easy enough but complex parsing would require specific logic implemented in php
[21:19:26] <Pretorian> Would it also be possible to aggregate everything on a similar feed on the site, so other people can develop their own feed?
[21:19:29] <cologic> So just ensure any complex parsing stays in the RSS feed side.
[21:19:43] <cologic> Sure.
[21:20:43] <cologic> It's mostly a question of (a) which feeds to include (easily parameterized); and (b) what sort of processing to do on them (currently, basically either version/file specific or none).
[21:21:11] <Pretorian> Any form of software you develop should ideally be published, as well.
[21:21:41] <cologic> Makes sense. Is there a preferred location/repository for that sort of thing, DCNF-related?
[21:22:03] <cologic> (But not, specifically, ADC, NMDC, etc.)
[21:22:20] <Crise> well considering it is website related script, one way to do it would be just to manage it under a scripts directory in the website repo
[21:22:35] <Pretorian> I'd otherwise say that it's an affiliated project?
[21:22:56] <Crise> if it is a substantial enough piece of code yes
[21:23:09] <cologic> It's probably not, at least currently. Just one file.
[21:23:12] <Pretorian> Is it specifically tied into DC software? Or can it be generalized for other purposes?
[21:23:33] <cologic> Generalized, I guess. I've seriously considered using it for my own purposes, non-DC-related.
[21:23:48] <Pretorian> I mean, the affiliated projects should primarily be DC related but I guess anything that the foundation produces or directly support should be an affiliated project.
[21:23:50] <cologic> Not hard to do, but nothing quite out there that I'd been looking for.
[21:24:30] <cologic> But it's on the order of dozens of lines of code, because it just pulls in an external RSS feed library. It's simply not much there.
[21:25:22] <Pretorian> Ok, well, I guess you can decide for yourself, but maybe at least separate it with a config file (with the addresses of the feeds) and a source code file.
[21:25:34] <cologic> I'm fine with either the website repo or as an affiated project, but it sounds like the affiliated project setup isn't necessarily quite there yet.
[21:25:50] <cologic> Indeed.
[21:25:57] <Crise> if you think it has enough substance for its own code repository and potentially a sub website then it should be an affiliate project, otherwise we can manage the code as part of the main website code
[21:26:12] <Crise> but it is obviously your call
[21:26:26] <cologic> Yeah, something to conclude after this meeting, probably, either way.
[21:26:31] <Pretorian> Yup.
[21:26:47] <Pretorian> Up to you cologic.
[21:26:49] <Pretorian> Let's move on.
[21:27:02] <Pretorian> crise-1: letsencrypt challenge error
[21:27:05] <Pretorian> Crise?
[21:27:40] <Crise> so yeah, I have been trying to add the subdomains... so far one of them verified fine the other not so much
[21:28:13] <Crise> if cologic could check the CSR config file and try going through the process and explain where I went wrong
[21:28:29] <cologic> Will do, yes.
[21:28:57] <cologic> The key thing is "Having created a CSR, one then needs to ensure Let’s Encrypt knows where to find it. The ACME protocol Let’s Encrypt uses specifies that this should be /.well-known/acme-challenge/" from the blog post.
[21:28:57] <Crise> because right now after running the renewal script it chockes on projects.dcbase.org (and the challenges directory is empty)
[21:30:04] <cologic> The renewal script knows nothing about putting the CSR anywhere. That's entirely manual (because it only has to be changed when updating subsites, etc, anyway).
[21:30:20] <cologic> It just assumes that LE can find the CSR in /.well-knwon/acme-challenge/
[21:30:24] <Crise> yeah, I generated the CSR already
[21:30:25] <cologic> *well-known
[21:30:56] <Crise> yeah and that should be set up
[21:31:54] <cologic> So that's the question, whether http://projects.dcbase.org:80/.well-kno ... challenge/ ends up containing the nonce (basically) that LE looks for.
[21:32:01] <cologic> I'll verify if/how this is happening.
[21:32:20] <Crise> wtf, I got errors on it for the better part of this meeting, now I just tried it and it runs clean
[21:32:25] <cologic> Huh.
[21:32:28] <Crise> no issue
[21:32:43] <cologic> That's good, I guess, though I'm wary of magical auto-fixes.
[21:32:48] <cologic> Because they can auto-break later.
[21:32:58] <Crise> I am with you
[21:34:05] <Crise> could cloudflare being on strict SSL mode during the certificate verification process have a bearing on it
[21:34:31] <cologic> Yeah, definitely -- any MitMing will potentially throw it off. If nothing else, create a delay.
[21:35:26] <Crise> that might be it then, as I switched it from strict to just plain full some time ago, but guess there is something that creates a delay for the dns being valid
[21:35:52] <Crise> switched because of the initial error, will obviously switch back now
[21:35:57] <Crise> and keep an eye on it
[21:36:23] <cologic> Yeah, still nice to have that fallback option to keep the site sort-of working in case TLS glitches.
[21:39:39] <Crise> anyways, for now that is that then on this subject
[21:39:49] <Pretorian> All right.
[21:39:56] <Pretorian> Does anyone have any additional items that they thought of?
[21:40:21] <cologic> I have nothing further, no.
[21:40:25] <Pretorian> (I have no further items)
[21:40:44] <Crise> not at this time... will fix the hublist submodule on git though :)
[21:40:49] <Pretorian> Great
[21:40:50] <Pretorian> Next meeting items;
1) Fix Markdown file issues (Pretorian)
2) Update DCNF web pages for affiliated projects (Pretorian, Crise)
3) Propose inclusion of affiliated projects (poy)
4) Setting up new affiliate project for information on DC projects (Crise, cologic, Pretorian)
5) Tax papers
[21:40:56] <Pretorian> If there's nothing further, that concludes this meeting. Thank you all.