Discussion OVP software license change

[Face]

Do you think that it would be the best course of action to stay in the GPL ? and why ?

I think it would be the best course of action to have a license for the OVP project (mind my words about OAPI in general) that fulfills Martin's points without much law consideration. GPL sure is on the safe side in this regards.

But that's just my opinion, I can't DO anything about it (neither promote nor deny), because I have zero copyrights in the OVP or D3D9Client project. All copyright holders have to agree for a license change to happen.

Generally speaking, I still think that GPL is the best license for community open-source projects. Not only for the source readability of all aspects of it, but also for the re-distribution rights, which are essentially just as important to me. However, I am not the right person you have to convince to change the status-quo. Those are Martin and the other graphics client developers.

Show them a detailed proposal and I'm sure there is a reasonable middle-ground (between now and what you wish for) to find.

 

[jarmonik]

Generally speaking, I still think that GPL is the best license for community open-source projects.

If we would have a GPL:ed Orbiter then everyone would need to surrender them selves to the believes of the GPL. Otherwise, they would have no right to share the add-ons they create. That could be considered to be discrimination and it would definitely not be very open-minded community.

Not only for the source readability of all aspects of it, but also for the re-distribution rights, which are essentially just as important to me.

Re-distribution rights are usually not the problem. Finding a willing re-distributors is.

Show them a detailed proposal and I'm sure there is a reasonable middle-ground (between now and what you wish for) to find.

I am not in a position to show any detailed proposals. Because, it is simply outside of my capabilities. The middle-ground between (EPL and GPL) is called LGPL.

1) Can Martin include LGPL:ed client into the Orbiter Distribution package ?

2) What license options we have for an artwork located in a client distribution package ?

3) Can we have (optional) proprietary artwork distributed in a separate distribution package ? (Can be used by the client if present but not required to use the client)

 

[Face]

If we would have a GPL:ed Orbiter then everyone would need to surrender them selves to the believes of the GPL. Otherwise, they would have no right to share the add-ons they create. That could be considered to be discrimination and it would definitely not be very open-minded community.

I see. Well, I already explained that I distinguish between Orbiter itself (NOT an open-source community project), Orbiter's API (very open to the point where it allows closed-source plugins) and the OVP project (the kind of open-source community projects I was talking about). I'm not having an overall Orbiter-GPL in mind.

Under this premise, your point about discrimination could be refuted like so: if you don't like the license, don't use the code. It's not like you absolutely have to use somebody's code, base your work on that, and then find yourself discriminated.

I am not in a position to show any detailed proposals. Because, it is simply outside of my capabilities.

Unfortunately, the same is true for me, so I can't really propose a replacement for the GPL at this point.

1) Can Martin include LGPL:ed client into the Orbiter Distribution package ?

2) What license options we have for an artwork located in a client distribution package ?

3) Can we have (optional) proprietary artwork distributed in a separate distribution package ? (Can be used by the client if present but not required to use the client)

For 1 I'd say yes. For 2 I think the LGPL doesn't really distinguish between code and artwork, so the later would be under LGPL, too.

For 3, why not? If it is not based on the client code/artwork, it is not derived work, especially if you take LGPL into account. If it is derived work, you have to take the base license into account.

So let's e.g. imagine a templating system ala skin-SDKs: if the skin-SDK is part of the LGPLed client code-base, all derived skins must be under LGPL, too. However, if the skin-SDK would be a separate project with e.g. Creative Commons, the derived skins must use this instead. The link between the client software and the skin-SDK (mesh-format used, loading call via IO OS-functions) can't be described as "deriving", because it uses means of either the still more open OAPI or the operating system.

Hm. It seems like this is getting a bit off-topic to the specific D3D9Client development itself, even if important for it. Maybe we should split it off into a separate thread?

That said, I'd like to encourage other current and potentially future OVP developers to say their opinion on this matters. Even if we can't do too much without copyrights in the appropriate projects, those who have to decide it can at least get a glimpse about what others are thinking. Seems like nobody here is a lawyer in that particular field, anyway, so every input would be valuable.

 

[jarmonik]

For 3, why not?

Well, can you override the LGPL license by splitting your work into a two different distribution packages ? I don't think so. Unless I am mistaking the answer is NO for all three questions.

I suppose the LGPL might be acceptable, but right now I don't really care. The license change to LGPL would need to be a very smooth process to be worth it.

Hm. It seems like this is getting a bit off-topic to the specific D3D9Client development itself, even if important for it. Maybe we should split it off into a separate thread?

No, need. I'll be staying out from this thread until we hear from Martin.


EDIT: Of course, Martin could upgrade the inline engine. That would also address many of those compatibility issues we are having.

 

[Enjo]

That said, I'd like to encourage other current and potentially future OVP developers to say their opinion on this matters. Even if we can't do too much without copyrights in the appropriate projects, those who have to decide it can at least get a glimpse about what others are thinking. Seems like nobody here is a lawyer in that particular field, anyway, so every input would be valuable.

I could eventually become one if I ever get my finances right. I'm planning a minimalistic OpenGL client in future for a good start.
It's no secret for everybody that I'm pro GPL, because my projects have proven to me that it works fine. This has two edges - I'd also love to see Orbiter GPLed, so that Linux or at least Winelib-derived version could become available (but the second part could be done without even GPLing Orbiter). I keep Windows only for developing for Orbiter, and not even playing it. However I understand that it might never happen. Nevermind.

So as you can see my opinion here is a bit biased, but I find all this license switching a bit of drama. Jarmo, we owe you very very much, but before quitting for license reasons, wouldn't it be better if you just used a GPL compatible numerical library like dlib?
On the other hand, I do understand your demotivation. We started this thang as youth, and now we're grown ups trying to make ends meet, and there seems no way to get our hard Orbiter work financed. Even if some fund were to be created (I saw potential sponsors here, some of them were ignored...), what money would have to be raised to make a difference for us? I have so large living costs, not living in luxury at all, that you couldn't imagine...
... unless you're married :lol:

 

[meson800]

The middle-ground between (EPL and GPL) is called LGPL.

1) Can Martin include LGPL:ed client into the Orbiter Distribution package ?

2) What license options we have for an artwork located in a client distribution package ?

3) Can we have (optional) proprietary artwork distributed in a separate distribution package ? (Can be used by the client if present but not required to use the client)

1. In addition, mere aggregation of another work not based on the Library
   with the Library (or with a work based on the Library) on a volume of
   a storage or distribution medium does not bring the other work under
   the scope of this License.

   Yes, just releasing a LGPL'd client with Orbiter would not require the whole package to be released under the LGPL.
   
   
2. See point three for included artwork.
   
   

3. If identifiable sections of that work are not derived from the Library,
   and can be reasonably considered independent and separate works in
   themselves, then this License, and its terms, do not apply to those
   sections when you distribute them as separate works. But when you
   distribute the same sections as part of a whole which is a work based
   on the Library, the distribution of the whole must be on the terms of
   this License, whose permissions for other licensees extend to the
   entire whole, and thus to each and every part regardless of who wrote
   it.

   Well, can you override the LGPL license by splitting your work into a two different distribution packages ? I don't think so. Unless I am mistaking the answer is NO for all three questions.

   I think you can "override" the license as long as the two parts are not based on one another (as artwork is not based on code, and vice versa).
   
   I would say that optional artwork (which is clearly not based on the source code of the client),if included in a different distribution package, could be distributed under any separate license because of the "do not apply to those
   sections when you distribute them as separate works" clause.

However, if the artwork was directly included in the client's distribution package, I believe it would fall under the LGPL.

All quotes from above taken from here.

 

[kamaz]

1) Even if we have a GPL license attached to the OVP the project it-self is not really a GPL:ed and we may not use any GPL:ed software resources in our project simply because in our project we are hooking the resources into a proprietary software (the Orbiter) and that is not allowed by the license.

This is a somewhat controversial area.

First off, GPL invokes something known as system library exeption, which allows you to link against non-free OS libraries. One could argue that Orbiter is your OS

Second, you can add an exception to the license explicitly allowing linking with non-free components.

2) A proper development of a client would require making a graphics client interface allowing addons directly to interact with a client by linking into it.
It is in a rights of a creator to decide how to share and license his or her own creations. This very fundamental and inspiring right would be taken away from anyone who's linking their creations to a GPL:ed client. That's completely ridiculous and unnecessary. I have no need to steal anyone's rights and I don't want to inflict such a curse upon anyone. That's why no graphics client interface exists today.

This is also a controversial issue because nobody knows for sure if dynamically linking your module against a GPL'd code causes it to become GPL-infected.

All that being said, if you believe that the copyleft should not cross the module boundary, just use LGPL, problem solved.

3) Development options are reduced because can't use closed source nor a GPL:ed software libraries in a development. A linear algebra package I created for the LTMFD can not be used in a client development. In a development version I used it for a curve fitting purposes for a faster approximation of some atmospheric integrals when working on an improved atmospheric model. I had to abandon the work I did because of our own license, that sucks.

If you are a sole copyright holder, or you have authorization of all other copyright holders, you can dual-license the code in question to GPL to allow it to be integrated. Problem solved.

---------- Post added at 09:08 PM ---------- Previous post was at 08:51 PM ----------

Then I want to avoid two things:

1. The client developer loses interest and the client is abandoned without any way for others to continue.

This is guaranteed if you use any OSI-approved license.

And if I may chime in, this problem is a real plague with add-ons (*cough* SC3 *cough*).

2. The client developer decides that there is money in this project and starts selling the client.

Technically, this cannot be avoided. You would have some standing if you GPL'd D3D7 code, and someone derived their closed source client from that. However, at the end of the day, the client is coded against the OVP API, and API is not copyrightable in the EU nor in the US. In other words, you cannot really sue someone for writing a closed-source client, unless you can demonstrate that their code is clearly based on D3D7Client -- which is going to be pretty difficult if the client targets anything else than DX7.

 

[jarmonik]

Yes, just releasing a LGPL'd client with Orbiter would not require the whole package to be released under the LGPL.

I think you can "override" the license as long as the two parts are not based on one another (as artwork is not based on code, and vice versa).

I would say that optional artwork (which is clearly not based on the source code of the client),if included in a different distribution package, could be distributed under any separate license because of the "do not apply to those
sections when you distribute them as separate works" clause.

Thank you for deciphering the license for us. I couldn't make any sense out of it on my own. If that's true then the LGPL would fulfill all necessary "points" for all of us and would be a better license for the OVP. Since, the LGPL is also a a GPL compatible other clients (if any) could still remain "GPL:ed".

 

[kamaz]

Oh, Yes. Of course, if the OVP contains a code that can't be re-licensed (for an example code from Artlav).

But Artlav can relicense his own code -- all you need is an e-mail from him saying that he agrees to change the license.

What exactly would need to be re-licensed ? is there something else than the API headers, D3D7 Reference client and the GDI client ?

License on API headers does not matter, API is not copyrightable.

D3D7 reference client does not need to be relicensed -- however, if D3D9Client is derived from D3D7 reference client, then you need consent from the author of the reference client (martins?). However, relicensing it could make sense to make writing new clients easier. The same for GDI client.

 

[jarmonik]

Removed the Quote

 

[Donamy]

I don't think Face is threatening anything, just being "Face"tious.

 

[martins]

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?

 

[Artlav]

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.

 

[jarmonik]

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.

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.

 

[martins]

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"?

 

[kamaz]

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

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.

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:

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).

 

[jarmonik]

(....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.

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 ----------

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. :thumbup:

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

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.

 

[SethEden]

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. :facepalm:

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! :thumbup:

 

[Face]

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.

 

[Urwumpe]

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.