[Incubator] Oskari incubation
Aarnio Timo (MML)
timo.aarnio at maanmittauslaitos.fi
Thu Nov 12 05:56:46 PST 2020
Hi Incubators!
We would like to further our incubation if we can recognize challenges blocking it. After the last communication a lot has obviously happened and we’ve e.g. released Oskari 2.0. The EUPL and MIT licenses are currently shipped with Oskari and the prebuilt sample application binary. I.e. the licenses can be found in
1. Maven’s pom.xml https://github.com/oskariorg/oskari-server/blob/master/pom.xml#L21-L34
2. the frontend’s package.json https://github.com/oskariorg/oskari-frontend/blob/master/package.json#L18
3. Repositories in GitHub all have a LICENSE-file in the SPDX-format
4. Sample application package https://download.osgeo.org/oskari/oskari-latest-stable.zip (has license documentation included)
Is this enough or do we need to be more specific? We compared the GeoTools and GeoServer ways of listing licenses and they seem to differ quite a bit. GeoServer https://github.com/geoserver/geoserver/blob/master/LICENSE.txt seems to have a complete listing of licenses whereas GeoTools https://github.com/geotools/geotools/blob/master/LICENSE.md only has the LGPL. We adopted the SPDX-way so that the LICENSE-file would be machine readable. Do you suggest we proceed by collecting a list like is done with GeoServer? If so should we list licenses for dependencies as well?
Are there other things we could do to help the progress of our incubation?
Best regards,
Timo
From: Incubator <incubator-bounces at lists.osgeo.org> On Behalf Of Aarnio Timo (MML)
Sent: Tuesday, October 29, 2019 12:42 PM
To: Jody Garnett <jody.garnett at gmail.com>
Cc: OSGeo-incubator <incubator at lists.osgeo.org>
Subject: Re: [Incubator] istSOS incubation (Oskari)
Thank you for your input Jody!
As I understand the minimum we should do is include the EUPL (and MIT) license in the Jetty-distribution we have. Googling for ways to do that I came up with these:
https://softwareengineering.stackexchange.com/questions/181040/how-to-document-a-dual-open-source-license
https://en.wikipedia.org/wiki/Software_Package_Data_Exchange
Is there an “OSGeo recommended” way of handling this? Particularly the “SPDX Way” mentioned here
https://softwareengineering.stackexchange.com/questions/181040/how-to-document-a-dual-open-source-license#371456 looks good to me, what do you think?
Kind regards,
Timo
(PS. My apologies Jody, in the morning I sent the above message only to you by mistake. I also added the word Oskari to the subject-line to more easily recognize these messages.)
From: Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>>
Sent: tiistai 15. lokakuuta 2019 8.37
To: Aarnio Timo (MML) <timo.aarnio at maanmittauslaitos.fi<mailto:timo.aarnio at maanmittauslaitos.fi>>
Cc: OSGeo-incubator <incubator at lists.osgeo.org<mailto:incubator at lists.osgeo.org>>; Massimiliano Cannata <massimiliano.cannata at supsi.ch<mailto:massimiliano.cannata at supsi.ch>>
Subject: Re: istSOS incubation
I am going through the same steps I would when evaluating a software project to use in a professional setting. In practice many folks evaluate your software each year, we just have the ability to talk about it here and see what we can do to make it easier for parties to use your work.
However, to best honest *me* providing a review is not so helpful, ... the goal is for your team to go through the codebase you are shipping and evaluate it critically. Do you communicate that the source code is open source, under what terms, especially when redistributing the work of others etc... Are you meeting the distribution terms, etc...
The examples I quickly found it gave the impression that your team was inconsistent, which if I was evaluating the technology would be a warning to me that there is some risk of a mistake being made etc...
You have a specific question about what needs to be included: In this case I really must defer to your team which is aware of the licenses you are working with. Many of them have terms requiring the license be included in source code and binary distributions.
Perhaps start with that EUPL license? If I search for the word "distribute" It has clear instructions as its first obligation for your team:
Attribution right: The Licensee shall keep intact all copyright, patent or trademarks notices and all notices that refer to the Licence and to the disclaimer of warranties. The Licensee must include a copy of such notices and a copy of the Licence with every copy of the Work he/she distributes or communicates. The Licensee must cause any Derivative Work to carry prominent notices stating that the Work has been modified and the date of modification.
How are you meeting this?
--
Jody Garnett
On Mon, 30 Sep 2019 at 22:58, Aarnio Timo (MML) <timo.aarnio at maanmittauslaitos.fi<mailto:timo.aarnio at maanmittauslaitos.fi>> wrote:
Dear Jody & incubator-list,
Many thanks for you comments and sorry for letting this slip on a break again! Here are hopefully some answers and at least clarifying questions:
- We have not conducted a providence review other than what has been stated below “(All code has been developed by the registered developers listed on github who have signed the CLA. All external libraries have project compatible licenses. The project has been started as a regular Open Source project following the guidelines as set out by OSGeo. A file-per-file code review was therefore deemed superfluous.)”
- Can you clarify which details are such that should be included in each distribution? I feel like this could be something we could rather easily meet if we don’t already.
- I presume you are talking about the jetty-package we ship for each release with the WAR. I can look into that, there most probably should be a LICENSE-description included!
- As for the headers in Java source code files, I cannot say I’m a 100% on this but I remember there being some kind of discussion that ended to the conclusion that they are not needed. At least if we add them it’ll look funny on GitHub as all of the .java files will have changes. Not that it couldn’t be done though, if you think it is necessary?
- SMAKINEN is Sami Mäkinen, our architect :) on GitHub his nickname is ZakarFin and SMAKINEN is his username in our organization.
- headers for properties file(s) is something we can also look at, I’ll discuss this with Sami among others in the project
In FOSS4G Bucharest we had a nice discussion with Astrid Emde about OSGeo Live, not going into details now, but that’s something we might actually be interested in as well later on.
Again, many thanks for your help!
BR,
Timo
From: Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>>
Sent: tiistai 25. kesäkuuta 2019 0.34
To: Aarnio Timo (MML) <timo.aarnio at maanmittauslaitos.fi<mailto:timo.aarnio at maanmittauslaitos.fi>>
Cc: OSGeo-incubator <incubator at lists.osgeo.org<mailto:incubator at lists.osgeo.org>>; Massimiliano Cannata <massimiliano.cannata at supsi.ch<mailto:massimiliano.cannata at supsi.ch>>
Subject: Re: istSOS incubation
That checklist looks good, for Providence review it has the following:
[x] Provenance Review (All code has been developed by the registered developers listed on github who have signed the CLA. All external libraries have project compatible licenses. The project has been started as a regular Open Source project following the guidelines as set out by OSGeo. A file-per-file code review was therefore deemed superfluous.)
This was a really well done codebase to review and look at - nice work :)
Do you have a link to the providence review? Like if I look at the codebase in GitHub I can quickly find:
- LICENSE.md<https://github.com/oskariorg/oskari-server/blob/master/LICENSE.md> file links to EUPL v1.1<https://joinup.ec.europa.eu/software/page/eupl/licence-eupl>, but this license (which was news to me) as some details on what must be included in each distribution, can you say how they are being met?
- one of the distributions appears to be generation of a WAR<https://github.com/oskariorg/oskari-server/blob/master/webapp-setup/pom.xml#L12> in webapp-setup, this would be an example where the above LICENSE details should be included?
- when I quickly looked at java files none of them had<https://github.com/oskariorg/oskari-server/blob/76b78cacfddc39800f4d3af35df8760d096b5737/control-userlayer/src/main/java/org/oskari/control/userlayer/CreateUserLayerHandler.java> a<https://github.com/oskariorg/oskari-server/blob/76b78cacfddc39800f4d3af35df8760d096b5737/control-routing/src/main/java/fi/nls/oskari/control/routing/RoutingHandler.java> header<https://github.com/oskariorg/oskari-server/blob/76b78cacfddc39800f4d3af35df8760d096b5737/servlet-map/src/main/java/fi/nls/oskari/spring/OskariRequestInterceptor.java> indicating copyright and license. Can you talk us through why you made this decision?
- looking at a specific example WebappHelper<https://github.com/oskariorg/oskari-server/blob/76b78cacfddc39800f4d3af35df8760d096b5737/service-webapp/src/main/java/fi/nls/oskari/servlet/WebappHelper.java> (that looked generic) I see the user "SMAKINEN" does not appear similar to any contributors listed in the file commit history<https://github.com/oskariorg/oskari-server/commits/76b78cacfddc39800f4d3af35df8760d096b5737/service-webapp/src/main/java/fi/nls/oskari/servlet/WebappHelper.java> ....
/**
* Created by SMAKINEN on 8.7.2015.
*/
public class WebappHelper {
- properties file may be considered executable code, do you want a header indicating license?
- I was impressed to see header preserved when building off of prior work<https://github.com/oskariorg/oskari-server/blob/76b78cacfddc39800f4d3af35df8760d096b5737/geoserver-ext/OskariMarkFactory/src/main/java/org/geotools/renderer/oskari/TTFMarkFactoryOskari.java>, but that ends up confusing when you do not have a header of your own ...
- various build files, example pom.xml<https://github.com/oskariorg/oskari-server/blob/master/pom.xml>, lack copyright license details (you may not care since they do not form executable code)
The incubation committee here is go through the same kind of steps a potential contributor would go through.This is the first time I have found a project without headers making me not quite sure how to review ...
--
Jody Garnett
On Mon, 24 Jun 2019 at 19:38, Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>> wrote:
Oh that is my bad, got the subject wrong :(
--
Jody Garnett
On Mon, 24 Jun 2019 at 14:31, Aarnio Timo (MML) <timo.aarnio at maanmittauslaitos.fi<mailto:timo.aarnio at maanmittauslaitos.fi>> wrote:
Hi Jody&al!
Thank you for helping, the revised checklist page can be found here:
https://github.com/oskariorg/oskari-docs/wiki/Oskari-Incubation-Checklist
(and the old one is still here:) https://wiki.osgeo.org/wiki/Oskari_Incubation_Status
Please let us know how it looks and if there is something we can clarify or improve.
BR,
Timo
PS. I did not realize your previous message dated May 27th, the subject esp. with the preview of the body text got me thinking it’s unrelated, sorry!
From: Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>>
Sent: perjantai 21. kesäkuuta 2019 19.50
To: OSGeo-incubator <incubator at lists.osgeo.org<mailto:incubator at lists.osgeo.org>>; Massimiliano Cannata <massimiliano.cannata at supsi.ch<mailto:massimiliano.cannata at supsi.ch>>; Aarnio Timo (MML) <timo.aarnio at maanmittauslaitos.fi<mailto:timo.aarnio at maanmittauslaitos.fi>>
Subject: Re: istSOS incubation
Any progress on a revised checklist page?
--
Jody Garnett
On Tue, 28 May 2019 at 12:53, Jody Garnett <jody.garnett at gmail.com<mailto:jody.garnett at gmail.com>> wrote:
I am taking this into a separate thread, thanks everyone for communicating across all the delays.
For the specific topic on open community and communication, it is my hope you already meet this requirement but to answer I would need ask how the project functions. My personal request is you write down how the communication works now, and do not set a goal as it may not be needed.
You can take inspiration from other projects that completed gradation<https://wiki.osgeo.org/wiki/Incubation_Committee#Graduated> and how they filled in this section.
open communication: The key is "public" communication, but can be a shared chat channel, or active stack exchange (email was common when open source started but is less common now). There are reasons to have private communication channels (GeoServer has a private security email list but we do document that it exists and committers can be included if they are in a position to help fix vulnerabilities). For a quick check I look at the repo README.
open community: Another aspect is that people can join the project and join the project leadership.We want to avoid the "single dictator" model as that is brittle. For a quick check I look at a repo CONTRIBTING.md.
The checklist should be in a place where your team collaborates (a place they all have permission to edit):
- If you use GitHub there is a markdown copy here<https://github.com/OSGeo/osgeo/tree/master/incubation/documents> to take into your wiki
- If you use OSGeo wiki copy one of the other examples
- If you use your own wiki or something that is also fine
When you and your mentor are happy the mentor will nominate the project and share the checklist. You are also welcome to share as you write and ask questions about difficult sections.
And I do not want the incubation sprint planning to get lost in this discussion, when you have a date Maxi there are several options for funding.
--
Jody Garnett
Dear Jody and Incubator-list,
Indeed, we’re still very interested in graduating as full members. Last time we had communications (On 24/8/18 12:46 am ) left us a bit waiting for answers to our questions, the most important probably being:
“What kind of concrete indicators would you like to see [that we have ‘an open community and communication’]? What could be a good goal?”
I.e. what could we do as a community in order for it to be more open? One thing contributing to that comes to mind (from the top of my head): We’ve since changed from Slack to the open-for-everyone-without-invitations Gitter (https://gitter.im/oskariorg/chat). AFAIK Gitter stores chat history indefinitely, which is a good thing. The PSC-memos are on GitHub and some of the discussion is on the mailing list.
As for the graduation checklist, unfortunately I can’t find information where it should be filled. The website https://www.osgeo.org/resources/project-graduation-checklist/has a downloadable PDF which is probably the one that should be filled?
Most of the information required is probably already here https://wiki.osgeo.org/wiki/Oskari_Incubation_Status but we’d be happy to fill the new one.
So, can you please point us to a list we can fill? Do we send it back to this list then?
Many thanks in advance!
- Timo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20201112/cb7c74b4/attachment-0001.html>
More information about the Incubator
mailing list