Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Tue, Nov 23, 2010 at 11:33 PM, Campbell Barton ideasma...@gmail.com wrote: Look at the simplest case for a LGPL switch: if all blender developers and all contributors agree to switch to LGPL. We still have libraries that are GPL, these cant just be made into extensions, they need to be replaced or removed/rewritten. The likely-hood of convincing external projects from GPL to LGPL is much lower. Quick grep reveals... - intern/elbeem: Fluids, can be disabled now at build time. - extern/lzo: Compression lib, can be disabled now at build time. - extern/Eigen2: Math lib, can be disabled now at build time. Eigen2 is actually LGPL already so it is no problem. http://eigen.tuxfamily.org/index.php?title=Main_Page#License - intern/moto: Math lib, used for the BGE and IK's, could of course be replaced but not trivial. I thought that moto was already planned to be completely replaced (eventually) by Eigen2? http://lists.blender.org/pipermail/bf-committers/2010-February/026014.html http://wiki.blender.org/index.php/User:Moguri/BGE_Eigen2 So that leaves elbeem and lzo. Is there any possibility that these two could be refactored as extensions? I'm not asking you to do it, I'm just asking if you think that it might be possible. I realize some things might be so deeply embedded that refactoring them would not be an option. I suppose that another option is offering blender under multiple licenses. For example: an LGPL version of Blender without elbeem and lzo, and a GPL version with them. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
A lot of the discussion has centered around integrating Blender in a production system based on proprietary software. I'd like to bring up the following two points: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. (...) However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in? It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. I really think the problems brought up in this discussion are best solved by being smarter about how the integration is handled. (It is possible to integrate GPL programs in a proprietary system, if not, we'd really have problems.) It's a lot easier than doing a wholesale re-licensing of the code - something which, as far as I can see, completely lacks support among the main contributors; and furthermore would not solve anything, as the interface required in section 0 of the LGPL isn't defined by Blender. Unless the interface is clearly defined (no, header files don't count - they define internal interfaces, not necessarily library interfaces; consider linux - it has many headers, but only some are considered OK to use in proprietary code). /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Wed, Nov 24, 2010 at 12:15 AM, Alex Combas blenderw...@gmail.com wrote: On Tue, Nov 23, 2010 at 11:33 PM, Campbell Barton ideasma...@gmail.com wrote: Look at the simplest case for a LGPL switch: if all blender developers and all contributors agree to switch to LGPL. We still have libraries that are GPL, these cant just be made into extensions, they need to be replaced or removed/rewritten. Sorry Campbell, I somehow missed that you wrote these can't just be made into extensions. So I guess that answers my question regarding Elbeem and lzo. Regarding lzo, I've heard that zlib is generally equivalent although zlib is slower and uses more memory but produces better compression so that might possibly be a replacement candidate. But that would still leave Elbeem. Are you absolutely certain that refactoring fluid simulation into an extension would be impossible? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Hello, I have a couple of things to say :) 1) If I was you, I would start a wiki page where to collect the results of all these discussions: right now I have the impression that this will go nowhere if you keep discussing just here. Maybe there's a better chance to get to a proper document. 2) In august 2009 we started this new repository for extensions: http://projects.blender.org/projects/bf-extensions Of course we've chosen to go GPL or GPL-compatible. After talking with Kent Mein, him being the father of the first repository of plugins + scripts, I started to send e-mails to ask authors of those scripts with unknown license if they were ok to put a GPL license. I had 50% replies, all OK to go with GPL, and 40% of the mails bounced back, and kindof 10% simply didn't bounced but they never replied. So in my experience I think you will have hard times trying to contact all contributors to have their agreement, even just because you can't get to them, or requires too much work to find out their new mail, and also in the case you find out, they might ignore you or say no. Too much work. Also, what happens if they died? Regards, Luca _ http://www.mindrones.com On 11/24/2010 08:33 AM, Campbell Barton wrote: On Wed, Nov 24, 2010 at 12:26 AM, Alex Combas blenderw...@gmail.com wrote: Hello developers, A common statement I've heard people make when talking about the possibility of a license change is: Its a good idea, but in practical terms it is almost impossible. I do not think that is true. Here is my proposal for how it could be done: ~~~ 1. Wait until Blender gets out of beta. A good first step. 2. Clarify the objective to re-license the code. There are several different proposals for re-licensing Blender. Before proceeding it would be necessary to pick one of them and make a clearly stated goal. For example: Our goal is to re-license the entire Blender code base from GPL to LGPL for the purpose of keeping the code free and protected, while at the same time allowing developers to write extensions which link to Blender to use whatever license they wish for their own code. 3. After having clearly defined the goal it would be necessary to organize a census among the Blender developer community to determine if the majority support this idea. 4. If we reach a state where the majority (at least 60-70%) of the Blender developer community support this idea, then the idea should move forward. But wait! Would it be possible to move forward if there was less than 100% support? Yes. Next the Blender Foundation would need to make an announcement: This is a notice to all past and present Blender developers: We are planning to change the license under which Blender is distributed from GPL to LGPL, this is for the purpose of keeping Blender free and protected, while at the same time allowing other developers to write extensions which link to Blender to use whatever license they wish for their own code. Important: If we have applied patches to the code from you, and you are opposed to this idea then please let us know and we will back out your changes. At this point people should wait for at least a month or two to give any developers who are opposed to the idea adequate time to go through the source and notify the Blender foundation of any sections which they claim they are the authors of and would like to have removed from Blender if the license is changed. Now depending upon how that goes will determine how the license change would proceed. Possibility #1: No developers contact the Blender Foundation and ask for their code to be removed. In this case, license Blender as LGPL and the job is done. Possibility #2: The Blender Foundation is notified by some developers that a few small trivial parts of Blender which they have written would need to be removed. In this case a separate branch could be created which does not contain their code, once the code has been reimplemented then it could be merged with trunk. Then license Blender as LGPL and the job is done. Possibility #3: The Blender Foundation is notified by some developers that one or more major sections of Blender which they have written will need to be removed. In this case it might be possible that their code could be completely removed from Blender and re-built as an extension. For example, lets just say that the compositor was made by a single developer and that this developer does not want his code to be relicensed as LGPL. Since we do not wish to lose the compositor, and it would be impractical to re-implement it, then the only option would be to rebuild the compositor as an extension. In this way the compositor extension would remain GPL in accordance with the authors wishes, and the rest of Blender could still be relicensed as LGPL. Once the code in contention has been reimplemented or modified to function as an extension then
[Bf-committers] Nameable group node sockets and other improvements
As part of the ongoing work on the particles-2010 branch i decided to address some of the nagging issues of group nodes. While nice in theory, the usability of node groups suffers from bad behavior and missing features to reveal its true power. Three things in particular i would like to fix: * External sockets should be renameable to give some meaning to the parameters and outputs of a complex group. * The order of external socket should be changeable (e.g. to stress different importance of sockets). * The internal sockets that get an external counterpart should be selectable explicitly, instead of having to use ugly workarounds to hide some of them. The first of these has now been implemented as a patch for trunk (which i will port to the particles branch too of course). It seems to work very well, but since i had to change some of the inner workings of group nodes, it could use some more testers. See the patch description for details. https://projects.blender.org/tracker/index.php?func=detailaid=24883group_id=9atid=127 There are certainly more features that would be nice to have for nodes (nested groups, more ui improvements), but these three can be implemented quickly. Cheers, Lukas Tönne ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Hello, GPL it is, and GPL it will be. Switching to v3 would be possible to some point anything else is completely out of discussion imho. Also in practical terms, it's not really possible to switch to LGPL,... in such a huge project I bet there will be at least 20-30 contributors, who would really object a switch to LGPL and would also take the according legal actions, if you try to do so. And you would have a hard time patching all their stuff out and show a proof of that. blender is not a platform or framework for any commercial software companies to release there products with. No sense to wine about this, at least I for myself, don't give a shit. If you want to be part of the blender world, play by our rules, e.g. release to GPL. Myself, I wouldn't care about blender at all, if it wasn't for it's openness. I don't get it why some folks think, it would help blender, to sell out some of it's openness, to make it more appealing to the world of proprietary software. Making it more successful by destroying the main intention behind this project simultaneously. That doesn't make sense to me. Imho, we should really object any non GPL extensions and plugins Aurel On 24 November 2010 12:47, mindrones mindro...@gmail.com wrote: Hello, I have a couple of things to say :) 1) If I was you, I would start a wiki page where to collect the results of all these discussions: right now I have the impression that this will go nowhere if you keep discussing just here. Maybe there's a better chance to get to a proper document. 2) In august 2009 we started this new repository for extensions: http://projects.blender.org/projects/bf-extensions Of course we've chosen to go GPL or GPL-compatible. After talking with Kent Mein, him being the father of the first repository of plugins + scripts, I started to send e-mails to ask authors of those scripts with unknown license if they were ok to put a GPL license. I had 50% replies, all OK to go with GPL, and 40% of the mails bounced back, and kindof 10% simply didn't bounced but they never replied. So in my experience I think you will have hard times trying to contact all contributors to have their agreement, even just because you can't get to them, or requires too much work to find out their new mail, and also in the case you find out, they might ignore you or say no. Too much work. Also, what happens if they died? Regards, Luca _ http://www.mindrones.com On 11/24/2010 08:33 AM, Campbell Barton wrote: On Wed, Nov 24, 2010 at 12:26 AM, Alex Combas blenderw...@gmail.com wrote: Hello developers, A common statement I've heard people make when talking about the possibility of a license change is: Its a good idea, but in practical terms it is almost impossible. I do not think that is true. Here is my proposal for how it could be done: ~~~ 1. Wait until Blender gets out of beta. A good first step. 2. Clarify the objective to re-license the code. There are several different proposals for re-licensing Blender. Before proceeding it would be necessary to pick one of them and make a clearly stated goal. For example: Our goal is to re-license the entire Blender code base from GPL to LGPL for the purpose of keeping the code free and protected, while at the same time allowing developers to write extensions which link to Blender to use whatever license they wish for their own code. 3. After having clearly defined the goal it would be necessary to organize a census among the Blender developer community to determine if the majority support this idea. 4. If we reach a state where the majority (at least 60-70%) of the Blender developer community support this idea, then the idea should move forward. But wait! Would it be possible to move forward if there was less than 100% support? Yes. Next the Blender Foundation would need to make an announcement: This is a notice to all past and present Blender developers: We are planning to change the license under which Blender is distributed from GPL to LGPL, this is for the purpose of keeping Blender free and protected, while at the same time allowing other developers to write extensions which link to Blender to use whatever license they wish for their own code. Important: If we have applied patches to the code from you, and you are opposed to this idea then please let us know and we will back out your changes. At this point people should wait for at least a month or two to give any developers who are opposed to the idea adequate time to go through the source and notify the Blender foundation of any sections which they claim they are the authors of and would like to have removed from Blender if the license is changed. Now depending upon how that goes will determine how the license change would proceed. Possibility #1: No developers contact the Blender Foundation and ask for their code to be removed. In this case, license
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
There's been a lot of discussion on here about how could we move to a point where we weaken the copyleft Blender has? I would just like to put in that not everyone hopes this will happen... I do not hope it will happen. I personally think the lack of a copyright assignment within Blender, and using the GPL, is actually tremendously to Blender's advantage: it keeps the copyleft strong, even when people don't want it to be.. example, now. This is a feature! I know that people have the best intentions here, hoping to increase the diversity of Blender usage, but I think that if Blender is good, people will use it. If companies want to make their own custom tools in-house, they can already do that. But I personally don't see value in a future with proprietary extensions on top of Blender. I don't have anything more to contribute to the conversation here (well besides the temptation to correct some clear misinformation on the thread, of which there's been a lot, but I'm staying out of that also). I'm only writing this email to comment on the fact that there's been a ton of noise on-list related to changing the license, despite the tremendous difficulty that would be involved in doing so. Well, not everyone wants that to happen. I don't. Keep Blender maximally free! - Christopher Allan Webber ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] RNA property updates vs anim sys
On Wed, Nov 24, 2010 at 5:08 AM, Matt Ebb m...@mke3.net wrote: Hi, What's the deal with RNA property update functions and the animation system? I would have expected the animation system to run the update functions when an rna property is updated via an fcurve/driver/etc, but they're not. Why is this, and can it be fixed? It's pretty bizarre that you can drag a property button, see the value in the button change, and see the results update (since the rna update function is being triggered) but if you do the same thing via an fcurve, see the same value in the button change, no update functions get run. This is throwing a spanner into the works of this ocean sim work, since I need to be able to update the simulation data when parameters (currently belonging to a texture) are changed, eg. 'time'. It works fine when you're dragging values in the property editor, but if you animate it, nothing updates. It's not just updating the sim either, the update functions are used to send depgraph update notices which aren't being sent either. RNA set functions are not appropriate here - I'm not doing anything fancy to the values as they are set, it's just setting DNA directly like most normal RNA properties - the issue is that I'm telling it to update when it's changed, but it's not doing that. How can I make this work? Matt From what I can tell, the reason update functions are not called is because it would slow blender down too much. Especially for arrays - quat's colors, rotations. Where updating a transformation or material 3-4 times will immediately make blender noticeably slower. One possible solution is to queue unique update functions for each update, per ID. A function pointer GHash a check/w previous comparison should make collecting unique functions quite fast. Then these can run at the end, per ID. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Hi Alex, Based on feedback from key developers, the likelyhood there's a relicense to LGPL happing is near zero. Let's focus on ways to get end- user level useful extensions possible. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 24 Nov, 2010, at 1:26, Alex Combas wrote: Hello developers, A common statement I've heard people make when talking about the possibility of a license change is: Its a good idea, but in practical terms it is almost impossible. I do not think that is true. Here is my proposal for how it could be done: ~~~ 1. Wait until Blender gets out of beta. A good first step. 2. Clarify the objective to re-license the code. There are several different proposals for re-licensing Blender. Before proceeding it would be necessary to pick one of them and make a clearly stated goal. For example: Our goal is to re-license the entire Blender code base from GPL to LGPL for the purpose of keeping the code free and protected, while at the same time allowing developers to write extensions which link to Blender to use whatever license they wish for their own code. 3. After having clearly defined the goal it would be necessary to organize a census among the Blender developer community to determine if the majority support this idea. 4. If we reach a state where the majority (at least 60-70%) of the Blender developer community support this idea, then the idea should move forward. But wait! Would it be possible to move forward if there was less than 100% support? Yes. Next the Blender Foundation would need to make an announcement: This is a notice to all past and present Blender developers: We are planning to change the license under which Blender is distributed from GPL to LGPL, this is for the purpose of keeping Blender free and protected, while at the same time allowing other developers to write extensions which link to Blender to use whatever license they wish for their own code. Important: If we have applied patches to the code from you, and you are opposed to this idea then please let us know and we will back out your changes. At this point people should wait for at least a month or two to give any developers who are opposed to the idea adequate time to go through the source and notify the Blender foundation of any sections which they claim they are the authors of and would like to have removed from Blender if the license is changed. Now depending upon how that goes will determine how the license change would proceed. Possibility #1: No developers contact the Blender Foundation and ask for their code to be removed. In this case, license Blender as LGPL and the job is done. Possibility #2: The Blender Foundation is notified by some developers that a few small trivial parts of Blender which they have written would need to be removed. In this case a separate branch could be created which does not contain their code, once the code has been reimplemented then it could be merged with trunk. Then license Blender as LGPL and the job is done. Possibility #3: The Blender Foundation is notified by some developers that one or more major sections of Blender which they have written will need to be removed. In this case it might be possible that their code could be completely removed from Blender and re-built as an extension. For example, lets just say that the compositor was made by a single developer and that this developer does not want his code to be relicensed as LGPL. Since we do not wish to lose the compositor, and it would be impractical to re-implement it, then the only option would be to rebuild the compositor as an extension. In this way the compositor extension would remain GPL in accordance with the authors wishes, and the rest of Blender could still be relicensed as LGPL. Once the code in contention has been reimplemented or modified to function as an extension then merge the branches, license Blender as LGPL, and the job is done. ~~ So that is my proposal. Sorry if it is a bit long winded. It is probably full of many holes which I am blissfully unaware of, but hopefully this can help roll the ball a little further. Best regards, Alex Combas irc: blenderwell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33257] trunk/blender: Changes to the ortho grid drawing based on discussion with Ton.
Am 23.11.2010 15:14, schrieb Campbell Barton: Revision: 33257 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=33257 Author: campbellbarton Date: 2010-11-23 15:14:06 +0100 (Tue, 23 Nov 2010) Log Message: --- Changes to the ortho grid drawing based on discussion with Ton. I did compile with mingw under WinXP, as soon as I use Units and touch the Scale slider blender crashes. Linux 64bit Build is fine. Carsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33257] trunk/blender: Changes to the ortho grid drawing based on discussion with Ton.
very strange that this worked, the float and string argument to the sprintf function were swapped, works now. On Wed, Nov 24, 2010 at 6:29 PM, Carsten Wartmann c...@blenderbuch.de wrote: Am 23.11.2010 15:14, schrieb Campbell Barton: Revision: 33257 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=33257 Author: campbellbarton Date: 2010-11-23 15:14:06 +0100 (Tue, 23 Nov 2010) Log Message: --- Changes to the ortho grid drawing based on discussion with Ton. I did compile with mingw under WinXP, as soon as I use Units and touch the Scale slider blender crashes. Linux 64bit Build is fine. Carsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Wed, Nov 24, 2010 at 9:32 PM, Alex Combas blenderw...@gmail.com wrote: On Wed, Nov 24, 2010 at 10:17 AM, Ton Roosendaal t...@blender.org wrote: Hi Alex, Based on feedback from key developers, the likelyhood there's a relicense to LGPL happing is near zero. Let's focus on ways to get end- user level useful extensions possible. -Ton- Ton I think you know full well the potential which is being thrown away. So if you feel we should not pursue this, then I will agree with you. But I'm disappointed, as far as freedom goes no one would even notice the difference between GPL and LGPL except for people who want to earn a living writing software. LGPL is the best of both worlds. I guess the message is if you want to feed your family, then do not waste your time with open source unless you want to have a hobby, because open source doesn't care if you starve. Looking at this as a Blender hobby user, I keep thinking this. If it goes to LGPL then companies will write really cool extension that I can't buy because if I do my family will starve. Other will not write free extensions that are the same because they are already written. Yes, I am a hobby Blender person that makes my living doing other things. I would have to drop my really cool blender hobby, if I had to start paying big bucks for comical blender stuff. Also, should I want to start up a comical blender based company, I would not want to have to pay the big bucks ether. I would also be happy to contribute free work to blender because of all the free work that was done before by blender people that let me make my company based off of blender. On the practical side, how many companies do we know of that want Blender to go LGPL? It seems to me that we are doing a lot of talking about something I have yet to see the real solid demand for. On the other hand I am all for keeping blender flexible as a tool. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Hi, On Wed, Nov 24, 2010 at 9:32 PM, Alex Combas blenderw...@gmail.com wrote: Ton I think you know full well the potential which is being thrown away. So if you feel we should not pursue this, then I will agree with you. But I'm disappointed, as far as freedom goes no one would even notice the difference between GPL and LGPL except for people who want to earn a living writing software. LGPL is the best of both worlds. I guess the message is if you want to feed your family, then do not waste your time with open source unless you want to have a hobby, because open source doesn't care if you starve. Let's not paint this issue in black and white, LGPL for example also means properietary software could take parts of Blender code and use it. If Blender would have many properietary plugins and modifications, it does result in a different development dynamic. I personally don't have a strong opinion on this, but I don't think it's an obvious choice. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On 25/11/2010 7:17 a.m., Ton Roosendaal wrote: Hi Alex, Based on feedback from key developers, the likelyhood there's a relicense to LGPL happing is near zero. Let's focus on ways to get end- user level useful extensions possible. Is there a way to have closed source extensions work within Blender? or does this require a new license for the entire software. It seems the original discussion of Creating closed source extensions has been turned into a discussion of an impossible task of re-licensing Blender. 1) Import and export extensions seem to be fine, since they don't touch the other software, but only the output. However, a dynamic import/export (like many new packages) would be impossible? 2) Would a plug-in system like Make-human (if it were still a plug-in) be impossible? -Ton- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Where to store physics related data
Do it in modifier data, I'm pretty sure current softbody is like that for historical reasons, from before it was rolled into the modifier stack system. Matt On Thu, Nov 25, 2010 at 3:38 AM, Gergely Klár shin...@creativereboot.hu wrote: Hi all, I'm working on an improved softbody modifier from scratch. What is the best place to store modifier related data, like mass, velocity, additional geometry used only for the simulation, etc.? I have looked at the code of both the current softbody and the cloth modifier, and they seem to this in two different ways. Cloth stores its data in a ClothModifierData struct, just I would do by instinct. On the other hand softbody adds a SoftBody pointer to the Object struct. Is one approach better than the other? If it is, which and why? Thanks, Greg ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Wed, Nov 24, 2010 at 1:32 PM, Alex Combas blenderw...@gmail.com wrote: But I'm disappointed, as far as freedom goes no one would even notice the difference between GPL and LGPL except for people who want to earn a living writing software. LGPL is the best of both worlds. Yeah, well, other than the people who would notice the 'lesser' freedom. I guess the message is if you want to feed your family, then do not waste your time with open source unless you want to have a hobby, because open source doesn't care if you starve. Open Source loves you. Still don't see what's so difficult about writing a BSD 'interface' layer built on top of some libffi shenanigans. The libffi authors apparently even care enough about your family's daily food intake to use 'a very liberal license'. Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
if you distribute an LGPL application you MUST provide the source code if you modify and distribute an LGPL application you MUST provide the source code. It is NO different than the GPL in this regard. The only difference is that if a separate program links to an LGPL program then the separate program is not forced to be licensed as LGPL, but with GPL then it is forced to do so. I think there are people here who do not understand this. @Knapp There are a billion closed source applications in this world, and yet you are not starving. Neither will you be starving if there is one more closed source application in the world. Blender itself will not ever be less free than it is now. If anyone modifies Blender then they must also distribute their modified source code. I didn't want to write a long reply, but it looks like this will be a long reply, and this will also be my last reply on this subject since I'm giving up on it. There are too many people opposed to something they don't understand. But I would like to at least try to divorce some of that misunderstanding before I go. Take this example: An artist uses Blender to create some art work, and they decide to sell it. Nobody complains. It took the artist years of training and weeks of effort to make their product. Nobody says You used Blender to make your product, Blender is free, you must make your product free or we will sue you. A programmer comes along, the programmer does not modify Blender but instead writes a separate program which uses Blender to do something special, something which Blender can not do right now. It took the programmer years of training and weeks of effort to make their product. Just as much skill and effort as the artist. But now everyone screams at them You used Blender to make your product, Blender is free, you must make your product free or we will sue you. I can understand people would be upset if the programmer had modified Blender but he did NOT modify Blender at all, he simply used Blender in a similar way that an artist would use Blender to create artwork. LGPL would allow this programmer to earn a living just like an artist, but GPL would put this programmer in jail for not making their product free. If you are still confused please re-read the beginning of this email. @Brecht LGPL for example also means properietary software could take parts of Blender code and use it Why is that a problem if the source code is still published just as it is now under GPL? You do understand that LGPL means the source code must be published, right? I would have thought that the legal requirement to publish the source code would be enough to make Blender developers happy. @Doug Is there a way to have closed source extensions work within Blender? No, that is the whole point, if you link to GPL code then you must license your code as GPL. Any attempt to do anything else is an attempt to break the GPL, or to find a loophole in the GPL. The whole point of the GPL is to stop that behavior. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
You seem to be co-mingling your free (gratis) and free (libre). Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
I thought Ton was clear enough the first time, but apparently not, so let me reiterate: - Based on feedback from key developers, the likelyhood there's a relicense to LGPL happing is near zero. Let's focus on ways to get end- user level useful extensions possible. - Alex, please drop it. You're not helping your position with false dichotomies and misrepresentations. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
I can understand people would be upset if the programmer had modified Blender but he did NOT modify Blender at all, he simply used Blender in a similar way that an artist would use Blender to create artwork. The programmer is free to use IPC for that purpose. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
El Wed, 24 Nov 2010 09:28:03 -0600 Christopher Allan Webber cweb...@dustycloud.org escribió: There's been a lot of discussion on here about how could we move to a point where we weaken the copyleft Blender has? I would just like to put in that not everyone hopes this will happen... I do not hope it will happen. I personally think the lack of a copyright assignment within Blender, and using the GPL, is actually tremendously to Blender's advantage: it keeps the copyleft strong, even when people don't want it to be.. example, now. This is a feature! Agreed! that makes the probability of there being an Autodesk Blender infinitesimal. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Wed, Nov 24, 2010 at 3:09 PM, Martin Poirier the...@yahoo.com wrote: I thought Ton was clear enough the first time, but apparently not, so let me reiterate: - Based on feedback from key developers, the likelyhood there's a relicense to LGPL happing is near zero. Let's focus on ways to get end- user level useful extensions possible. - Alex, please drop it. You're not helping your position with false dichotomies and misrepresentations. Hello Martin, If you had read my last comment before you made yours you would have seen that I had already said this will be my last reply on this subject since I'm giving up on it and so there was no need for you say anything at all. But I have to say false dichotomies and misrepresentations is rude and uncalled for. I don't think you were intending to be rude, so I'm just going to forget about it, but I hope you don't usually treat people this way. Making statements like that is what leads to flame wars and I'm sure that nobody wants to see that. All the best, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On 25/11/2010 10:09 AM, Martin Poirier wrote: I thought Ton was clear enough the first time, but apparently not, so let me reiterate: - Based on feedback from key developers, the likelyhood there's a relicense to LGPL happing is near zero. Let's focus on ways to get end- user level useful extensions possible. - I am personally quite happy to see Blender remain licensed as GPL (especially as opposed to LGPL). LGPL allows the functionality of Blender to be gutted and stuck into another application. For example, it would be possible for C4D, Maya, whatever to take the LSCM module and use it without contributing anything back to Blender. A plugin, on the other hand, explicitly is contributing to Blender (at least if it wants any kind of use/sales) because it is an extension to the application as opposed to an application being extended by Blender. As things appear to stand (the plugin documentation is apparently only current to Blender 2.31), we have a requirement of linking to Blender definition files in order to be useful. Is there a reason that the definition plugin required header files need to be SOLELY GPL? Could they not be distributed on their own as interface specifications under a more lenient (perhaps BSD-with-credit) license? There are copyright exceptions allowed for interface requirements (should it be needed) and provided the header/def files were indeed used only for interfacing with Blender - this solution seems feasible. Especially if the Blender Foundation were to make an explicit statement to their purpose and the licensing restrictions (or lack thereof) they place upon them. -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
This debate is going nowhere. I get an impression that some people simply can't accept the fact that a lots of developers are working on Blender code exactly because GPL license ensures them that their hard work will not end up in some closed source software. And I don't think that they are all starving because of that. We should have a way to efficiently use proprietary plug-ins but I don't see how transferring all source to LGPL would benefit Blender. Exactly an opposite. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On 25/11/2010 5:30 PM, Damir Prebeg wrote: This debate is going nowhere. I think parts of it are moving forward. There are some people that don't want the debate at all and some that are taking rejection of their ideas as a complete rejection of the concept of proprietary plugins. I don't think they are the majority or the sum total of people involved though. I get an impression that some people simply can't accept the fact that a lots of developers are working on Blender code exactly because GPL license ensures them that their hard work will not end up in some closed source software. I don't think *anyone* is suggesting that the Blender code end up in some closed source software. We're looking at making Blender capable (legally) of using third-party distributed closed-source plugins. This is about *extending* Blender, not taking parts of it and making them proprietary. And I don't think that they are all starving because of that. I agree with you there. Not everyone who codes does it for a living, not everyone who codes does it as a product (as opposed to a service), and it is not like Blender isn't already paying for some people to code on/for it (and above starvation levels of reimbursement! -grin-). I agree the false dichotomy of what is being claimed about about copyleft-supporters is as false (and as insulting) as the implication that those desiring proprietary EXTENSIONS to Blender are trying to steal the code squirrel it away in closed source software. We should have a way to efficiently use proprietary plug-ins but I don't see how transferring all source to LGPL would benefit Blender. Exactly an opposite. This I agree with too. LGPL will allow, if only through careful extraction of code into a shared library, the extraction of code from the Blender project into closed source projects. Personally, even though I am for the capability of Blender to use support proprietary plugins; I am against changing the source code to LGPL. It has also been stated that this would be an impossibility. -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Wed, Nov 24, 2010 at 10:38 PM, Benjamin Tolputt btolp...@internode.on.net wrote: This I agree with too. LGPL will allow, if only through careful extraction of code into a shared library, the extraction of code from the Blender project into closed source projects. Personally, even though I am for the capability of Blender to use support proprietary plugins; I am against changing the source code to LGPL. It has also been stated that this would be an impossibility. I think a lot of people are agreeable to the idea of closed source plugins for Blender. But there is really no way to do that with the GPL ...unless you try to break the GPL somehow by using shims or some other sort of loophole. But why continue to use the GPL if you are looking for ways to break it. Why not just switch to a license which allows closed extensions? Personally I am against trying to break the GPL and I would not support such an effort. That is why instead I made this proposal to switch, but it is safe to say that this proposal has been completely rejected. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On 25/11/2010 6:19 PM, Alex Combas wrote: I think a lot of people are agreeable to the idea of closed source plugins for Blender. I think you'd be right ;) But there is really no way to do that with the GPL ...unless you try to break the GPL somehow by using shims or some other sort of loophole. Whether one thinks of it as a loophole or simply an allowed method of doing so would be a matter of opinion, I think. If the loophole is still possible in GPL3, the FSF at least don't think of it as one :) But why continue to use the GPL if you are looking for ways to break it. Why not just switch to a license which allows closed extensions? Well, unless you are starting a project from scratch AND removing all the GPL libraries used, you're stuck with GPL. Personally, I think of it as a fine license for the stated purpose of Blender (I was open to dual licensing as well but it never got off the ground). Given there are contributors that are heavily against changing the license and the fact that any reimplementation may as well be a separate project (can one call a ground up complete rewrite Blender or just inspired by it?) - whether we like the GPL or not, it is the one we're stuck with. As much as I hate to be brash, I think you'll have to accept that because enough people (with code contributions in Blender) have stated they won't accept anything else. Personally I am against trying to break the GPL and I would not support such an effort. As I said above. Being able to use proprietary libraries is not considered by everyone breaking the GPL. If you don't want to support the effort, that's fine and dandy but I doubt that is going to stop anyone more than your opposition to Blender's use GPL prevented people speaking out for it. That is why instead I made this proposal to switch, but it is safe to say that this proposal has been completely rejected. Whether it is safe to say it was rejected or not doesn't matter. What has been determined is that the effort required (given the opinion of some major contributors) makes the proposal a practical impossibility. Blender would need to be rewritten from the ground up and I don't think anyone has the stomach for that. I know if it was suggested seriously by Ton company, I'd be forking (or supporting a fork of) Blender because I couldn't wait as long as would be required to see the new version. We need to consider the effort available, the effort required, and the main contributors' desires in the equation - even if it annoys the @#$% out of us (as other decisions have). The time for license changing was *quite* some time ago, the horse has bolted long ago on that change. Let's move forward and see what we can do NOW :) -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
