Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 05-07-2014, 01:36 PM   #31
Donamy
Beta Tester


Default

I don't think Face is threatening anything, just being "Face"tious.
Donamy is offline   Reply With Quote
Thanked by:
Old 05-07-2014, 05:41 PM   #32
martins
Orbiter Founder
Default

I've asked Artlav to comment on the issue, since his code is part of OVP and I couldn't change the license without his consent anyway.

In the meantime, I should like to summarise a few points, just for my own sanity's sake:

First off, the status of OVP and Orbiter's graphics client interface:
The graphics client interface (specifically, the GraphicsClient class) is part of Orbiter, not of the OVP. Hence, somebody could write a graphics client to interface with Orbiter without ever referencing OVP. In that case, the OVP license is irrelevant. Such a client could be distributed under a closed license and presumably sold. The only thing not allowed as per Orbiter license is to bundle Orbiter with it.

So I am assuming what we are disussing here is clients that are derived from OVP, rather than written directly for the Orbiter API. By derived I mean either explicitly linking to OVP libraries (e.g. the GDIClient dll), or re-using parts of its code.

Regarding bundling external clients with the Orbiter distribution for future releases: I would be very happy to do so provided the developers are happy with that, and the license permits it. If a switch to LGPL does allow for client modules to be distributed together with Orbiter, I would gladly do so.

Regarding my future plans for the inline client: I am currently not planning to upgrade the DX7 engine it to a newer interface. If the DX7 engine is considered obsolete I would rather remove it altogether and ship future Orbiter versions (after the next one) without a graphics engine in the core. (and instead maybe contribute to the external client developments).

So to my best understanding, these are the opinions voiced in this thread:
  1. The current GPL license may not be appropriate for the context of OVP, a library that is used by a closed-source application (Orbiter). A switch to LGPL or a more permissive license such as EPL would resolve any potential conflicts in this regard.
  2. The GPL license may be too restrictive when it comes to including third-party libraries and artwork. Again, a permissive license (and probably LGPL) would solve this.
  3. The danger of switching to a more permissive license is that clients could start to depend on proprietary libraries and art, making it dependent on components that the Orbiter community (including myself) have no control over.

As far as I understand, LGPL may constitute a compromise that all parties could live with? It would
  1. require all parts of the client to be available in source-form
  2. allow graphics client libraries to be bundled with Orbiter releases
  3. allow artwork to be bundled with a client under a different license as a "separate entity", i.e. as added content that the client can use, but doesn't depend on.

Is that a fair summary of the discussion so far? Would a dual-license GPL/LGPL license for OVP be a way that all parties could live with?
martins is offline   Reply With Quote
Old 05-07-2014, 06:55 PM   #33
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

I'm not too literate on OSS licenses, and my style of "open-source" was always more of a "fire and forget"+GPL/LGPL, so most of the discussion here is getting lost on me until i do a few more read passes.

The current OGLAClient is mostly this kind of code, plus a few bits of LGPL stuff, like FTGL library and KOST, i think.

How much it is relevant is another question.

The current OGLAClient is a dead end.
-There are some problems in it that i can't solve, like GDI compatibility and satisfactory implementation of new 2D rendering interface
-I'm too far behind the curve on the graphics programming to provide anything distinctly better than the other clients
-The OGLAClient is essentially closed-source - it's written in a custom dialect of Pascal, that no one is likely to make sense of or maintain

So, the existing code is unlikely to ever be brought up to date or maintained again.
Essentially, i'm ok with options that leave it behind.

On the other hand, one project that i was contemplating is making a new basic OpenGL client.
C++ translation of stripped-down OGLA engine, with all the functionality of the inline client (at least as far as of the previous betas - i didn't anticipate terrain), implemented in a readable way, and using standard OSS libraries instead of my ones.
Using and basing off parts of OVP reference code is more than likely.

For this to happen, i need to be able to link in LGPL and similar libraries into the project.
Any license change that fulfil this is fine by me.
Artlav is offline   Reply With Quote
Thanked by:
Old 05-07-2014, 07:08 PM   #34
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 In the meantime, I should like to summarise a few points, just for my own sanity's sake:
Looks like I am not the only one whose sanity has been pushed near the edge or over it.

Quote:
Originally Posted by martins View Post
 As far as I understand, LGPL may constitute a compromise that all parties could live with? It would
  1. require all parts of the client to be available in source-form
  2. allow graphics client libraries to be bundled with Orbiter releases
  3. allow artwork to be bundled with a client under a different license as a "separate entity", i.e. as added content that the client can use, but doesn't depend on.

Is that a fair summary of the discussion so far? Would a dual-license GPL/LGPL license for OVP be a way that all parties could live with?
Yes, I am O.k. with GPL/LGPL dual license.

Also there's a 4:th point:

4. allow third-party add-ons to link into a client regardless about a license model used by the add-on. (This is also included in LGPL)

EDIT: Also a client would need to be fully (100%) LGPL:ed in-order-to fulfill points 2. and 4.

Last edited by jarmonik; 05-07-2014 at 07:25 PM.
jarmonik is offline   Reply With Quote
Old 05-07-2014, 07:46 PM   #35
martins
Orbiter Founder
Default

OK, it seems that GPL+LGPL is the way forward then. I'll ask the other registered OVP developers for their input (if I can reach them - most of them probably don't remember that they are on the team) and then start updating the license.

What are the practicalities of changing the license of the project? Is it enough to submit a new version with modified license notes, and a comment that says "From commit X, OVP has switched to a dual license scheme. Derived works can choose to adopt a GPL or LGPL license"?
martins is offline   Reply With Quote
Old 05-07-2014, 08:03 PM   #36
kamaz
Unicorn hunter
 
kamaz's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 Is that all ? and how do you know ?
Technically speaking, Face is right. Remember that it's the author of the code who decides the license. If you have my code in your project contributed under license A, then you are not allowed to change the license of my code to license B (and since my code cannot be separated from your code...). That said, given the specifics of Orbiter, I would probably not sue you -- it's unlikely that I'd be awarded enough damages to cover my lawyer fees.

However, I am allowed to change license on my code from A to B. Therefore, if you have my statement in writing (e-mail counts) that I consent to change of distribution license, then you are covered. (An explicit grant of new license would be better, but consent should be enough to remove my grounds to sue).

You may take some time to read this book: http://www.rosenlaw.com/oslbook.htm

Quote:
Originally Posted by jarmonik View Post
 But, I don't really know what's been committed into the client code base during past half a year and where's the code initially coming from.
You have commit logs, don't you? You now have to ask everyone who contributed code (a) if they agree to changing the license (b) do they actually hold copyright on the code they've contributed and (c) if they know if the code they have contributed is encumbered by third party claims in any way. If you get a yes/yes/no from everyone, then you are covered.

Quote:
Originally Posted by jarmonik View Post
 Yes, I am O.k. with GPL/LGPL dual license.
You can do that, but it's redundant -- LGPL (v.2.1) has the following clause:

Quote:
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
Also, use of GPL for Orbiter modules is on shaky grounds anyway -- FSF believes that GPL'd modules cannot be dynamically linked to proprietary modules (i.e. Orbiter_ng.exe).

Last edited by kamaz; 05-07-2014 at 08:13 PM.
kamaz is offline   Reply With Quote
Thanked by:
Old 05-08-2014, 01:18 AM   #37
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
  (....maybe contribute to the external client developments).
It would be an honor to have you in a project. Welcome aboard. You can sent a request to join a project by creating a codeplex account also a windows live ID should work if you have one.

Quote:
Originally Posted by martins View Post
 What are the practicalities of changing the license of the project? Is it enough to submit a new version with modified license notes, and a comment that says "From commit X, OVP has switched to a dual license scheme. Derived works can choose to adopt a GPL or LGPL license"?
I don't really know since I have never done that before. However, for the D3D9Client project it was my intention to change the file headers to refer the LGPL-license instead of GPL and then change the project license to LGPL as well. If there is a possibility to add notes somewhere regarding the license change then I would list a few reasons why the license was changed:
- GPL isn't a suitable license for a project that is a sub-library/plug-in for a proprietary software.
- LGPL is a closest match to the actual needs of the project.

---------- Post added at 04:01 ---------- Previous post was at 03:59 ----------

Quote:
Originally Posted by kamaz View Post
 You may take some time to read this book: http://www.rosenlaw.com/oslbook.htm
Thank you, I'll have to read that one. Might be a good idea to buy one written in a local language.

---------- Post added at 04:18 ---------- Previous post was at 04:01 ----------

Quote:
Originally Posted by kamaz View Post
 You have commit logs, don't you?
Of course we have the commit logs. I was mostly referring to a code changes posted by some people through the Orbiter Forum without any kind of license with the changes. Of course, those changes are posted for a project that is a graphics client for the Orbiter and from that point of view nothing has changed. Also the license change is merely a correction to a mistake. As far as I can see the LGPL would allow us to legally do what we have been doing past 3 years already. Project's purpose or function haven't changed.
jarmonik is offline   Reply With Quote
Thanked by:
Old 05-08-2014, 04:13 AM   #38
SethEden
Beta Tester
 
SethEden's Avatar

Big Grin Client Wrapper

Wow it's been a long time! Glad to see you guys are still around.

I've always hoped to work on a graphics client but never seem to get around to it, especially with career and mortgage payments and home improvement projects.

But if I did ever get my graphics client project going, then I'm thinking LGPL is ok with me, as my plan was to build a fully open-sourced wrapper client and bind it to an external client rendering engine that would remain partly closed source and partly open source, but always available for free. In this sense Orbiter would be considered a plugin to the parent graphics engine connected via the graphics wrapper. This way I could form a company and build other plugin modules for the rendering engine say for instance for doing CAD or 3D modeling unrelated to Orbiter and having nothing to do with Orbiter, other than they use the same rendering engine.

Not sure if I'd ever get that far, but hey you never know. It's a nice idea anyways. I think LGPL fits that model, so I'm good with it.


I've started to build out the architecture for such a project already in my TimersXP project on Code Plex, but that is very much a work in progress and I'm not even sure if it compiles right now. I'm working a contract in Birmingham Alabama and don't have access to my usual development environment.

In short I say go for LGPL.
Cheers guys
Happy developing!
SethEden is offline   Reply With Quote
Thanked by:
Old 05-08-2014, 09:57 AM   #39
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 If the DX7 engine is considered obsolete I would rather remove it altogether and ship future Orbiter versions (after the next one) without a graphics engine in the core. (and instead maybe contribute to the external client developments).
IMHO, NG+client is still not the same as the core engine in terms of stability and compatibility. Sure it will never be 100% compatible due to things like DevMesh, but even taking this besides, many add-ons simply don't behave the same yet. If you dump the core engine before this situation gets better, I think you'll alienate many users and developers.

A better way would be to bring the DX7-OVP client to the same level of functionality as the core engine, up to a point where there is no difference for running add-ons. Other graphic client projects would also benefit from this, because it is effectively dog-fooding, giving you the chance to see interface short-comings early on.

Last edited by Face; 05-09-2014 at 10:45 PM.
Face is offline   Reply With Quote
Thanked by:
Old 05-08-2014, 10:09 AM   #40
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

I am not involved at all in the client world, but I also think a LGPL would be the better choice among the many alternatives.

A MIT license or BSD license would be too permissive regarding the requirements.
Urwumpe is offline   Reply With Quote
Old 05-08-2014, 11:09 AM   #41
jarmonik
Beta Tester

Default

Out of topic content removed. Apology for Face remains.

Last edited by jarmonik; 05-11-2014 at 07:23 PM. Reason: Out of topic content removed.
jarmonik is offline   Reply With Quote
Old 05-08-2014, 11:33 AM   #42
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by jarmonik View Post
 Out of topic content removed. Apology for Face remains.
Ditto and apology accepted.

Last edited by Face; 05-13-2014 at 03:24 PM.
Face is offline   Reply With Quote
Old 05-08-2014, 01:04 PM   #43
Xyon
Puts the Fun in Dysfunctional
 
Xyon's Avatar



Default

Quote:
Originally Posted by jarmonik View Post
 Oh, you were just being Facetious. Then I apologize making a wrong conclusions (with my bad English) regarding your out-of-context joke. I would prefer no-more jokes in this thread if that's O.k.
Quote:
Originally Posted by Face View Post
 The "facetious" term was from Donamy, and I am pretty sure it was tongue-in-cheek. I was not joking regarding my opinion, and the out-of-context quoting was done by you, not me.
Now that this is settled, can we perhaps keep the thread on-topic?
Xyon is offline   Reply With Quote
Thanked by:
Old 05-08-2014, 04:55 PM   #44
kamaz
Unicorn hunter
 
kamaz's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 Of course we have the commit logs. I was mostly referring to a code changes posted by some people through the Orbiter Forum without any kind of license with the changes.
In order to be copyrightable, the work must be creative. Works which are short and trivial (like most bugfixes) are not creative and thus not copyrightable.
kamaz is offline   Reply With Quote
Thanked by:
Old 05-10-2014, 11:16 PM   #45
jarmonik
Beta Tester

Default

Quote:
Originally Posted by kamaz View Post
 In order to be copyrightable, the work must be creative. Works which are short and trivial (like most bugfixes) are not creative and thus not copyrightable.
Yesterday, I spend 6 hours to browse through the D3D9Client development thread and now I have a pretty good contributor list available. Besides me and Kuddel only three persons have contributed something that is creative and therefore copyright-able. It would seem that runway lights are the biggest concern right now. I suppose it would be easier and probably faster to scrub the file and re-implement it from a scratch. If that is a valid option ? Now, I'll try to reach all other contributors.
jarmonik is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 07:38 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.