Re: [Flightgear-devel] Licensing issues
John Check wrote: Theres nothing abot the licensing terms of the base package that would prevent the scenario of which he speaks. FWIW Erik, I understand how you feel, but OTOH thats the GPL. Yep, GPL covers almost anything, but I'm not so sure LGPL does. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Christian (and others): The purpose of my two bits of text, which you quoted, was to formally state on the mailing list what _my_ policy is for _this_ project. I was not trying to tell anybody else how their patches/code should be treated ... I wrote the message to avoid putting GPL copyright notices on the top of every little patch I routinely send through the mailing list. I should explicitly mention that my policy may be different on other projects. Thus, I encourage you to disagree with my personal policy (grin). I think I've said this before. If I submit a patch against someone else's file, the patch is intended to inherit the copyright and any current or future licensing of the containing file or code fragment. When I create a file, or submit a large patch to a file without an identified copyright owner, the intent is to retain the copyright in my name and apply _only_ the then-current GPL license version. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Erik Hofman wrote: Okay, here's my view. I've spent numurous hours of work into FlightGear (sometimes even almost as a day job) not only for the fun of it, but also because it's Free (for everyone). The fun would stop for me if I noticed my work ens up in a commercial application as an easy way to make money. You don't want to know how much time I've spent creating the F-16 configuration file and some of the texture (realy, you don't). That said, if the product will clearly state it's based on FLightGear _and_ provided the URL to the website, I'm willing to accept almost anything because that assures me there won't be any commercial compettitor which directly affects FlightGear. For instance, if there ever will be a sailing simulator based on large parts of FLightGear, I would have no obligations because it doesn't affect FlightGear itself. However, if for example the textures end up included in a commercial flight simulator just because it saves them time, I will strongly disagree. On the other hand, if one or more of the active FlightGear developers get the opportunity to spent their life developing FlightGear that way (which *is* a donation to FlightGear if you ask me) I would have no obligations at all. Erik Erik, I don't think there's any movement to change the license on the base package. I believe this discussion is on moving useful code routines from fg to sg, to make simgear a more useful and attractive platform. --Brandon Bergren ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote:
What I would like to propose for people's consideration, is the idea
of taking each of FlightGear's component libraries and converting them
to the LGPL license. The top level wrapper code (i.e. whatever is in
src/Main) would remain GPL.
Well, it doesn't matter what license is used for the wrapper code:
for (i=1, iN; ++i) {
subsystem[i].start();
}
because anyone could re-write it easily. Effectively we're talking
about putting as much as possible under LGPL. At first I thought that
sounded like betrayal, but now I'm thinking it sounds good. It would
allow companies who sell a product to include part or (essentially) all
of Flight Gear in their product. They would still have an obligation to
make freely available any modifications to Flight Gear components, so we
and anyone else would not lose out and might benefit if they felt
generous. They might just put minimal hooks in to get at what they
need, and not contribute anything valuable back to us. I don't think
that matters much. They won't gain a special commercial advantage,
because all of their competitors will be able to use FG in their
products too.
If we do not do this, companies which might want to use (part of) FG in
their products will instead write their own proprietary code, and almost
certainly keep it proprietary. Their potential input to the world of
computing will be sealed in a private box and never shared.
Curt, you have mentioned before that you work in a Human Factors
Research Lab and use FG (or parts of it) for (ground-) vehicle display
systems. I assume you are thinking of enabling a commercial product to
be made from this. That's OK by me.
As a programmer I strongly support measures that avoid duplication of
work. I'm not sure whether GPL does this better by persuading users
to share their own code so that they can use shared code, or the LGPL,
by giving users more flexibility with what they can do.
If people are concerned about unfair use of LGPL'd libraries, then we
should think about how to make such a library less susceptible, probably
by making its interface tighter.
Disclaimer: these are just some current thoughts, and I reserve the
right to change my mind.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Licensing issues
about putting as much as possible under LGPL. At first I thought that sounded like betrayal, but now I'm thinking it sounds good. It would allow companies who sell a product to include part or (essentially) all of Flight Gear in their product. They would still have an obligation to Yes. One point that has not been raised, yet, is that it also gives us a chance to permeate (to whatever degree) more of the flight simulation world and have a greater say in how things get done - perhaps even setting a standard. The more people use our code, the more input we get, and with that may come growth opportunities. Jon Jon S. Berndt Coordinator, JSBSim Project http://jsbsim.sf.net smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Licensing issues
Even back in the early days when FlightGear was just starting out, I thought it would be pretty great if someday I could get paid to work on FlightGear full time. So far no one has stepped up to the plate and offered to cover my salary simply for the pleasure of assisting an open source project. That would be great, but if someone actually wanted to do this, realistically I'd probably encourage them to give their money to a more deserving charity. However, as time goes on, there are little seeds of opportunity that come along once in a while. As can be expected, anything that would pay me or anyone else to work on FlightGear would most likely need some sort of financial incentive. FlightGear would have to satisfy some need they are trying to fullfill. There are some realities that we as a project are going to have to face in the upcoming years, and personally, I'd prefer to control our destiny, rather than have it control us. One reality is that what we have going here is pretty darn cool and impressive and it is getting to the point where FlightGear or portions thereof could be highly attractive to various companies. More than a few people are impressed with FlightGear in it's current state when they see it for the first time. (that doesn't mean we still don't have a lot of work to do ... ) I would prefer a culture where companies go through us and work with us to achieve their objectives rather than go around us. I'd prefer that we were in control of the process, rather than having companies simply do whatever they want. Another reality is time (or the lack thereof.) It seems that as life goes on, I have less and less time to spend on any particular thing. Life just get's busier and busier, and I get stretched thinner and thinner. I have less and less time for hobbies. Finding ways to generate income from my would would free me up to spend more time developing code for our project and less time helping my boss get rich. Now as you point out, the benifits to the flightgear project is that if someone is 100% focused on FlightGear, they can accomplish a lot in a relatively short amount of time. This can have huge benefits to our project. For example, I've been chipping away at runway lighting for the last few weeks in my spare time. If I was doing this full time, I'd probably have it done a long time ago. That would benefit everyone involved. There are trade offs to whatever course we take. Personally I made a conscious choice when I got involved in this open-source project. I knew we could never pull this off in a classic commercial sense and there were other groups (fly, propilot, etc.) that actually tried without any long term success. The open source approach allowed us to get to where we are today without needing to ship a product, pay employees, etc. And also I know that on my own, I could never have come up with something even to close to the same calliber as flightgear. There is also a matter of trust. If I go off and participate in some commercial venture involving flightgear, am I selling out? Am I screwing everyone else? I see it as getting paid to spend my time working on FlightGear. Most likely the bulk of that time would go towards contributing to the open-source body of code. Nothing is taken away from the FlightGear project, but many things are certain to be given to it. I know I'm far from perfect and can say/do some stupid things now and then, and people certainly should be cautious, but hopefully I've earned your trust over the years. If I was in this to try to make a quick buck ... well ... after five years of not having made a quick buck ... I'd either be a complete idiot, or more likely I'm doing this because I love it. That still doesn't mean I wouldn't like to find a way to get paid for my efforts so I can spend more time doing it, but lacking that, I'm still happy to continue giving as much time as I can afford for the love of mixing computers and aviation. So in terms of licensing our code. I think it is a good thing if we can position the code so that we can take advantage of our own work or at least make it possible to do so. I'm proposing that we move very slowly and very carefully. I'm not proposing anything radical I don't think. What I would like to do at some point is start looking at key sections of code, and with appropriate discussion, move them individually to SimGear and convert the license to LGPL. From other feedback I've heard, people have generally been receptive to this idea, and if we attack it one section at a time I think it is doable. In many senses I'm talking about moving towards my original goal with simgear to turn it into a simulator construction set, or simulation kernel, depending on what you want to call it. Having said all that, I have no immediate plans to quit my full time job, however there are some little seeds of opportunity I'd like to be able to water and see what grows. Have I dug myself a deep enough
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson [EMAIL PROTECTED] said: come along once in a while. As can be expected, anything that would pay me or anyone else to work on FlightGear would most likely need some sort of financial incentive. FlightGear would have to satisfy some need they are trying to fullfill. Like the basis for a sophisticated and low cost flight training appliance (FS-Tivo)? I would prefer a culture where companies go through us and work with us to achieve their objectives rather than go around us. I'd prefer that we were in control of the process, rather than having companies simply do whatever they want. Hmmm...Covalent and Apache? Another reality is time (or the lack thereof.) It seems that as life goes on, I have less and less time to spend on any particular thing. Life just get's busier and busier, and I get stretched thinner and thinner. I have less and less time for hobbies. Finding ways to generate income from my would would free me up to spend more time developing code for our project and less time helping my boss get rich. Yep. Me too :-) There are trade offs to whatever course we take. Personally I made a conscious choice when I got involved in this open-source project. I knew we could never pull this off in a classic commercial sense and there were other groups (fly, propilot, etc.) that actually tried without any long term success. The open source approach allowed us to get to where we are today without needing to ship a product, pay employees, etc. And also I know that on my own, I could never have come up with something even to close to the same calliber as flightgear. There is also a matter of trust. If I go off and participate in some commercial venture involving flightgear, am I selling out? Am I screwing everyone else? I see it as getting paid to spend my time working on FlightGear. Most likely the bulk of that time would go towards contributing to the open-source body of code. Nothing is taken away from the FlightGear project, but many things are certain to be given to it. I know I'm far from perfect and can say/do some stupid things now and then, and people certainly should be cautious, but hopefully I've earned your trust over the years. If I was in this to try to make a quick buck ... well ... after five years of not having made a quick buck ... I'd either be a complete idiot, or more likely I'm doing this because I love it. That still doesn't mean I wouldn't like to find a way to get paid for my efforts so I can spend more time doing it, but lacking that, I'm still happy to continue giving as much time as I can afford for the love of mixing computers and aviation. I think you can have your cake and eat it...no problem. :-) So in terms of licensing our code. I think it is a good thing if we can position the code so that we can take advantage of our own work or at least make it possible to do so. I'm proposing that we move very slowly and very carefully. I'm not proposing anything radical I don't think. What I would like to do at some point is start looking at key sections of code, and with appropriate discussion, move them individually to SimGear and convert the license to LGPL. From other feedback I've heard, people have generally been receptive to this idea, and if we attack it one section at a time I think it is doable. In many senses I'm talking about moving towards my original goal with simgear to turn it into a simulator construction set, or simulation kernel, depending on what you want to call it. There's been discussion about moving stuff to SimGear anyway...sounds like a good approach. Having said all that, I have no immediate plans to quit my full time job, Darn :-) Have I dug myself a deep enough hole yet? :-) Hehe...getting there. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote: I know this is probably opening a can of worms, but I just thought I'd throw this out to the list now so people could start thinking about and/or discussing the issues. Currently SimGear is a set of libraries, each of which is licensed under the *L*GPL. FlightGear is also mostly a set of libraries (with some top level wrapper code) that is entirely GPL'd. What I would like to propose for people's consideration, is the idea of taking each of FlightGear's component libraries and converting them to the LGPL license. The top level wrapper code (i.e. whatever is in src/Main) would remain GPL. Well, to be honnest. I've been thinking of restricting some of my contributions even more (configuration files, textures, etc) so it can be used for non commercial purposes only. That said, I'm a big fan of the Free Software Foundation, but some contributions took so much time, that I don't wanted to see them end up in commercial software (e.g. the F-16 config file end up in FLy! ot MSFS ...) For code, I think GPL is good enoug and when looking back at it, changing SimGear to LGPL was done without consulting anyone else also (If I had contributed code for Simgear at that time I probably would have complained). For me it's all an issue of other people running away with (and making mony out of) my contributions to LightGear, while I am jobless for some time now. This doesn't sound appealing to me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote: James A. Treacy writes: You should get as close to 100% of the contributors to agree as you can get. Flightgear needs to be prepared to remove any code written by someone who disagrees or who couldn't be contacted and appears later on. FWIW, wine did this earlier this year and they got all but a handful of contributors to sign off on the change. The missing had made only small contributions that they could easily recode if the need arose. Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. My sense is that if it is only minor changes that were contributed by others, the primary author should be able to maintain complete ownership over the copyright and license terms of that code. Yep. That's my opinnion also. FWIW, this issue arrises when we consider moving code from FlightGear into SimGear. SimGear code is LGPL'd and FlightGear code is GPL'd so a license change would be required. Hoever, if we attacked this piece by piece, subsystem by subsytem, it would likely be doable. What's your reason for wanting to change the license anyway? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Alex Perry writes: See the article in Linux Journal recently. You legally cannot place anything into the public domain, you merely get to assert that the licensing you are assigning to your copyrighted work behaves as though it is in the public domain. There is a subtle distinction, which essentially means that, since you do still have the copyright, people who retrieve the code also have the right to sue you. After all, the public domain license does not limit warranties etc. They have the right to sue anyway, no matter how many disclaimers you put in the license. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
David Megginson wrote: Erik Hofman writes: Well, to be honnest. I've been thinking of restricting some of my contributions even more (configuration files, textures, etc) so it can be used for non commercial purposes only. Unfortunately, that would force their removal from FlightGear, which (given the high quality of your textures) would be a shame. I haven't, I still supose the base package falls under the GPL. But I like to keep it GPL and nothing less restrictive. Also not that none of my code contributions have an explicit copyright in the header, which means they fall under the same license terms of FlightGear (GPL now, and maybe LGPL later). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
I should point out that my earlier message in this thread was to recommend that Curt not pursue the relicensing because the benefits are probably too small to outweigh both the non-trivial effort for the developers and the fairly large risk of causing FGFS to fork. However, that is independent of how I license my contributions. Erik said: Also not that none of my code contributions have an explicit copyright I think I've said this before. If I submit a patch against someone else's file, the patch is intended to inherit the copyright and any current or future licensing of the containing file or code fragment. When I create a file, or submit a large patch to a file without an identified copyright owner, the intent is to retain the copyright in my name and apply _only_ the then-current GPL license version. To save confusion, don't bother asking me to me-copyrighted files under the GPL with any version and automatic upgrade to future versions. There are no restrictions on how the FSF organisation can rewrite the intent and content of future versions of the GPL. Those future versions could, for example, grant a $0.01/sourceline royalty to RMS for any commercial use of GPL'ed software. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
James A. Treacy wrote: On Tue, Oct 15, 2002 at 11:15:08PM -0500, Curtis L. Olson wrote: Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. Exactly the way I want to think of it. The law, though, seems to have its own bizarre sense of logic. I belive that contributions are seen as being individual items(*), like pieces of lego. You only have the copyright on your 'pieces of lego'. Thus, if the primary author of some code wants to release future versions under a different license and a contributor disagrees, then the primary author would need to back out the contributed code. Obviously, as code evolves it becomes less clear who contributed what. That's also my point of view. If you want to change the licence you must ask every contributor. If one doesn't answer or one rejects the change (you'll have to assume the worst) you must roll these commits back before you change the license. There's no other way to do it. Code that has grown over the time is thus quite impossible to convert to a new license with out implementing it in a clean room. As this sounds like *very* much work to me and all of us have no spare time (if they'd had they'd be improoving FGFS...) I can't see the FGFS changing the license in the near future. If a company needs a differnt licence they could do it if they have the resources... (have a look at the Wine project as a reference) To make this kind of stuff easier in the future we could try to ask every contributor to give the copyright to someone. E.g. to Curt or The FlightGear project (whatever that means - probably only legal if there's an official organisation like the KDE league; Mantis does that) Appart from this legal stuff I really dislike 2 different licenses in the FGFS pakage (or SimGear, or ...). All the files should have the same license. That was IIRC one the reasons for seperating SimGear. I also can's see any benefit for changing FGFS itself to LGPL. So I grant permission to move any code that I produced (mostly, but not only, patches and bug fixes) to SimGear and change the License for that purpose only to the LGPL. Code that remains in FGFS itself has to stay under GPL. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
David Megginson wrote: My understanding of the *gpl is keep the copyright as a legal instrument to enforce the donation in court against those who try to deny the public its donated good, which _makes_ it legally enforceable. I don't see pd as being enforceable. Not quite -- the GPL is designed to force people to make their modifications or improvements publicly available, something that does not concern me so much. The GPL doesn't force the modifications to be given back to the community. It only forces that the source code for the distribution of the software (modified or unmodified doesn't matter) must be aviable for reasonalbe costs. So if my company gets an GPLed software and modifies it and uses it only internally no code has to come back to the community (although it'd be playing nice). If the company sells (or gives it away for free) this modified software it doesn't need to give the modified source code away with it. BUT: The customer can copy this software for free and give it to everybody else for free (as long as it states that this software is still GPLed). And the customer can ask the company for the source code. The company has to give the source to the customer then... Something that is in the Public Domain remains in the Public Domain; otherwise, publishers would be able to restrict Jane Austen's novels or Shakespeare's plays (rather than just the publisher's editorial contributions). They can - sort of. The layout etc. in their books is copyrighted work. But you are free to type it from the books and give it away for free - as long as you aren't also typing additional stuff like translations from the old english to the new english words. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Alex Perry wrote: I should point out that my earlier message in this thread was to recommend that Curt not pursue the relicensing because the benefits are probably too small to outweigh both the non-trivial effort for the developers and the fairly large risk of causing FGFS to fork. exactly I think I've said this before. If I submit a patch against someone else's file, the patch is intended to inherit the copyright and any current or future licensing of the containing file or code fragment. I disagree partly. If I submit a patch it'll be under the same licence of the file that it had at the creation of the patch (unless otherwise stated). If anyone (including the author who has written everthing exept a few minor patches) wants to change the licence every author of that file (i.e. the original author and any additonal authors, also those that only fixed a speeling mistake in a sting that never gets printed) must agree - or their work has to be redone in a clean room environment. When I create a file, or submit a large patch to a file without an identified copyright owner, the intent is to retain the copyright in my name and apply _only_ the then-current GPL license version. Who decides if my patch is minor or a large rewrite? Also I haven't heard the phrase except minor modifications in the Copyright law... So it's a everybody agrees or no action can be done. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
On Wed, Oct 16, 2002 at 03:51:17PM +0200, Christian Mayer wrote: If you want to change the licence you must ask every contributor. If one doesn't answer or one rejects the change (you'll have to assume the worst) you must roll these commits back before you change the license. There's no other way to do it. Code that has grown over the time is thus quite impossible to convert to a new license with out implementing it in a clean room. As this sounds like *very* much work to me and all of us have no spare time (if they'd had they'd be improoving FGFS...) I can't see the FGFS changing the license in the near future. If a company needs a differnt licence they could do it if they have the resources... (have a look at the Wine project as a reference) IMO, changing licenses is one of those areas which end up being easier in practice than expected - if people see a good reason to change the license. If the reasons to change the license aren't strong enough you are much more likely to encounter resistance (and as has been discussed resistance would make changing the license very difficult). To date, I don't believe the reasons to change the license are strong enough to overcome any resistance. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote: Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. It goes by change, not by file. They contributed a patch under an existing license, not a new one. So you can't legally change their license without removing the patch; nothing gives you the right to their work. In practice, what this means is that you need to get most of the developers on board. If someone doesn't agree, you need to be prepared to remove their code and reimplement it. You don't necessarily need to remove every 2-line patch submitted on the assumption that the author doesn't agree. It's enough to announce the license change in the appropriate forum for FlightGear development (here, of course) and expect that people interested will notice and tell you about problems. IANAL, of course. But this is the way it's worked in other projects (Wine, especially) that have gone through license changes. But under no circumstances can you relicense someone else's code over their objections. If someone makes a stink, you have to snip it out. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Alex Perry wrote: There is a subtle distinction, which essentially means that, since you do still have the copyright, people who retrieve the code also have the right to sue you. It's even more subtle: the right to sue you doesn't go with the copyright. The copyright is a right that *you* have to restrict distribution. The right to sue for damages is someone else's, and is inherent (with lots of legislative exceptions). Basically, regardless of what you do with your copyright: if you wrote the code, it's your fault. This is why the GPL has its warranty clause, and why commercial licenses always have the limitation of liability clause. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Erik Hofman writes: I haven't, I still supose the base package falls under the GPL. But I like to keep it GPL and nothing less restrictive. Also not that none of my code contributions have an explicit copyright in the header, which means they fall under the same license terms of FlightGear (GPL now, and maybe LGPL later). Perhaps the licensing status of the base package should be our first concern. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson [EMAIL PROTECTED] said: James A. Treacy writes: You should get as close to 100% of the contributors to agree as you can get. Flightgear needs to be prepared to remove any code written by someone who disagrees or who couldn't be contacted and appears later on. FWIW, wine did this earlier this year and they got all but a handful of contributors to sign off on the change. The missing had made only small contributions that they could easily recode if the need arose. Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. My sense is that if it is only minor changes that were contributed by others, the primary author should be able to maintain complete ownership over the copyright and license terms of that code. If someone else (in addition to the main author of a particular chunk of code) contributed new code, or a major rewrite, or something else significant, then we start getting into gray areas. It seems like the primary author of that code probably still could have final say, but basic courtesy might dictate that the major contributors at least be consulted ... (?) This could be a concern for a legal department in a company considering using code down the road. It seems unlikely that anyone with a trivial contribution would sue the project if they were not given full say. Ethically I would say yes, since the conditions under which the contribution took place were clearly stated by GPL. Ethics are extremely important in the open source community, and should I think be considered before legal liability. Whether or not someone could or would take legal action or would spend the money to defend against legal action should not be the primary concern. If that all was the case, then it still might be nearly impossible to relicense the entire project given the total number of contributors, but it might be possible to relicense a smaller sub-section of the code where the number of identifiable contributors is smaller and within reason (as long as the resulting license remained compatible with the rest of the code of course.) At least two or three of the authors of the 3D models that I solicited for the project would not want their work released under LGPL (I understand this isn't necessarily what you had in mind). FWIW, this issue arrises when we consider moving code from FlightGear into SimGear. SimGear code is LGPL'd and FlightGear code is GPL'd so a license change would be required. Hoever, if we attacked this piece by piece, subsystem by subsytem, it would likely be doable. And of course, the FlightSim specific stuff would make the most sense to leave inside FlightGear, but other things like the scenery subsystem, FDM interface (?), sound manager, time tracking, model animation, properties, joystick support, etc. might make sense to migrate over to SimGear as time goes by ... This would be the best approach I think, so long as authors are consulted. Generally I feel the same as David about the code I've created. But, fundamentally I think that David's concern about the pretentiousness in the GPL or LGPL is unwarranted. It isn't about whether or not someone would actually afford to defend their rights faced with abuses by a large company. GPL and LGPL are as much social contracts as they are legal contracts. They have recognizable meaning that could be disrupted, if too many projects sought less restrictive licensing without good reason. That said, the age of this project and the large number of contributors makes it difficult to do this conversion right, except by carefully moving work over to SimGear as Curt suggests, consulting authors along the way. My apologies if this response is out of sync, but i'm only about half way through the thread and need to get back to work work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Licensing issues
I know this is probably opening a can of worms, but I just thought I'd throw this out to the list now so people could start thinking about and/or discussing the issues. Currently SimGear is a set of libraries, each of which is licensed under the *L*GPL. FlightGear is also mostly a set of libraries (with some top level wrapper code) that is entirely GPL'd. For those that aren't as familiar with the differences between GPL and LGPL, I will summarize based on my understanding: - They are essentially the same except that the GPL applies to an entire application, where as the LGPL applies only to a specific library. I.e. in a GPL'd application, the entire source code that forms that application must also be GPL'd (or at least have a compatible license.) If someone makes a source code change (i.e. adds value) and distributes that change, they must distribute the new/different source code so everyone else can also benefit. All the rights and benifits which you received, you need to afford them to everyone else. - The LGPL is very similar except it works on the granularity of a library. If I add code or make a change to the a particular LGPL'd library and distribute it, I need to make the source for those changes available. However, unlike the GPL, an LGPL'd library can be linked into a commercial application. The host application can remain commercial. Plib (which flightgear makes heavy use of is LGPL'd.) This means we (an open source project) can use it, and also a commercial application can use it. For plib, this is a big benefit because it means more people can use their code, more people contribute to the code, etc. etc. In the long term the code is probably better than it would have otherwise been. It might be true that some company is able to sell a better product because of the efforts of the plib team, but the hope is that the commercial company will be able to contribute back to plib, just like any other contributor, and in fact the company would have paid developers that may be able to contribute larger chunks of time to plib than a home hobbyist could. SimGear is also completely LGPL'd. I'm not aware of any commercial applications that are currently using it, however at the moment it's pretty specific to the needs of FlightGear/TerraGear. What I would like to propose for people's consideration, is the idea of taking each of FlightGear's component libraries and converting them to the LGPL license. The top level wrapper code (i.e. whatever is in src/Main) would remain GPL. I'm sure there are some people out there that aren't thrilled with the GPL and would be happy to see the licensing relaxed a bit more (and might feel that this is not going far enough.) There may be other's who think the GPL is just fine and would rather not make the licensing more flexible. - I'd be interested in perspectives and discussion, although I highly doubt this would lead to any sort of consensus. :-) - If we wanted to tweak the licensing terms for the FlightGear project, could we? Who has authority to do this. If we can get most authors/contributors to agree, is that good enough? Do we need approval from 100% of the authors/contributors? What if someone doesn't respond negatively now (i.e. they are on vacation, or just don't have time to think about it) and we change the licensing terms, but then they come back in a year and make a big issue of it? What do we do then? Would that be a potential problem? - Personally I'm inclined towards LGPL'ing the FlightGear components at some point in the nearer future. Is there any major opposition to doing this? - The LGPL license means that the code could show up as part of a commercial application and benefit them. However, if they need to make any changes or improvements to the library to meet their needs, those changes would propogate back into our LGPL code. It's conceivable/likely that if a commercial entity used portions of FlightGear's LGPL code, they would be able to contribute back to our project. - Worst case scenario ... someone out there is a jerk and tries to take advantage of us and our efforts. My view is that we out compete them. We continue to develop our open-source version so it kicks their sorry butts. If they have customers that are stupid enough to buy their old, outdated crap, then what are you going to do? A couple rounds of thorough butt kicking and most people will get the idea. It's not unlike commercial competition where a company see's another company's features and hires someone to replicate them. The first company just impliments new and better features. We are open-source so we are all volunteers, but just like the commercial world, we still win by being better. We don't need to make a decision right now, but it would be interesting to hear people's perspective on whether or not this LGPL'ing the library portions of FlightGear would be
Re: [Flightgear-devel] Licensing issues
I don't see a real benefit of changing FGFS from GPL to LGPL ... * The people who don't like GPL probably aren't much happier about LGPL * They (or we) can add a shared-memory tunnel in SimGear for properties * Most proprietary extensions can simply coexist as separate programs Anything that makes sufficiently fundamental changes to FGFS that the property tree isn't enough, while also staying proprietary, is probably going to be a strong source of project forking and should be discouraged. My $0.02 I know this is probably opening a can of worms, but I just thought I'd throw this out to the list now so people could start thinking about and/or discussing the issues. Currently SimGear is a set of libraries, each of which is licensed under the *L*GPL. FlightGear is also mostly a set of libraries (with some top level wrapper code) that is entirely GPL'd. For those that aren't as familiar with the differences between GPL and LGPL, I will summarize based on my understanding: - They are essentially the same except that the GPL applies to an entire application, where as the LGPL applies only to a specific library. I.e. in a GPL'd application, the entire source code that forms that application must also be GPL'd (or at least have a compatible license.) If someone makes a source code change (i.e. adds value) and distributes that change, they must distribute the new/different source code so everyone else can also benefit. All the rights and benifits which you received, you need to afford them to everyone else. - The LGPL is very similar except it works on the granularity of a library. If I add code or make a change to the a particular LGPL'd library and distribute it, I need to make the source for those changes available. However, unlike the GPL, an LGPL'd library can be linked into a commercial application. The host application can remain commercial. Plib (which flightgear makes heavy use of is LGPL'd.) This means we (an open source project) can use it, and also a commercial application can use it. For plib, this is a big benefit because it means more people can use their code, more people contribute to the code, etc. etc. In the long term the code is probably better than it would have otherwise been. It might be true that some company is able to sell a better product because of the efforts of the plib team, but the hope is that the commercial company will be able to contribute back to plib, just like any other contributor, and in fact the company would have paid developers that may be able to contribute larger chunks of time to plib than a home hobbyist could. SimGear is also completely LGPL'd. I'm not aware of any commercial applications that are currently using it, however at the moment it's pretty specific to the needs of FlightGear/TerraGear. What I would like to propose for people's consideration, is the idea of taking each of FlightGear's component libraries and converting them to the LGPL license. The top level wrapper code (i.e. whatever is in src/Main) would remain GPL. I'm sure there are some people out there that aren't thrilled with the GPL and would be happy to see the licensing relaxed a bit more (and might feel that this is not going far enough.) There may be other's who think the GPL is just fine and would rather not make the licensing more flexible. - I'd be interested in perspectives and discussion, although I highly doubt this would lead to any sort of consensus. :-) - If we wanted to tweak the licensing terms for the FlightGear project, could we? Who has authority to do this. If we can get most authors/contributors to agree, is that good enough? Do we need approval from 100% of the authors/contributors? What if someone doesn't respond negatively now (i.e. they are on vacation, or just don't have time to think about it) and we change the licensing terms, but then they come back in a year and make a big issue of it? What do we do then? Would that be a potential problem? - Personally I'm inclined towards LGPL'ing the FlightGear components at some point in the nearer future. Is there any major opposition to doing this? - The LGPL license means that the code could show up as part of a commercial application and benefit them. However, if they need to make any changes or improvements to the library to meet their needs, those changes would propogate back into our LGPL code. It's conceivable/likely that if a commercial entity used portions of FlightGear's LGPL code, they would be able to contribute back to our project. - Worst case scenario ... someone out there is a jerk and tries to take advantage of us and our efforts. My view is that we out compete them. We continue to develop our open-source version so it kicks their sorry butts. If they have customers that are stupid enough to buy their old, outdated crap,
Re: [Flightgear-devel] Licensing issues
Alex Perry wrote: I don't see a real benefit of changing FGFS from GPL to LGPL ... * The people who don't like GPL probably aren't much happier about LGPL * They (or we) can add a shared-memory tunnel in SimGear for properties * Most proprietary extensions can simply coexist as separate programs I'm inclined to agree. The only real purpose behind the LGPL is to special case the situation of GNU versions of system libraries. Applying the GPL strictly to libraries like libc or libstdc++ means that proprietary software can't be run on free operating systems, since the act of linkage makes them a derived work according to the license. That's silly, so there's a special-purpose variant of the license that allows linkage (but *only* linkage) of proprietary code. The LGPL has since become popular for library projects that are designed to become standards, or at least widely shared. Projects like plib and SDL use it for that reason -- to keep development open while encouraging use of the library by anyone. FlightGear doesn't really fall into either category, since it's a one-of-a-kind codebase that is used only by other GPLed software. It strikes me that putting, say, the scenery engine under the LGPL isn't likely to encourage anyone to use it as the standard scenery engine for anything. Users who want the code are likely going to want to hack at it for their own purposes, which the LGPL forbids. Is there a use case here, or a particular proprietary application you have in mind? It might be simpler to do a custom release to that vendor under a separate license, rather than play with the license for the whole project. The LGPL is a little problematic for most proprietary users. They aren't, contrary to common belief, allowed to use the library any way they want. They have to link expressly against the library as shipped (no cutting and pasting of code), and have to ensure that future users can relink against newer versions of the library if they want (no static linkage, essentially). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
On Tue, Oct 15, 2002 at 03:22:02PM -0500, Curtis L. Olson wrote: - If we wanted to tweak the licensing terms for the FlightGear project, could we? Who has authority to do this. If we can get most authors/contributors to agree, is that good enough? Do we need approval from 100% of the authors/contributors? What if someone doesn't respond negatively now (i.e. they are on vacation, or just don't have time to think about it) and we change the licensing terms, but then they come back in a year and make a big issue of it? What do we do then? Would that be a potential problem? You should get as close to 100% of the contributors to agree as you can get. Flightgear needs to be prepared to remove any code written by someone who disagrees or who couldn't be contacted and appears later on. FWIW, wine did this earlier this year and they got all but a handful of contributors to sign off on the change. The missing had made only small contributions that they could easily recode if the need arose. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Licensing issues
Curtis L. Olson writes: I know this is probably opening a can of worms, but I just thought I'd throw this out to the list now so people could start thinking about and/or discussing the issues. Currently SimGear is a set of libraries, each of which is licensed under the *L*GPL. FlightGear is also mostly a set of libraries (with some top level wrapper code) that is entirely GPL'd. Well, GPL or freer. Some of the code that I've written that doesn't incorporate anyone else's is explicitly PD, though that leaves you free to make it GPL if you want. My opinion is already on the record, so I'll just restate it quickly: I prefer Public Domain to LGPL (and LGPL to GPL), both because it makes it easier for companies to use the code without waiting for approval from the legal department, and because I don't believe in making threats I'm not willing to keep (I'm not going to bankrupt myself suing Microsoft if they steal my code, so why pretend that I would)? If people cannot stomach Public Domain, then something freer than LGPL, such as BSD or Perl artistic, would be preferable. The issue in any case is getting permission from original authors who contributed under the GPL; here's a start: I hereby grant permission for any code or other digital objects I've contributed to FlightGear, SimGear, TerraGear, or the FlightGear base package to be relicensed under the LGPL or a less restrictive license, up to and including Public Domain. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
On Tue, 15 Oct 2002 17:37:32 -0400, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: My opinion is already on the record, so I'll just restate it quickly: I prefer Public Domain to LGPL (and LGPL to GPL), both because it makes it easier for companies to use the code without waiting for approval from the legal department, and because I don't believe in making threats I'm not willing to keep (I'm not going to bankrupt myself suing Microsoft if they steal my code, so why pretend that I would)? ..pretending, you allow, say, the FSF, to act on our behalf, or to fund that furball. With PD, AFAIK, you have given up all rights, and your (or the public domains) case never makes it into the court. ..there _are_ many good reasons not to give up copyright for free stuff too, the best ones is to protect that very freedom and price. If people cannot stomach Public Domain, then something freer than ..public domain equals the author drops or donates his copyright to the public domain? My understanding of the *gpl is keep the copyright as a legal instrument to enforce the donation in court against those who try to deny the public its donated good, which _makes_ it legally enforceable. I don't see pd as being enforceable. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Arnt Karlsen writes: ..public domain equals the author drops or donates his copyright to the public domain? It means that the work is released into the public domain. There is no donation, because no one owns (or can own) copyright on their original work, though people can copyright derivatives. My understanding of the *gpl is keep the copyright as a legal instrument to enforce the donation in court against those who try to deny the public its donated good, which _makes_ it legally enforceable. I don't see pd as being enforceable. Not quite -- the GPL is designed to force people to make their modifications or improvements publicly available, something that does not concern me so much. Something that is in the Public Domain remains in the Public Domain; otherwise, publishers would be able to restrict Jane Austen's novels or Shakespeare's plays (rather than just the publisher's editorial contributions). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
James A. Treacy writes: You should get as close to 100% of the contributors to agree as you can get. Flightgear needs to be prepared to remove any code written by someone who disagrees or who couldn't be contacted and appears later on. FWIW, wine did this earlier this year and they got all but a handful of contributors to sign off on the change. The missing had made only small contributions that they could easily recode if the need arose. Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. My sense is that if it is only minor changes that were contributed by others, the primary author should be able to maintain complete ownership over the copyright and license terms of that code. If someone else (in addition to the main author of a particular chunk of code) contributed new code, or a major rewrite, or something else significant, then we start getting into gray areas. It seems like the primary author of that code probably still could have final say, but basic courtesy might dictate that the major contributors at least be consulted ... (?) If that all was the case, then it still might be nearly impossible to relicense the entire project given the total number of contributors, but it might be possible to relicense a smaller sub-section of the code where the number of identifiable contributors is smaller and within reason (as long as the resulting license remained compatible with the rest of the code of course.) FWIW, this issue arrises when we consider moving code from FlightGear into SimGear. SimGear code is LGPL'd and FlightGear code is GPL'd so a license change would be required. Hoever, if we attacked this piece by piece, subsystem by subsytem, it would likely be doable. And of course, the FlightSim specific stuff would make the most sense to leave inside FlightGear, but other things like the scenery subsystem, FDM interface (?), sound manager, time tracking, model animation, properties, joystick support, etc. might make sense to migrate over to SimGear as time goes by ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Arnt Karlsen writes: ..public domain equals the author drops or donates his copyright to the public domain? See the article in Linux Journal recently. You legally cannot place anything into the public domain, you merely get to assert that the licensing you are assigning to your copyrighted work behaves as though it is in the public domain. There is a subtle distinction, which essentially means that, since you do still have the copyright, people who retrieve the code also have the right to sue you. After all, the public domain license does not limit warranties etc. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
On Tue, Oct 15, 2002 at 11:15:08PM -0500, Curtis L. Olson wrote: Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. Exactly the way I want to think of it. The law, though, seems to have its own bizarre sense of logic. I belive that contributions are seen as being individual items(*), like pieces of lego. You only have the copyright on your 'pieces of lego'. Thus, if the primary author of some code wants to release future versions under a different license and a contributor disagrees, then the primary author would need to back out the contributed code. Obviously, as code evolves it becomes less clear who contributed what. (*)This is what I have surmised from previous discussions on copyright. I have never seen this explicitly stated. I don't like this way of looking at things but we have to deal with the legal system we have been given. My sense is that if it is only minor changes that were contributed by others, the primary author should be able to maintain complete ownership over the copyright and license terms of that code. It is precisely because this is false that the FSF will not accept code for software they own the copyright unless you sign a document stating you own the copyright on code that you submit and assign the copyright to the FSF. If someone else (in addition to the main author of a particular chunk of code) contributed new code, or a major rewrite, or something else significant, then we start getting into gray areas. It seems like the primary author of that code probably still could have final say, but basic courtesy might dictate that the major contributors at least be consulted ... (?) I wish common courtesy played a part in such matters. When it comes to the law you can't trust people to be polite. Unfortunately, the legal system is inherently combatative(**). SUMMARY If the developers decide to change the license it should be doable. Some person or group will need to track down as many contributors as possible and try to get them to agree to the switch. That is where the real work is. My opinion is that the change won't bring enough benefits to warrant the expenditure of energy. (**) Off topic: the family of a co-worker of my wife completely devastated a few million dollar estate (on lawyers) because one group didn't agree with the terms of the will and contested it. This is not a rare occurence. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
