OpenCPN PlugIn Development

[bdbcat]

Hello Developers and Testers...

The OpenCPN PlugIn Architecture, API Version 1.0 has been released for Beta discussion and test.

Design and Release Notes:
1. PlugIns are dynamically loaded libraries;
{name}_pi.dll for Windows
lib{name}_pi.so for linux.
2. Plugins are automatically detected when placed in the correct directory.
Windows: {Where OpenCPN is}\plugins ex: C:\Program Files\OpenCPN\plugins
linux: {prefix}/share/opencpn/plugins ex: /usr/local/share/opencpn/plugins
3. All detected, compatible PlugIns are loaded and initialized on application startup. We may want to develop a "PlugInManagerDialog" to allow selective loading...
4. Plugins are written in C++ and use the wxWidgets toolset. Interested developers are invited to consider other, more generic, toolsets and propose useful API extensions thereto. It should be possible to integrate with wxPython, for example...
5. The API is roughly defined in include/ocpn_plugin.h, found in the source tree. More verbage needed here.


I have created two PlugIns:

1. grib_pi
This is a PlugIn implementing the current GRIB overlay functionality. My alpha testing indicates that the functionality of GRIB in 2.1.0 is (almost) exactly duplicated. Full testing is required. Some developer(s) may wish to consider improved performance of this PlugIn. The code is fairly brutish in some places. Better caching and rendering are indicated.
I plan to release this PlugIn as part of opencpn Version 2.2.

This PlugIn does a lot of interesting stuff at the API level.
a. Toolbar Tool addition/management.
b. Toolbox Tab page addition.
c. Config file read/write.
d. Chart overlay rendering.
e. Private dialog management.
f. Mouse tracking.

Observant readers will note that this is exactly the functionality required for many chart overlay applications. Google KML file support is one. Some kind of Active Captain PlugIn is another candidate. Satallite radio weather....BlackBox radar...Others???
We could probably move AIS out to a PlugIn if we wanted to.

2. demo_pi
Demo_pi is, well, a demonstration. It can be used as the skeleton of a more advanced PlugIn development effort. I do not plan to release demo_pi in the next official 2.2 Release. It is for developer discussion and use only. It doesn't really do much, anyway.
Demo_pi exercises and demonstrates at least the following:
a. Private window creation.
b. NMEA data stream interception.
c. Context Menu item addition/management.

I expect demo_pi will be the basis wrapper for the much anticipated "dashboard" function that is our most popular request.

So, this is a start.
I am not smart enough to have anticipated all possible API requirements of a PlugIn. I expect as developers begin to actually consider writing PlugIns, we will have to add new methods, functions, and data types to the API specification. No problem with that. I hope we can stabilize the API for Version 2.2 release. We will make every effort to preserve backward compatibility where possible.

The PlugIn build process is a work-in-progress. Developer comments and improvements regarding the cmake scripts are encouraged.

I welcome spirited discussion of PlugIn development efforts here.
We will want separate threads for discussion of each PlugIn as each is ready for testing.

Good Luck
Dave

[ActiveCaptain]

Nice idea - I'll check it out.

[ActiveCaptain]

I have a couple of questions related to creating PlugIns:

1. What is the current status of Mac OSX support for OCPN and is PlugIn support being considered? There would obviously be a slightly different API set for Mac PlugIns but most of the PlugIn code should be identical.

2. How does the licensing work for creating PlugIns? Is the PlugIn API a part of the OCPN license thereby requiring the PlugIn itself to be open? It would be a significant issue if source had to be provided for many PlugIn developers. In addition, it is highly possible that a PlugIn developer would want to charge a fee for their PlugIn.

[cagney]

Originally Posted by ActiveCaptain

I have a couple of questions related to creating PlugIns:

......

2. How does the licensing work for creating PlugIns? Is the PlugIn API a part of the OCPN license thereby requiring the PlugIn itself to be open? It would be a significant issue if source had to be provided for many PlugIn developers. In addition, it is highly possible that a PlugIn developer would want to charge a fee for their PlugIn.

From gnu.org:

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

It looks like the plug-ins must be gpl:ed as well.
I don't think there will be any lack of plug-ins developed for OpenCPN, or interested developers.

Thomas

[ActiveCaptain]

Originally Posted by cagney

I don't think there will be any lack of plug-ins developed for OpenCPN, or interested developers.

So close and yet impossibly far away.

I'd strongly suggest that you find a way around this issue. It's not something to fight about - it's something to discuss. Create a set of objectives listing what you're trying to accomplish and make sure the rules imposed are promoting those objectives. I don't think they are. I think you're missing a major opportunity to bring a lot of accessory, data, content, and hardware vendors into providing OCPN solutions.

[nohal]

Originally Posted by ActiveCaptain

I'd strongly suggest that you find a way around this issue. It's not something to fight about - it's something to discuss. Create a set of objectives listing what you're trying to accomplish and make sure the rules imposed are promoting those objectives. I don't think they are. I think you're missing a major opportunity to bring a lot of accessory, data, content, and hardware vendors into providing OCPN solutions.

Jeffrey, there is no need to look for anything as the wheel was invented a long time ago by other people making money on the work of opensource programmers trying to give back to the community making it possible as little as possible. The plug-in itself can be just a very small (and harmless to open source as it does not show anything of the vendor know-how) part of the solution making the out of process calls to pretty much anything - totally legal as far as lawyer's point of view goes as you can read in the quote Thomas provided earlier.
Sorry to say that, but now I would like to see those products and solutions, not just complaints that there is no way to provide them

Pavel

[ActiveCaptain]

Come on, knock it off about "complaints". I'm trying to have a reasonable conversation regarding the discussion that Dave asked for. If the group here isn't interested in that, then I'll just go away and not provide feedback. You're missing something major due to license restrictions. I'd think you'd want to completely understand decisions like that as a part of opening a new capability.

You're not right about a plug in being small and simple. It can be quite complex and require interfacing to things that a commercial developer doesn't want exposed. Numerous examples exists. Certainly, ActiveCaptain is one of them for a variety of reasons.

[nohal]

Jeffrey, sorry if it sounded offensive to you. There was no intention. Did you read the rest of my post? There is no need for a commercial developer to expose stuff he doesn't want to be exposed as most of his stuff can run out of the plug-in itself, so you basically have to expose just the plug-in GUI and the interface to the commercial, private, secret, part of you solution. What's that problem you see with this? The GUI? It can be copied from how it works and looks, not just from the code. The only way to keep it just for yourself is not showing it to anybody - no business then as far as I can tell. The interface? Well, there has to be some, of course, but can be done in a way that's safe for you and useless for anybody else since we have encryption, hardware keys and other bizarre stuff making pirates life hard(er)...
More work for the commercial developer? Of course. That's how it works when he wants to make money on GPL stuff.

Pavel

[ActiveCaptain]

Originally Posted by nohal

Did you read the rest of my post?

Yes, I read the post. I didn't see where you were talking about just having the GUI open. I certainly don't see that as part of the quote previously about dynamically linked plug-ins. Perhaps this paragraph needs to be looked at carefully - it is quite clear to me that every plug-in for OCPN would require release under GPL including the release of full source.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

I wonder how many radar manufacturers would consider creating an overlay plug-in with those terms. Right now they're very closed about the interface to their devices. That might very well change in the future but is surely an example today (among others).

The electronics navigation market is a different type of place characterized by a lot of proprietary and closed systems. We can argue all day about the value and problems of that but at the end of the day, it's the way it is - some 10 years behind the rest of computer technology. It seems like an incredible shame to provide a clean way to enhance OCPN and yet require that small piece of it to be strapped with unacceptable terms to most third parties.

Here's the question I'd like answered...

Why is it OK for OCPN to create a system where significant income is received by chart resellers (ChartWorld, various governments, etc)? This enables use of data that is extremely closed, proprietary, and quite expensive. Why is this type of commercialization fully acceptable while interfacing to proprietary systems though code considered something that must be kept open?

[nohal]

Originally Posted by ActiveCaptain

Here's the question I'd like answered...

Why is it OK for OCPN to create a system where significant income is received by chart resellers (ChartWorld, various governments, etc)? This enables use of data that is extremely closed, proprietary, and quite expensive. Why is this type of commercialization fully acceptable while interfacing to proprietary systems though code considered something that must be kept open?

You sort of answered yourself. The open "glue" for the charts is the format, which is open and available - and it was paid by the chart producers and governments to make that standard. As you sure know, OpenCPN doesn't support chart formats which are not publicly available and have license issues - Garmin, BSBv4, CM93v3 to name just a few... Producers of those closed format charts don't get any money from OCPN users. And it's their legitimate business decision that they want it to be this way.
The commercialization of the same type is neither forbidden nor discouraged for the systems vendors. But I'm afraid the ball is not on the OSS side of the playground... As with everything else, it's a vendor's decision and if a vendor is a decade behind the apes, it's his problem, not our's.
And believe me, when the radar manufacturers start to appear with questions like "How could we interface our stuff with OpenCPN?", there will be a way to do that without making them bankrupt.

Pavel

[bluearcus]

Originally Posted by ActiveCaptain

Here's the question I'd like answered...

Why is it OK for OCPN to create a system where significant income is received by chart resellers (ChartWorld, various governments, etc)? This enables use of data that is extremely closed, proprietary, and quite expensive. Why is this type of commercialization fully acceptable while interfacing to proprietary systems though code considered something that must be kept open?

I imagine that the authors would like the plugin architecture to encourage development of FOSS modules providing additional functionality first of all, and to allow commercial developers to create proprietary licensed plugins as a secondary consideration.

Using direct linking of modules to the GPL'd OpenCPN core encourages the former, but doesn't prevent the latter... it just requires additional work to bounce out to the separate commercial module.

The charts issue, well that's a different matter.

Regards,

Mike

[Netsurfer]

Jeffrey,

Originally Posted by ActiveCaptain

Here's the question I'd like answered...

Why is it OK for OCPN to create a system where significant income is received by chart resellers (ChartWorld, various governments, etc)? This enables use of data that is extremely closed, proprietary, and quite expensive. Why is this type of commercialization fully acceptable while interfacing to proprietary systems though code considered something that must be kept open?

I cannot answer your question, but ...
Since when are the S-57 and BSB (1,2) standards

extremely closed, proprietary

?

Why is it OK for OCPN to create a system where significant income is received by chart resellers

Maybe because there is no alternative?
And as Dave has written on his website (OpenCPN About):

OpenCPN uses public domain chart data, provided by the U.S. government by download from the internet. This is the same data commonly used by existing commercial products of this sort.

From my understanding OCPN is intended to offer a free alternative to mariners for electronical navigation, as a suitable program is one of the two things that is needed beside the charts.

So to me it seems just consequential that every plugin follows the same intention and do not (directly or indirectly) support any proprietary things (no matter how useful they may be).

BTW: Personally I do not like the idea of making money with information gathered from users. I prefer the system "From users for users (for free)!".

But we are getting a little bit OT here ..., maybe it is better to start an extra thread for this (kind of) discussion?

Gunther

[ActiveCaptain]

Originally Posted by Netsurfer

Since when are the S-57 and BSB (1,2) standards (extremely closed, proprietary)

I never said they were. But S-63 certainly provides for extremely closed and proprietary data to be used.

Originally Posted by Netsurfer

From my understanding OCPN is intended to offer a free alternative to mariners for electronical navigation...

Try using OCPN to cruise along the coast of the UK and see how free it is. I'm actually not arguing with you - you already accept that the charts aren't free. Why should interfaces to proprietary systems be required to be free too?

Originally Posted by Netsurfer

I prefer the system "From users for users (for free)!".

It depends what you mean by "free". ActiveCaptain is totally free. There isn't a user who has ever paid for using the data. Over 4 years we've continually said that this policy would never change. And it hasn't. Every other free-for-all POI/cruising collection has failed previously. This is because there needs to be a significant amount of editing, reviewing, validation, and verification of the data for it to be useful. It currently takes 10-12 person hours a day to accomplish this - and that is growing (having now crossed over a million user updates).

I know that this puts it in a gray area and seems to tweak the conscience of some open source purists. It just seems odd to me that OCPN would allow for the obvious income generation and proprietary nature of most non-US charts and yet limit the availability of things like our free data because we want to protect it from abuse and provide next generation features with some amount of control.

[idpnd]

Originally Posted by ActiveCaptain

It depends what you mean by "free". ActiveCaptain is totally free. [...] It just seems odd to me that OCPN would allow for the obvious income generation and proprietary nature of most non-US charts and yet limit the availability of things like our free data because we want to protect it from abuse and provide next generation features with some amount of control.

The term free as in free software has nothing to do with free of charge, it's about a legal guarantee that the contributions to the published body of software and knowledge stay free. That's a fundamental ethical issue. I would not consider contributing to a database or project where I give up ownership of that contribution to some private entity. In that sense your data is anything but free.

You cannot really argue with the legal requirements of the existing license - and that's the whole beauty of it.. It does not even stop you from continuing what I personally regard as an abusive relationship with your data contributors, it just requires you to publish a module that interacts with your - closed and proprietary - database.

[sailias]

IMHO there are two sides to this discussion. One is the license of the actual plugin and the other is the license associated with the data that plugin calls upon. Lets take qgis as an example. The application is licensed under a gpl variant of which there are several flavors. Some plugins however rely on data that must by copyrighted to protect the validity of the data, otherwise it becomes useless. This is particularily important for geospatial data that is proofed by several means and to several degrees to ensure accuracy and validity of the data in accordance with standard statiscal and scientific methods. (which incidentally relies heavily on peer review however has lost its connection with its origins)

So IMHO while I agree that code is poetry, it can be argued that data is not. Its collected, messaged, collated edited, tested verified and proofed as part of the internel QA and QC process. Case in point, one of the big benefactors of the qgis project is the Canton of Solothurn, Switzerland who spend a lot on money writing enhancements for the project. Their data however is copyrighted, see

Abteilung SO!GIS Koordination

and comes with a specific license that allows for fees to be associated with the processing of the data, with the data allowed to be redistributed without warranty or claim of fitness. A legal requirement to prevent damages (a third issue...similar to the disclaimer that now comes with OCPN)

If I understand Jeffrey's position, and I may not, his concern is that user contributed data needs to be verified to be accurate and useful to other mariners. I dont think there is anything uncommon about that. Chart manufacturers do that all the time, some charge and some dont (eg: CMAP/Jeppson vs NOAA charts) I firmly believe there is a middle ground and that middle ground IMHO as Im not a developer but have some understanding of both the license structures, free software world and commercial vendors requirements, is based on the architecture of the plugin itself. Even the authors of the gpl v2 recognize this and leave the door open for discussion.

I surely hope this issue can be resolved as OCPN is too formidable of an application that really has a chance to change the playing field in terms of the quality of the offering, potential feature sets, the speed of development and enhancements, to be locked into a gpl vs propriatary discussion. Those always are polemical and end nowhere.

It is not my wish to offend anyone. It is my wish to see this wonderful application grow in terms of what it has to offer. My thanks to all who have made it possible as I use it now for all my travels and to date Ive always come safely back to port.

best regards

Chris Herrnberger
svBayBreeze
78 CAL3-29