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, 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 a good thing, and > if so, what sort of consensus or agreement would be required in order > to be able to move forward with a change. > > Thanks, > > 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 > > _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
