Discussion OVP software license change

[jarmonik]

Well, there have been a few problems with the GPL:

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.

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.

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.


GPL does very little (if any) good to us and it's like a dagger in our back. When people are pushed to work in a conditions they don't approve the fire of creativity will simply die. Why do we do this to our selves ? Who's saying that we must all use the GPL ? If you want my help with the client then we need an alternative license for the OVP. Likely a dual license scheme of some kind. Otherwise, the people who favor the GPL have to do the bloody work by them self.

 

[Enjo]

Well, there have been a few problems with the GPL:

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.

Therefore it seems that OVP is more about outsourcing than opensourcing. But it's better than nothing.

 

[Face]

Hy Jarmonik,

good to know you are still skimming the forums.

GPL does very little (if any) good to us and it's like a dagger in our back. When people are pushed to work in a conditions they don't approve the fire of creativity will simply die. Why do we do this to our selves ? Who's saying that we must all use the GPL ? If you want my help with the client then we need an alternative license for the OVP. Likely a dual license scheme of some kind. Otherwise, the people who favor the GPL have to do the bloody work by them self.

Well, that's your opinion and this is OK for me, even if I don't agree.

However, you have to admit that D3D9 builds upon the examples distributed by Martin in his OVP project on Sourceforge. Those are GPL, and what this license means in terms of derived work I'm sure I don't have to re-iterate. If this is for better or for worse doesn't matter for the status quo. And that's what I was referring to with my statement about releasing, which obviously triggered your comment (and the fast reaction :tiphat.

I take it that the license is what keeps you from working on it further, then? What about re-licensing it for further work? If all copyright holders agree, this should be possible. AFAIK, those are you, martins, kuddel and Bibi Uncle (runway lights). Have you already tried to contact the others? Or do you think that won't be an option?

 

[kuddel]

What about re-licensing it for further work? If all copyright holders agree, this should be possible. AFAIK, those are you, martins, kuddel and Bibi Uncle (runway lights). Have you already tried to contact the others? Or do you think that won't be an option?

For me every license is O.K. Everybody is allowed to copy all of my bugs :lol:
Nice people do note from whom they've copied code.
Other -not nice- people will copy without ...and can not be stopped by a license.
Long story put short: Any license is O.K. with me.

Could any non-GPL license be a problem for some hosters? I think sourceforge e.g. only allows GPL code, right? But to be honest, I don't have that much of knowledge about that topic. Do we really need a software-license lawyer uhh ?

/Kuddel

 

[Bibi Uncle]

I don't have a lot of knowledge around the licensing of open-source, since I work almost exclusively on closed-source projects. However, I gave my code to the Orbiter community and everyone else. Jarmonik's answer will be mine.

It's good to see you back jarmo! :tiphat:

 

[Face]

Long story put short: Any license is O.K. with me.

I don't have a lot of knowledge around the licensing of open-source, since I work almost exclusively on closed-source projects. However, I gave my code to the Orbiter community and everyone else. Jarmonik's answer will be mine.

So it is down to Martin's stance on this.

Could any non-GPL license be a problem for some hosters? I think sourceforge e.g. only allows GPL code, right? But to be honest, I don't have that much of knowledge about that topic. Do we really need a software-license lawyer uhh ?

I think SourceForge is not GPL-only, just open-source. That said, Jarmonik is hosting his repository on Codeplex, where different rules apply.

 

[jarmonik]

So it is down to Martin's stance on this.

Yeah, it looks like it.

I think SourceForge is not GPL-only, just open-source. That said, Jarmonik is hosting his repository on Codeplex, where different rules apply.

Last time I checked, the codeplex accepts pretty large range of licenses. Not a problem.

---------- Post added 29-04-14 at 18:29 ---------- Previous post was 28-04-14 at 22:15 ----------

I think we would need a license with a following properties:

- Ability to link in our software from a closed source applications and add-ons as freely as they can link to the Orbiter itself.

- Ability to use and distribute additional code modules, artwork and resources under a different license in a distribution package.

- Also it would be nice if Martin could include our software (the D3D9Client) in the Orbiter distribution package under it's own proprietary license. Very handy if the DX7 stops working some day.

- Also a direct derivative work from the source codes would need to remain open-sourced. So, the source codes could not be closed by anyone.

After searching some licenses it would seem that a license known as EPL (Eclipse public license) would have these properties. http://www.eclipse.org/legal/eplfaq.php

That would allow us to use open-source software resources licensed under EPL, BSD and MIT licenses. Doesn't really matter since we not going to need them anyway.

Of course, some commercial software companies might be able to take a minor advantage of the code under more "relaxed" license such as the EPL. But since the client is heavily bound to the Orbiter and it's resources therefore any use of the code outside the OVP would be problematic at least. I don't think it's going to be a problem.

Any thoughts ?

 

[martins]

I am happy to discuss the OVP licensing. I am not having a strong opinion as obviously others do, and would consider re-licensing under more permissive terms, if that is required to keep the client development on track.

My only concern is this: I don't want Orbiter to become dependent on code I don't have any access to. Let's say I convert OVP to a BSD-type license, and it's used as the basis for a brilliant new closed-source graphics client that becomes the new standard to the point where Orbiter becomes dependent on it.

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.

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

So in summary, I'm open to more permissive licensing as long as it still requires the sources to be accessible. Is there anything that would fit the bill?

Edit: cross-posted with jarmonik's post. It looks like we are essentially in agreement here.

 

[Matias Saibene]

Just a curiosity:
Is possible to license the client under the terms of the LGPL?
As I have understood this license is less restrictive. Excuse my ignorance.

 

[jarmonik]

My only concern is this: I don't want Orbiter to become dependent on code I don't have any access to. Let's say I convert OVP to a BSD-type license, and it's used as the basis for a brilliant new closed-source graphics client that becomes the new standard to the point where Orbiter becomes dependent on it.

That is a fair point and understandable. The EPL I mentioned above would not allow to make a closed source clients. Although, it allows closed-source sub-libraries to be used. But I suppose you could demand having necessary access and re-distribution rights for any closed source sub-libraries we have for your self. Currently I only have a linear least-squares solver for curve fitting that would go in a closed library. Also, It's a good idea to license a sub libraries in a way that they are freely usable and re-distributable inside the OVP.

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

I am not a lawyer so I can't really say. How could one sell a product that is depended from the Orbiter and it's resources and completely unusable without them ?

 

[martins]

I am not a lawyer so I can't really say. How could one sell a product that is depended from the Orbiter and it's resources and completely unusable without them ?

Well, I don't see why not. If it enhances the Orbiter experience, then surely there would be people prepared to pay for it if necessary. The cost of the client would essentially become the cost of Orbiter. People are happy to pay for games, so why not here?

Anyway, this really was only a concern for a closed-source client development. If the EPL license does require the sources to be open, this point shouldn't be a problem.

What are the repercussions of re-licensing the OVP sources? I would prefer a straight switch to a new license rather than dual-licensing with GPL. But could this jeopardise existing clients? Could a client derived from OVP still be released under GPL, or would all existing clients have to switch their licenses? In that case, since the next Orbiter version will require modifications to the clients anyway, would it be better to leave the current OVP with its GPL license alone, and start a new OVP2 project with a new license?

 

[jarmonik]

What are the repercussions of re-licensing the OVP sources? I would prefer a straight switch to a new license rather than dual-licensing with GPL. But could this jeopardise existing clients? Could a client derived from OVP still be released under GPL, or would all existing clients have to switch their licenses? In that case, since the next Orbiter version will require modifications to the clients anyway, would it be better to leave the current OVP with its GPL license alone, and start a new OVP2 project with a new license?

Hopefully someone has little more insight for this.

But could this jeopardise existing clients?

Definitely it could, Some people are heavily sided with the GPL and they would not take a license change lightly. But I don't know where the DX11 developers stand in this matter.

Could a client derived from OVP still be released under GPL, or would all existing clients have to switch their licenses?

It just happens to be so that a license that requires any derivative work to be released under the same license will conflict with every license making the same requirement. (LGPL-GPL in an exception). EPL and GPL can't co-exist in a same code module or possibly a project. Licensing OVP under EPL only would very likely lead into a deadlock situation with-in a GPL:ed clients, forcing them to change to the EPL.

In that case, since the next Orbiter version will require modifications to the clients anyway, would it be better to leave the current OVP with its GPL license alone, and start a new OVP2 project with a new license?

I don't know, that sounds a bit complicated. Does anyone know anything about dual licensing ?

I would presume that it would be pretty simple. Something like this:

This source code is available under the terms of
GNU General public license or Eclipse public license by user choice.

Or Am I missing something ?

Here is one triple licensed project (EPL, GPL, LGPL) [ame="http://en.wikipedia.org/wiki/JRuby"]http://en.wikipedia.org/wiki/JRuby[/ame]

 

[Face]

What are the repercussions of re-licensing the OVP sources? I would prefer a straight switch to a new license rather than dual-licensing with GPL. But could this jeopardise existing clients? Could a client derived from OVP still be released under GPL, or would all existing clients have to switch their licenses? In that case, since the next Orbiter version will require modifications to the clients anyway, would it be better to leave the current OVP with its GPL license alone, and start a new OVP2 project with a new license?

From what I have seen from other projects, copyright holders can always agree to switch a project's license as a group. Of course, this will not work retroactively for all previous versions, just for the work going forward. I.e.: if you commit a new version of the OVP project, just change the copyright note. All derived work from then on will be subject to the new license.

AFAIK, already derived work will have to do the same. I.e.: with a new version, change the copyright note. All work from then on has the new license. Of course this only works if ALL copyright holders for the given project agree on changing the license, and I think it is a good idea to document this process in the project, too.

For the given case that would mean that work derived from a current version of D3D9 can still keep the GPL, but is not allowed to incorporate new code from the project without also changing to the new license (which would also need agreement of all involved contributors). I don't think there is such a thing, though.

Of course you can interpret all this more radically, and perhaps a court might invalidate all license changes given good lawyers... but this is not really a realistic scenario, is it? As long as no money is involved, I can't imagine a court act over OVP licensing.

That said, I don't really know how EPL covers the case of the closed-source library Jarmonik mentioned before. If it allows such libraries, it would contradict Martin's wish for always open source in OVP projects, as it would allow for all the things he mentioned (lock-in after developer is gone, possibility of becoming cash-cow, etc.). GPL is clearly ruling that out.

---------- Post added at 21:29 ---------- Previous post was at 21:15 ----------

Small addition:

In my understanding it would also be possible to only re-license D3D9, without touching OVP itself. The GPL requirement in D3D9 comes IMHO only from the fact that it was based on the D3D9 sources in the OVP code-base (even if it changed completely over the course of development).

If it were a clean implementation of the interface, I'd say the OS-analogy holds: you can license it however you wish as long as OS license is met. I.e.: the way normal add-ons are distributed (e.g. closed-source) would also be allowed for OVP-plugins. Therefore a special re-licensing of D3D9 should be fair, too.

 

[jarmonik]

That said, I don't really know how EPL covers the case of the closed-source library Jarmonik mentioned before. If it allows such libraries, it would contradict Martin's wish for always open source in OVP projects, as it would allow for all the things he mentioned (lock-in after developer is gone, possibility of becoming cash-cow, etc.). GPL is clearly ruling that out.

Yeah, GPL is ruling that out. Also, we don't need a closed-source software libraries in D3D9 if Martin implements the required functions in the Orbiter core. But it would still remain closed and not open nor "free". There's a difference but it ain't big. Also, It's not just the software there is artwork as well and we can't expect artwork creators to license their creations under GPL just like that. GPL is likely ruling out them too. Artwork is a bigger and more concerning issue than software libraries.

---------- Post added at 23:21 ---------- Previous post was at 23:01 ----------

In my understanding it would also be possible to only re-license D3D9, without touching OVP itself. The GPL requirement in D3D9 comes IMHO only from the fact that it was based on the D3D9 sources in the OVP code-base (even if it changed completely over the course of development).

D3D9Client is based on the D3D7Client in the OVP repository. Even if there exists a D3D9Client in the repository our client has nothing to do with it. I presume the D3D9 reference above was just a typo but better to be sure.

If it were a clean implementation of the interface, I'd say the OS-analogy holds: you can license it however you wish as long as OS license is met. I.e.: the way normal add-ons are distributed (e.g. closed-source) would also be allowed for OVP-plugins. Therefore a special re-licensing of D3D9 should be fair, too.

Could you be a little more specific about what do you mean by OS-analogy. I hope it has nothing to do with the exceptions given for the Operating Systems in the GPL.

---------- Post added at 23:46 ---------- Previous post was at 23:21 ----------

My only concern is this: I don't want Orbiter to become dependent on code I don't have any access to.

Any concerns to become dependent on GPL:ed code ? Some people might consider that a really interesting situation. I am concerned about that.

 

[Face]

D3D9Client is based on the D3D7Client in the OVP repository. Even if there exists a D3D9Client in the repository our client has nothing to do with it. I presume the D3D9 reference above was just a typo but better to be sure.

Well, it was no typo. D3D9 was there right from start, but you certainly know better what it was based on. Still it is based on OVP code, so the "derived work" argument applies. EDIT: Just to add: it is obvious that it was NOT based on OGLA, though. That's why I've excluded Artlav from the contributors list before, although he had some commits in the OVP project, too. As I see it, if Martin decides to re-license the OVP as a whole, Artlav must agree, too.

Could you be a little more specific about what do you mean by OS-analogy. I hope it has nothing to do with the exceptions given for the Operating Systems in the GPL.

By OS-analogy I mean the similarity to applications written on specific operating systems. Because it is only the API you are using, it doesn't matter what the operating system itself is licensed with, just what the API's license is allowing you to do with your work. However, if you develop an application for a specific operating system, and you license it as GPL, everybody using your application for derived work has to do the same.

For Orbiter, that would mean that Orbiter itself is the OS, applications are add-ons written against OAPI, but one specific application is OVP under GPL, requiring derived work (e.g. D3D9Client based on - as we established above - D3D7 code) to be under GPL, too. If D3D9Client were a "clean-room" implementation based on the API only, it could technically be released under the same rules as every other plugin.

That said, I'm not sure if this explanation fulfills your hope...

 

[jarmonik]

In that case, since the next Orbiter version will require modifications to the clients anyway, would it be better to leave the current OVP with its GPL license alone, and start a new OVP2 project with a new license?

Oh, Yes. Of course, if the OVP contains a code that can't be re-licensed (for an example code from Artlav). Then a new OVP2 might be an option but how much work would it take ?

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

---------- Post added at 20:37 ---------- Previous post was at 20:23 ----------

For Orbiter, that would mean that Orbiter itself is the OS, applications are add-ons written against OAPI, but one specific application is OVP under GPL, requiring derived work (e.g. D3D9Client based on - as we established above - D3D7 code) to be under GPL, too. If D3D9Client were a "clean-room" implementation based on the API only, it could technically be released under the same rules as every other plugin.

There's a lot of speculation and unknowns... and I am not looking into a re-writing a D3D9Client from a scratch. If there will be a major re-write of the D3D9 then it will be made directly into the Orbiter core in a case if Martin decides to pullout the plugs from the OVP. That would be a "clean-room" implementation then.

---------- Post added 01-05-14 at 18:52 ---------- Previous post was 30-04-14 at 20:37 ----------

That said, I don't really know how EPL covers the case of the closed-source library Jarmonik mentioned before. If it allows such libraries, it would contradict Martin's wish for always open source in OVP projects, as it would allow for all the things he mentioned (lock-in after developer is gone, possibility of becoming cash-cow, etc.). GPL is clearly ruling that out.

I am not sure what you mean by cash-cow but EPL:ed works can be distributed under a proprietary license. So, could the OVP (the interface to the Orbiter) licensed under a proprietary license that would describe the rights under which the clients may link into the Orbiter. That should give the means to keep a cash-cows out.

Also, if someone is selling your GPL:ed work on e-Bay then what can you do about it ? Why should anyone do anything about it if the GPL gives a valid license to sell it. If an EPL:ed work is containing a proprietary artwork or other material from a multiple contributors then you can just start selling it at least not legally.

EDIT: If we are about the mix EPL:ed software with a proprietary artwork then we would need a (global) license for a project that would cover all parts in a client distribution. (The OVP License)

 

[Face]

I am not sure what you mean by cash-cow but EPL:ed works can be distributed under a proprietary license.

My two short describing sentences there just tried to summarize Martin's points:

My only concern is this: I don't want Orbiter to become dependent on code I don't have any access to. Let's say I convert OVP to a BSD-type license, and it's used as the basis for a brilliant new closed-source graphics client that becomes the new standard to the point where Orbiter becomes dependent on it.

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.

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

These points are fulfilled with GPL. If EPL - or a proprietary license FWIW - allows for a closed-source library within a client, this is not given anymore. Whether or not someone sells it on Ebay is not the point. The point is that whoever releases a client (if sold or not doesn't matter) MUST also release the source code.

TBH, I think we are starting to go in circles. It seems like you don't want to develope on D3D9Client any further as long as the license doesn't change. That sure is a loss for the community, but of course you are totally free to make this decision. The only way to change the license is to give a proposal for a license that is acceptable for all copyright owners (you included). And then of course change it in the next version...

Direct question: is EPL allowing closed-source libraries, or not? If it does, is there a way to make a derived proprietary license that guarantees Martin's points? If so, how can we be sure that it is still compatible with other (and what) open-source licenses (to be sure there is not just another license-lock-in)? The later thing is documented thoughout the web for well-known licenses, but a proprietary might be not so clear.

 

[bpops]

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

Ok I am by NO means any sort of expert on this. But isn't the entire point of the GNU public license to prevent exactly that? That the software released under this license can be used freely but explicitly prohibited from being resold?

It's the whole idea of Richard Stallmann's "copy-left", right?

I could be way off or misunderstanding your worries. If so I'm sorry. Just commenting from what I've heard.

 

[Face]

Ok I am by NO means any sort of expert on this. But isn't the entire point of the GNU public license to prevent exactly that? That the software released under this license can be used freely but explicitly prohibited from being resold?

It's the whole idea of Richard Stallmann's "copy-left", right?

I could be way off or misunderstanding your worries. If so I'm sorry. Just commenting from what I've heard.

No. The idea of RMS was that there is no possibility to close out contributors of a project from reading sources of derived works ("not free as in beer, but free as in speech"). Actually, the GPL explicitly allows for copies being sold. It just doesn't make any sense to build a business plan on selling GPLed work, if you always have to include all sources anyway. Everyone would be able to recompile and redistribute.

IMHO, Martin's point was about a more permissive license (like the one Jarmonik hinted on), where it would be possible to create a graphics client that uses a closed source library for important features, say rendering atmospheric scattering for example. If people then view that client as de-facto Orbiter graphics engine, the copyright-owner of the library could decide to either go away and leave the community with perhaps broken code, or that so many people are using his library via the graphics client, that it is worth selling it now, having folks de-facto paying for Orbiter.

Of course that's just my interpretation of it, but I think it a reasonable worry. Martin's choice of GPL for OVP was the safe bet in this regards, if you ask me.

 

[jarmonik]

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

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

These points are fulfilled with GPL. If EPL - or a proprietary license FWIW - allows for a closed-source library within a client, this is not given anymore. Whether or not someone sells it on Ebay is not the point. The point is that whoever releases a client (if sold or not doesn't matter) MUST also release the source code.

Yes, you are right. The first point is covered better in the GPL. However, the GPL does not guarantee that the project keeps going after a developer is gone. Current situation with a D3D9Client isn't very far from a dead-lock. Also, Even if an EPL allows a closed-source sub-libraries they are likely made by one man and can be remade by an other man. So, it is a question of work doesn't mean that the project would be in a dead-lock situation. Any derivative work based on EPL:ed sources must remain open-sourced under EPL and the source codes must be made available to anyone receiving a copy the EPL:ed work.

Direct question: is EPL allowing closed-source libraries, or not?

Yes.

If it does, is there a way to make a derived proprietary license that guarantees Martin's points?

Yes, I believe so. 2:nd point shouldn't be a problem but the 1:st point could be a little more problematic.

If so, how can we be sure that it is still compatible with other (and what) open-source licenses (to be sure there is not just another license-lock-in)?

We wouldn't be miss-using the codes in anyway that I can see. But I can't really tell. If that is the way to go then it would be a good idea to point the question to Eclipse Foundation.

---------- Post added 03-05-14 at 15:41 ---------- Previous post was 02-05-14 at 19:29 ----------

Of course that's just my interpretation of it, but I think it a reasonable worry. Martin's choice of GPL for OVP was the safe bet in this regards, if you ask me.

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