Re: [Bf-committers] extension clause
That sentence is also unclear to me. If I understand it right, that means that Blender can't have for instance, a legal VRay plugin. That doesn't make much sense because If any proprietary program can use GPL'd DLL as long as they provide license and access to the code of that DLL, why GPL program shouldn't be able to use proprietary DLL? If Python script and MyDLL doesn't use any GPL code, I don't see a reason that they couldn't be published under a different license than GPL. That's not supporting of proprietary code. Few years a go I've watched a discussion about Python scripts for Blender and licensing and someone stated that If some script needs Blender to work, then It can not be published under any license but GPL. And what If that script is divided in two parts? One that works only in Blender and second that uses only generic python? For instance, first one takes Blender mesh, gathers vertex coordinates and face data, creates generic lists and exports them to second one. That way second one can be used by any program that can create lists. Damir On 6 October 2010 04:43, Roger Wickes rogerwic...@yahoo.com wrote: What is not OK about it? I think it is clear that the Blender Foundation cannot support proprietary code. If you have the situation where a company wants to build some DLL and keep it proprietary, then never release it to the public. Guard it as your own intellectual property. Use your code to your competitive advantage. I have a client who did just that. Their scripts that they wrote and paid for are theirs. They license their code and have a great business model. Their complete solution includes Blender, but they do not sub-license Blender or steal code; instead the customer gets Blender from BF, and their solution from them. Or do you have the situation where you want to develop a plugin to Blender that you license out (sell) to customers? --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: john grant johnkonradgr...@yahoo.com To: bf-committers@blender.org Sent: Tue, October 5, 2010 10:09:50 PM Subject: [Bf-committers] extension clause Hello, I assume this topic has been brought up before, but I have not yet found evidence of those conversations. I would like to voice my opinion to find out what is the truth. If I am not understanding correctly, please let me know. I presume that the following text, Not OK is: Author publishes a Blender script, calling a compiled C library with own code, both under own license. from this source, http://www.blender.org/education-help/faq/gpl-for-artists/ ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
This is one of those questions that end up being decided by case law. The issue is what is an aggregate and what is a modified version. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation It is tricky to define where the line between these is drawn, as much of it depends on the nature of the connection between the Blender-part and the external part. If public APIs are used on both sides, then it comes closer to aggregation. If private APIs are used, closer to modified version. I had this same discussion with the authors of JBoss, an EJB Server, a while back. There, too, one could write plugins for the server. The end result was that as long as the plugin only used public APIs (Java standards), you could do anything you wanted. /LS On 2010-10-06 06:56, Dan Eicher wrote: As long as myDLL didn't link to or rely on any gpl'd code there's nothing anyone can say about how people use it -- except for the copyright owner of course. Bundling (distributing it and blender in the same 'package') is probably not an option though. The bottom line is that we consider everything you can create in Blender as 'data', including Blender scripts. But when you extend Blender with other facilities you have to follow the regulations of the GPL. ...snip... The divider is If the script runs in the Blender Interpretor. When the script calls code not running in the Blender Interpretor you are making bindings to other facilities, and the regular GNU GPL rules apply. Hmm... so one can only make calls to gpl compatible code if they want to distribute a script that runs in blender's interpreter? That doesn't sound right. ___ 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] OpenGL Profiles Project?
Thank you very much guys, this is very good information. Keep it coming if anyone else has anything they think is obvious, but which might not be clear yet. On Tue, Oct 5, 2010 at 2:28 PM, Mathew Burrack mburr...@yahoo.com wrote: I actually had to write similar code back in the day for realMYST/URU for handling the peculiarities of various graphics cards (and back then, there were a TON more of them!). Having the user select a profile still doesn't make sense; instead, all it really takes is a bitfield of what capabilities you want to run with, which the OGL code checks (are GL_POINTS supported? If that bit is set, go that path, else go the fallback path, etc). In an ideal world, all you have to do is populate that bitfield with what you can detect from GL_EXTENSIONS, etc. Obviously, though, that never really works. So instead, you have a list of exceptions, keyed off of the reported device name, vendor name, and driver version, that says force this bit off or force this bit on. The startup code populates the bitfield based on what it detects, then checks the list of exceptions for bits to fix based on the card detected. That way, the user never has to select anything, and the code automatically does what it's supposed to, and enabling/disabling certain functionality based on a graphics card misbehaving is a simple matter of adding a line or two to the exception file (which can easily be tweaked based on bug reports from various users based on their gfx card; what's more, testing the fix with that user is dead simple, since all you have to do is send them a new exceptions list). ...worked on realMYST/URU just fine, at least :) -Mathew --- On Tue, 10/5/10, Tom M letter...@gmail.com wrote: From: Tom M letter...@gmail.com Subject: Re: [Bf-committers] OpenGL Profiles Project? To: bf-blender developers bf-committers@blender.org Date: Tuesday, October 5, 2010, 11:00 AM It might be worth looking at how Ogre and possibly CrystalSpace handle this. LetterRip On Tue, Oct 5, 2010 at 9:29 AM, Ton Roosendaal t...@blender.org wrote: Hi, The sad truth is that the implementation of Opengl, driver versions, bugs in drivers, all make Opengl not work as smooth as it could be. The idea of a Profile is that you can setup per-system settings that match the used hardware. These could be topics like: - FSA - Buffer swap methods - Bitmap support - mipmap settomgs - GLSL support levels - VBO (I guess) - dual graphics cards (?) - multi monitor setups, or stereo - This should not to be automatically checked on, because most cards support it more or less. The profile is to ensure you can get maximum performance and best quality user experience. What is also possible it to extend our bgl calls (like bglBegin(GL_POINTS)), which wraps specific problematic calls in Opengl to match what we expect. The choosen profile can work that way without polluting the code with checks, making it all local in a single C file or so. If you check in our code, the places where opengl extension or vendor strings are being checked is probably a good indication where we have issues. Hope this info helps. Be warned it's not the best beginner code project, good understanding of opengl on various systems, and on how Blender uses opengl is required. And don't forget Mesa! Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 5 Oct, 2010, at 8:50, Mathew Burrack wrote: Not to butt in here, but what exactly is the point of the OpenGL profiles? To simplify setting up OpenGL display settings? What's wrong with auto-detecting what the card is capable of and just using that? Is the goal to avoid settings that are buggy on certain cards? It just seems to me like the end users would want it to Just Work and not care (or even necessarily know about) the difference between the profiles, and would just end up picking the first one that worked, not necessarily the best one. (Just trying to understand the goal here :) --mcn --- On Mon, 10/4/10, Knapp magick.c...@gmail.com wrote: From: Knapp magick.c...@gmail.com Subject: Re: [Bf-committers] OpenGL Profiles Project? To: bf-blender developers bf-committers@blender.org Date: Monday, October 4, 2010, 11:12 PM Might start by doing a hardware poll among the users. Perhaps on the Blender.org site and also a few of the other bigger blender sites. I would bet that you could find a much narrower design goal that way. I will start out here. Nvidia Gforce 7600 GS. A nice card for blender but I am hoping to update soon.
Re: [Bf-committers] OpenGL Profiles Project?
Hi, A user-definable profile will allow you to make Blender behave as you want, and not behave as the drivers, vendor strings, bugs, exceptions, and our smart developers think it will be. You can always do a good guess first though, but in the end allowing to tweak some important settings will only benefit for using Blender. Simple example: some systems do support GL_POINTS only for point size 1. Some only draw such points as squares, others as rounded shapes. You can try to get this all sorted out by smart guessing, but in the end it pays off to have the user make a decision what's acceptable, or where other methods are preferred. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 5 Oct, 2010, at 20:28, Mathew Burrack wrote: I actually had to write similar code back in the day for realMYST/ URU for handling the peculiarities of various graphics cards (and back then, there were a TON more of them!). Having the user select a profile still doesn't make sense; instead, all it really takes is a bitfield of what capabilities you want to run with, which the OGL code checks (are GL_POINTS supported? If that bit is set, go that path, else go the fallback path, etc). In an ideal world, all you have to do is populate that bitfield with what you can detect from GL_EXTENSIONS, etc. Obviously, though, that never really works. So instead, you have a list of exceptions, keyed off of the reported device name, vendor name, and driver version, that says force this bit off or force this bit on. The startup code populates the bitfield based on what it detects, then checks the list of exceptions for bits to fix based on the card detected. That way, the user never has to select anything, and the code automatically does what it's supposed to, and enabling/disabling certain functionality based on a graphics card misbehaving is a simple matter of adding a line or two to the exception file (which can easily be tweaked based on bug reports from various users based on their gfx card; what's more, testing the fix with that user is dead simple, since all you have to do is send them a new exceptions list). ...worked on realMYST/URU just fine, at least :) -Mathew --- On Tue, 10/5/10, Tom M letter...@gmail.com wrote: From: Tom M letter...@gmail.com Subject: Re: [Bf-committers] OpenGL Profiles Project? To: bf-blender developers bf-committers@blender.org Date: Tuesday, October 5, 2010, 11:00 AM It might be worth looking at how Ogre and possibly CrystalSpace handle this. LetterRip On Tue, Oct 5, 2010 at 9:29 AM, Ton Roosendaal t...@blender.org wrote: Hi, The sad truth is that the implementation of Opengl, driver versions, bugs in drivers, all make Opengl not work as smooth as it could be. The idea of a Profile is that you can setup per-system settings that match the used hardware. These could be topics like: - FSA - Buffer swap methods - Bitmap support - mipmap settomgs - GLSL support levels - VBO (I guess) - dual graphics cards (?) - multi monitor setups, or stereo - This should not to be automatically checked on, because most cards support it more or less. The profile is to ensure you can get maximum performance and best quality user experience. What is also possible it to extend our bgl calls (like bglBegin(GL_POINTS)), which wraps specific problematic calls in Opengl to match what we expect. The choosen profile can work that way without polluting the code with checks, making it all local in a single C file or so. If you check in our code, the places where opengl extension or vendor strings are being checked is probably a good indication where we have issues. Hope this info helps. Be warned it's not the best beginner code project, good understanding of opengl on various systems, and on how Blender uses opengl is required. And don't forget Mesa! Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 5 Oct, 2010, at 8:50, Mathew Burrack wrote: Not to butt in here, but what exactly is the point of the OpenGL profiles? To simplify setting up OpenGL display settings? What's wrong with auto-detecting what the card is capable of and just using that? Is the goal to avoid settings that are buggy on certain cards? It just seems to me like the end users would want it to Just Work and not care (or even necessarily know about) the difference between the profiles, and would just end up picking the first one that worked, not necessarily the best one. (Just trying to understand the goal here :) --mcn --- On Mon,
Re: [Bf-committers] extension clause
Think about it this way. A program that runs under Linux uses OS API's. Even though Linux is GPL, the program does not have to be GPL. Blender is a facility. If you use publicly-available APIs to write an extension to Blender, or even a whole suite of programs like an AutoCAD-type, you can license your Intellectual Property any way you want to. What you cannot do is to take some existing Blender module, extend it with your own code, and then license that module back out. --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: Leo Sutic leo.su...@gmail.com To: bf-blender developers bf-committers@blender.org Sent: Wed, October 6, 2010 3:23:50 AM Subject: Re: [Bf-committers] extension clause This is one of those questions that end up being decided by case law. The issue is what is an aggregate and what is a modified version. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation It is tricky to define where the line between these is drawn, as much of it depends on the nature of the connection between the Blender-part and the external part. If public APIs are used on both sides, then it comes closer to aggregation. If private APIs are used, closer to modified version. I had this same discussion with the authors of JBoss, an EJB Server, a while back. There, too, one could write plugins for the server. The end result was that as long as the plugin only used public APIs (Java standards), you could do anything you wanted. /LS On 2010-10-06 06:56, Dan Eicher wrote: As long as myDLL didn't link to or rely on any gpl'd code there's nothing anyone can say about how people use it -- except for the copyright owner of course. Bundling (distributing it and blender in the same 'package') is probably not an option though. The bottom line is that we consider everything you can create in Blender as 'data', including Blender scripts. But when you extend Blender with other facilities you have to follow the regulations of the GPL. ...snip... The divider is If the script runs in the Blender Interpretor. When the script calls code not running in the Blender Interpretor you are making bindings to other facilities, and the regular GNU GPL rules apply. Hmm... so one can only make calls to gpl compatible code if they want to distribute a script that runs in blender's interpreter? That doesn't sound right. ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
i think the person who made that statement is wrong. Any program needs an OS to work, yet you can license your program differently from the way the OS is licensed. The API is the dividing line. If you dance on the outside of the API, your stuff is yours. --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: Michelangelo Manrique michelangelomanri...@hotmail.com To: bf-blender developers bf-committers@blender.org Sent: Wed, October 6, 2010 3:08:19 AM Subject: Re: [Bf-committers] extension clause well, sentences like If something needs x to work... is little bit tricky. After all you require a pc to run scripts independently what they do. If we see little bit far away we can say you can't publish anything under GPL because you require an Intel chipset to make it running or you require Windows or anything else... this is a point of view issue after all imo. On Wed, 2010-10-06 at 08:20 +0200, Damir Prebeg wrote: That sentence is also unclear to me. If I understand it right, that means that Blender can't have for instance, a legal VRay plugin. That doesn't make much sense because If any proprietary program can use GPL'd DLL as long as they provide license and access to the code of that DLL, why GPL program shouldn't be able to use proprietary DLL? If Python script and MyDLL doesn't use any GPL code, I don't see a reason that they couldn't be published under a different license than GPL. That's not supporting of proprietary code. Few years a go I've watched a discussion about Python scripts for Blender and licensing and someone stated that If some script needs Blender to work, then It can not be published under any license but GPL. And what If that script is divided in two parts? One that works only in Blender and second that uses only generic python? For instance, first one takes Blender mesh, gathers vertex coordinates and face data, creates generic lists and exports them to second one. That way second one can be used by any program that can create lists. Damir On 6 October 2010 04:43, Roger Wickes rogerwic...@yahoo.com wrote: What is not OK about it? I think it is clear that the Blender Foundation cannot support proprietary code. If you have the situation where a company wants to build some DLL and keep it proprietary, then never release it to the public. Guard it as your own intellectual property. Use your code to your competitive advantage. I have a client who did just that. Their scripts that they wrote and paid for are theirs. They license their code and have a great business model. Their complete solution includes Blender, but they do not sub-license Blender or steal code; instead the customer gets Blender from BF, and their solution from them. Or do you have the situation where you want to develop a plugin to Blender that you license out (sell) to customers? --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: john grant johnkonradgr...@yahoo.com To: bf-committers@blender.org Sent: Tue, October 5, 2010 10:09:50 PM Subject: [Bf-committers] extension clause Hello, I assume this topic has been brought up before, but I have not yet found evidence of those conversations. I would like to voice my opinion to find out what is the truth. If I am not understanding correctly, please let me know. I presume that the following text, Not OK is: Author publishes a Blender script, calling a compiled C library with own code, both under own license. from this source, http://www.blender.org/education-help/faq/gpl-for-artists/ ___ 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 ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
Hi all, Thanks for contributing to the discussion. It isn't clear to me what the final decision is. I think many of you (Dan, Damir, others) see the issue with the wording and understand what I'm trying to do (definitely nothing malicious toward Blender) which is to extend Blender to do new things via a script or plugin. Blender has created facilities for extension, but the language used by the Foundation makes it DEBATABLE that the extension may need to have a license compatible with the GPL. The situation (probably common, like the VRay example) is that a script or plugin can be written to use the Blender API from within Blender AND call a DLL with a different license. I can think of several examples that the community is probably already using or would like to use that may be violating the language used by the Blender Foundation. Again, I think Blender will be well served by allowing for such extensions. Will the Blender Foundation provide language that removes any doubt that proprietary DLLs can be used from at least one form of extension mechanism? Thanks, John From: Roger Wickes rogerwic...@yahoo.com To: bf-blender developers bf-committers@blender.org Sent: Wed, October 6, 2010 6:20:38 AM Subject: Re: [Bf-committers] extension clause Think about it this way. A program that runs under Linux uses OS API's. Even though Linux is GPL, the program does not have to be GPL. Blender is a facility. If you use publicly-available APIs to write an extension to Blender, or even a whole suite of programs like an AutoCAD-type, you can license your Intellectual Property any way you want to. What you cannot do is to take some existing Blender module, extend it with your own code, and then license that module back out. --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: Leo Sutic leo.su...@gmail.com To: bf-blender developers bf-committers@blender.org Sent: Wed, October 6, 2010 3:23:50 AM Subject: Re: [Bf-committers] extension clause This is one of those questions that end up being decided by case law. The issue is what is an aggregate and what is a modified version. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation It is tricky to define where the line between these is drawn, as much of it depends on the nature of the connection between the Blender-part and the external part. If public APIs are used on both sides, then it comes closer to aggregation. If private APIs are used, closer to modified version. I had this same discussion with the authors of JBoss, an EJB Server, a while back. There, too, one could write plugins for the server. The end result was that as long as the plugin only used public APIs (Java standards), you could do anything you wanted. /LS On 2010-10-06 06:56, Dan Eicher wrote: As long as myDLL didn't link to or rely on any gpl'd code there's nothing anyone can say about how people use it -- except for the copyright owner of course. Bundling (distributing it and blender in the same 'package') is probably not an option though. The bottom line is that we consider everything you can create in Blender as 'data', including Blender scripts. But when you extend Blender with other facilities you have to follow the regulations of the GPL. ...snip... The divider is If the script runs in the Blender Interpretor. When the script calls code not running in the Blender Interpretor you are making bindings to other facilities, and the regular GNU GPL rules apply. Hmm... so one can only make calls to gpl compatible code if they want to distribute a script that runs in blender's interpreter? That doesn't sound right. ___ 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 ___ 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] extension clause
Probably our FAQ should list possible ways to write closed source code with blender, rather then only saying whats not possible. AFAIK there are a few ways... 1) run your closed source code in a separate process and have your own opensouce module communicate with it (pipes, sockets, shared-mem). 2) do what nvidia do on linux. mix closed and open code but distribute separately. this means the violation only happens on the system where both are installed and running. 3) do whatever the heck you like but only use internally or share with clients but dont sell or distribute pubically. On Wed, Oct 6, 2010 at 3:36 PM, john grant johnkonradgr...@yahoo.com wrote: Hi all, Thanks for contributing to the discussion. It isn't clear to me what the final decision is. I think many of you (Dan, Damir, others) see the issue with the wording and understand what I'm trying to do (definitely nothing malicious toward Blender) which is to extend Blender to do new things via a script or plugin. Blender has created facilities for extension, but the language used by the Foundation makes it DEBATABLE that the extension may need to have a license compatible with the GPL. The situation (probably common, like the VRay example) is that a script or plugin can be written to use the Blender API from within Blender AND call a DLL with a different license. I can think of several examples that the community is probably already using or would like to use that may be violating the language used by the Blender Foundation. Again, I think Blender will be well served by allowing for such extensions. Will the Blender Foundation provide language that removes any doubt that proprietary DLLs can be used from at least one form of extension mechanism? Thanks, John From: Roger Wickes rogerwic...@yahoo.com To: bf-blender developers bf-committers@blender.org Sent: Wed, October 6, 2010 6:20:38 AM Subject: Re: [Bf-committers] extension clause Think about it this way. A program that runs under Linux uses OS API's. Even though Linux is GPL, the program does not have to be GPL. Blender is a facility. If you use publicly-available APIs to write an extension to Blender, or even a whole suite of programs like an AutoCAD-type, you can license your Intellectual Property any way you want to. What you cannot do is to take some existing Blender module, extend it with your own code, and then license that module back out. --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: Leo Sutic leo.su...@gmail.com To: bf-blender developers bf-committers@blender.org Sent: Wed, October 6, 2010 3:23:50 AM Subject: Re: [Bf-committers] extension clause This is one of those questions that end up being decided by case law. The issue is what is an aggregate and what is a modified version. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation It is tricky to define where the line between these is drawn, as much of it depends on the nature of the connection between the Blender-part and the external part. If public APIs are used on both sides, then it comes closer to aggregation. If private APIs are used, closer to modified version. I had this same discussion with the authors of JBoss, an EJB Server, a while back. There, too, one could write plugins for the server. The end result was that as long as the plugin only used public APIs (Java standards), you could do anything you wanted. /LS On 2010-10-06 06:56, Dan Eicher wrote: As long as myDLL didn't link to or rely on any gpl'd code there's nothing anyone can say about how people use it -- except for the copyright owner of course. Bundling (distributing it and blender in the same 'package') is probably not an option though. The bottom line is that we consider everything you can create in Blender as 'data', including Blender scripts. But when you extend Blender with other facilities you have to follow the regulations of the GPL. ...snip... The divider is If the script runs in the Blender Interpretor. When the script calls code not running in the Blender Interpretor you are making bindings to other facilities, and the regular GNU GPL rules apply. Hmm... so one can only make calls to gpl compatible code if they want to distribute a script that runs in blender's interpreter? That doesn't sound right. ___ 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 ___ Bf-committers mailing list
Re: [Bf-committers] extension clause
Related to this, wouldn't it suffice to release the RNA and bpy modules under a less restrictive license (BSD) to potentially solve this issue? I think we can reasonably track down all contributors to these modules, as they're fairly recent and all of the APIs scripts use are bridged by these two modules so it should screen out any possible licensing conflicts? The same would be true for C extensions, by using RNA exclusively to access the Blender API. Or does the fact that RNA itself uses GPL'd code influence this possibility? Campbell Barton wrote, on 10/06/2010 05:07 PM: Probably our FAQ should list possible ways to write closed source code with blender, rather then only saying whats not possible. AFAIK there are a few ways... 1) run your closed source code in a separate process and have your own opensouce module communicate with it (pipes, sockets, shared-mem). 2) do what nvidia do on linux. mix closed and open code but distribute separately. this means the violation only happens on the system where both are installed and running. 3) do whatever the heck you like but only use internally or share with clients but dont sell or distribute pubically. On Wed, Oct 6, 2010 at 3:36 PM, john grantjohnkonradgr...@yahoo.com wrote: Hi all, Thanks for contributing to the discussion. It isn't clear to me what the final decision is. I think many of you (Dan, Damir, others) see the issue with the wording and understand what I'm trying to do (definitely nothing malicious toward Blender) which is to extend Blender to do new things via a script or plugin. Blender has created facilities for extension, but the language used by the Foundation makes it DEBATABLE that the extension may need to have a license compatible with the GPL. The situation (probably common, like the VRay example) is that a script or plugin can be written to use the Blender API from within Blender AND call a DLL with a different license. I can think of several examples that the community is probably already using or would like to use that may be violating the language used by the Blender Foundation. Again, I think Blender will be well served by allowing for such extensions. Will the Blender Foundation provide language that removes any doubt that proprietary DLLs can be used from at least one form of extension mechanism? Thanks, John From: Roger Wickesrogerwic...@yahoo.com To: bf-blender developersbf-committers@blender.org Sent: Wed, October 6, 2010 6:20:38 AM Subject: Re: [Bf-committers] extension clause Think about it this way. A program that runs under Linux uses OS API's. Even though Linux is GPL, the program does not have to be GPL. Blender is a facility. If you use publicly-available APIs to write an extension to Blender, or even a whole suite of programs like an AutoCAD-type, you can license your Intellectual Property any way you want to. What you cannot do is to take some existing Blender module, extend it with your own code, and then license that module back out. --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! - Original Message From: Leo Suticleo.su...@gmail.com To: bf-blender developersbf-committers@blender.org Sent: Wed, October 6, 2010 3:23:50 AM Subject: Re: [Bf-committers] extension clause This is one of those questions that end up being decided by case law. The issue is what is an aggregate and what is a modified version. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation It is tricky to define where the line between these is drawn, as much of it depends on the nature of the connection between the Blender-part and the external part. If public APIs are used on both sides, then it comes closer to aggregation. If private APIs are used, closer to modified version. I had this same discussion with the authors of JBoss, an EJB Server, a while back. There, too, one could write plugins for the server. The end result was that as long as the plugin only used public APIs (Java standards), you could do anything you wanted. /LS On 2010-10-06 06:56, Dan Eicher wrote: As long as myDLL didn't link to or rely on any gpl'd code there's nothing anyone can say about how people use it -- except for the copyright owner of course. Bundling (distributing it and blender in the same 'package') is probably not an option though. The bottom line is that we consider everything you can create in Blender as 'data', including Blender scripts. But when you extend Blender with other facilities you have to follow the regulations of the GPL. ...snip... The divider is If the script runs in the Blender Interpretor. When the script calls code not running in the Blender Interpretor you are making bindings to other
Re: [Bf-committers] extension clause
Date: Wed, 6 Oct 2010 16:07:13 + From: Campbell Barton ideasma...@gmail.com Subject: Re: [Bf-committers] extension clause 3) do whatever the heck you like but only use internally or share with clients but dont sell or distribute pubically. Absolutely DO NOT distribute Blender pubically!! There has GOT to be something in the GPL against that :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On Wed, Oct 6, 2010 at 9:07 AM, Campbell Barton ideasma...@gmail.comwrote: ...snip... 2) do what nvidia do on linux. mix closed and open code but distribute separately. this means the violation only happens on the system where both are installed and running. That is merely tolerated by Linus et al. and is probably a violation of the gpl from what I understand. And, if you look into it a bit, they have a 'fine line' between public api (good) and other kernel level calls (bad) which in blender would most likely translate to py-api (good) and ctypes (bad). Found an article from the recent WordPress gpl dustup that explains the distinction pretty well -- http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-derivative-of-wordpress/. It kind of seems from the FSF analysis of 'themes' -- http://wordpress.org/news/2009/07/themes-are-gpl-too/ -- that operators and extensions would indeed be subject to the gpl since they are intermingled with and operated on by blender code. I'm also thinking that calling external renderers is probably good (vray example) since they aren't designed to run linked together in a shared address space but the actual blender exporter script is most likely subject to the gpl. But, as always, seek proper legal council. Dan** ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On 07/10/2010, at 05:20 , Dan Eicher wrote: I'm also thinking that calling external renderers is probably good (vray example) since they aren't designed to run linked together in a shared address space but the actual blender exporter script is most likely subject to the gpl. I think the VRay query is not related to use of python per se, but potentially what would happen with a C or C++ RNA API/Render API, which could be used like a 'normal' render plugin in other software, without having to go through python. On 07/10/2010, at 00:23 , Roger Wickes wrote: i think the person who made that statement is wrong. Any program needs an OS to work, yet you can license your program differently from the way the OS is licensed. The API is the dividing line. If you dance on the outside of the API, your stuff is yours. Unfortunately, the GPL itself doesn't seem so clear on this. And in many cases I think it's quite silly and doesn't really do anything to preserve the open-ness of an application. On 07/10/2010, at 03:07 , Campbell Barton wrote: AFAIK there are a few ways... 1) run your closed source code in a separate process and have your own opensouce module communicate with it (pipes, sockets, shared-mem). 2) do what nvidia do on linux. mix closed and open code but distribute separately. this means the violation only happens on the system where both are installed and running. This is kinda funny to me, in that awkward solutions like this would seem more compliant with 'the letter of the law', when in effect its really the same end result, without any differing levels of open-ness in blender itself. It seems to me that criteria like shared address space/dlopen/etc are a bit arbitrary in deciding whether its a single program, or two, communicating via an API. I suspect if such a case went to court, the question would be judged more on that 'is it a modified single program' issue, rather than 'does it satisfy these arbitrary technical requirements via obtuse workarounds'. AFAIK this part hasn't been tested in court. Personally I'd just go and do what you want anyway, especially if as you say it's not a modification to Blender itself. I don't think any blender developers will sue you - I promise not to, at least ;) Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] new patch:uniform displace modifier when no texture is present
https://projects.blender.org/tracker/index.php?func=detailaid=24177group_id=9atid=127 copy pasted from the patch description: this removes the need for adding a texture if all you want is a uniform push over the entire mesh using the displace modifier. now my usual workflow is to use the displace modifier + one single colored texture when i am retopologizing a mesh so the new mesh will be sightly above the surface instead of partially hidden this patch removes the need for that texture step. now this works in x y z and normal mode disabled the xyz-rgb one since it would just result in the entire mesh being pushed in the all axises at once. and it works just as before with a texture present. compiled against rev:32357 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL Profiles Project?
Hi, mburr...@yahoo.com (2010-10-06 at 0815.35 -0700): The irony is that, at least IMHO, the specific example you gave actually supported my idea of *not* having user intervention. Specifically, you're putting the burden on the user to determine whether their graphics card supports GL_POINTS correctly or not. End users don't want to bother with that; they just want to get modeling! Some cards/drivers claim X, then give you X by software (looks correct, but too slow) or X done to the basic level required by spec (compliant but slow and/or not looking as expected by coder that wanted the extras). In both cases, being able to manually pick Y is a lot better than being stuck with X, even if down the road an exception will be added so Blender knows it has to pick Y, because all that time you have been enjoying X. Or the other option, the driver gets fixed or improved and X becomes fast and implements the full spec, so now Y is the wrong thing. One example inside Blender is swap mode (triple buffer, overlap, etc). It sounded like a great thing, but once people started testing with other cards than the developer's one, problems appeared. Auto select was added to tune out of the box behaviour, but manual override was kept. As another example of thrusting the drivers to use advertised options, that are slower and worse looking than the old fallbacks, you can check the latest rants arround KDE. Probably if they had an manual override from start they could had collect user reports to make better guesses, whilst people would be getting good performance until a new release that integrates the changes is done. So having a manual option means reducing the pains but also the delays from updating to guess code. IE, happier users, and even better, people being able to test what workarrounds must be added or if the old workarround can be disabled now or still needed. [...] The code could also store what exception set from the exceptions file matched the current profile. If/when the Python API is called to change a value in the profile, we automatically write out the updated exceptions to the exception file. That way, developers (and hard-core users) have a way of tweaking the exceptions file without manually editing it, and plus they can check the tweaks in real-time. If someone tweaks their particular setup to a better profile, all they have to do is submit the updated exceptions file as a patch, and we merge in the new set of exceptions (after any appropriate testing, of course). So in the end there should be a manual override system on top of code that tries to do a first guess. Just like the swap method selection. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL Profiles Project?
Specifically, you're putting the burden on the user to determine whether their graphics card supports GL_POINTS correctly or not. End users don't want to bother with that; they just want to get modeling! Some cards/drivers claim X, then give you X by software (looks correct, but too slow) or X done to the basic level required by spec (compliant but slow and/or not looking as expected by coder that wanted the extras). In both cases, being able to manually pick Y is a lot better than being stuck with X, Actually, in both cases, *using* Y is a lot better than being stuck with X. Manually choosing Y has nothing to do with it, because in both cases, X will be unequivocally less desirable. Do you want the option to be able to Y instead of X in those cases? Absolutely. Should the user have to intervene to pick Y instead of X? No, not if at all possible. Or the other option, the driver gets fixed or improved and X becomes fast and implements the full spec, so now Y is the wrong thing. At which point, you update the exceptions list from: vendor.device.*: do Y instead of X to: vendor.device.version foobar: do Y instead of X This is expected, and inevitable as drivers are updated. *Something* will have to be changed as the drivers are updated; in my case, it's just a configuration file instead of the code, and all you need is one updated exception config file to push out to users, instead of having every single user go back into the preferences and unselect the do Y instead of X option. In fact, in my proposal, instead of *every* user doing that, only *one* has to do that and submit the updated exceptions file as a patch. All future users benefit automatically. So having a manual option means reducing the pains but also the delays from updating to guess code. IE, happier users, and even better, people being able to test what workarrounds must be added or if the old workarround can be disabled now or still needed. ... So in the end there should be a manual override system on top of code that tries to do a first guess. Just like the swap method selection. My suggestion for the Python API for the exceptions list satisfies that. Yes, you need the manual control one way or another; the fundamental difference I'm proposing is that, instead of having *every* user needing to modify those exceptions manually, that we save them back out and store them in such a way that they can be submitted as a patch so that, ideally, only one user (or at least a small subset) need to actually bother with the manual control. Everyone else just downloads an update and benefits automatically. --mcn ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] BGE Components Proposal
HI Mitchell. I have no familiarity with Unity (although always heard wonders about it) nevertheless it sounds like an interesting feature. I confess that the workflow confused me a little bit. Why to go to outliner instead of loading the class straight from a text (internal or not) datablock? If I'm not mistaken your original proposal (the one in the video) was doing something like this, no? Some details: 1) how to tell blender what is the type of the game property you are adding (in your example Health, Energy and Regen are floats, but and if they are boolean, strings, timer, ...) 2) your update function runs every logic tic. I can see some cases where this is more often than the necessary (given the overhead that python+logics can sometimes produce). Maybe something to be workarounded with some internal counter (e.g. if counter%5: return). Those are my 2 cents for now. I think that to be able to do more with python is a great gain for BGE. Too bad we don't have a feature roadmap, but from my understanding this kind of functionality fits well with present and future plans for BGE. Dalai 2010/10/5 Mitchell Stokes moguri...@gmail.com I would like feedback on this proposal: http://wiki.blender.org/index.php/User:Moguri/BGE_Components_Proposal It is a proposal to add Unity-like components to the BGE. I plan to hopefully implement this soon, but as I said, I would like some feedback. Thanks, Mitchell Stokes (Moguri) ___ 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
