Re: [Bf-committers] extension clause
On Mon, Nov 22, 2010 at 7:20 AM, Alex Combas blenderw...@gmail.com wrote: On Sun, Nov 21, 2010 at 9:05 PM, Campbell Barton ideasma...@gmail.com wrote: While this is what blenders GPL exception states it does seem quite fuzzy as to what it does/doesn't apply to. - python its self has many compiled extensions, ok so it cant/shouldn't apply to this case but where does it end? - what if the extension loads a module such as PIL, numpy, or PyGame???, I'm not sure in this case.. - what if you write your own module but make it BSD/GPL/Apache and have it as a package which can be installed by debian's package manager for eg. So I'm guessing this is how it works... - You can write your own BSD module and include no problems - since this is what we do with python. - You can write your own GPL module as long as you include the same exception that blender its self has. - You CAN'T make use of a 3rd party GPL module unless they make the same allowances that blender does. Hi Campbell, I have a question for you. The way it was explained to me is that you can license your Blender python script any way you want (closed, BSD, GPL, foo, bar, baz) as long as it only links to things which were shipped as part of Blender and this includes the interpreter and any modules which are shipped along with the interpreter. However if your Blender python script links to anything which is not distributed as part of the Blender package then it is an extension and must be GPL licensed. Is my understanding correct? I did say in my post before that I'm not clear on this but I think this is correct. My point was that there shouldn't be any difference between using pythons pickle module for eg, or some other BSD licensed module, the current wording makes out there is. Also, how do you feel about the idea of relicensing Blender to be LGPL similar to glibc? In light of what the FSF has said particularly about LGPL and glibc. Blender has obviously gotten by without the proprietary software developers so far, is that something you want to see continue, or do you think it would be a good thing to open up this market? This is why we used the Lesser GPL for the GNU C library. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another—no problem for them, only for us. http://www.gnu.org/licenses/why-not-lgpl.html Or to translate that into Blender terms... There are plenty of other (Animation/Modeling/Compositing) libraries, using the GPL for ours would have driven proprietary software developers to use another--no problem for them, only for us. Probably the first question to ask is if all blender developers blender foundation wanted to re-license blender as LGPL is this even possible? Take a look at ./intern/ ./extern/ folders since these contain the most code that was not written by blender developers (external libs we build into blenders binary but distribute with blender). -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On Sun, Nov 21, 2010 at 6:31 PM, Benjamin Tolputt btolp...@internode.on.net wrote: On 22/11/2010 10:46 AM, Dan Eicher wrote: More likely your crime would preclude you from being protected under thelicensing terms since you were never the legal recipient of said software. Just because something is under the GPL doesn't give anyone carte blanche permission to use, modify and copy but merely the folks who legally obtained it. Quite simply put, you are wrong on this. Once the code has been distributed, it is legal for me to have distribute a copy of it. The hacking is illegal but the GPL license on the material makes it's distribution legal once it has been sent off-site already. The laws around hacking concern themselves with the intrusion, fraud, and damage caused. They leave the distribution of material obtained to the laws concerning copyright and trade secrets (where they are already adequately covered). Again, this is not something I am pulling out of thin air but what is being advised to corporate decision makers by legal representatives. Until such time as it is proven in court, this is the best a corporate head can hope for in terms of what is isn't legal. -- Regards, Benjamin Tolputt Analyst Programmer from the faq; If someone steals a CD containing a version of a GPL-covered program, does the GPL give him the right to redistribute that version? If the version has been released elsewhere, then the thief probably does have the right to make copies and redistribute them under the GPL, but if he is imprisoned for stealing the CD he may have to wait until his release before doing so. If the version in question is unpublished and considered by a company to be its trade secret, then publishing it may be a violation of trade secret law, depending on other circumstances. The GPL does not change that. If the company tried to release its version and still treat it as a trade secret, that would violate the GPL, but if the company hasn't released this version, no such violation has occurred. So, yeah, according to the FSF a stolen version is ok to distribute... not that I agree with their reasoning on this though. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On 22/11/2010 8:06 PM, Dan Eicher wrote: So, yeah, according to the FSF a stolen version is ok to distribute... not that I agree with their reasoning on this though. This is also the conclusion of the legal representation I've been able to talk to about it (in regards to licensing software which had trade secret code mixed in with GPL code). They too thought it was a stupid result, but it is a valid reading of the license terms (and good lawyers are good at finding the worst possible, yet still valid interpretations of legal clauses). In my experience, this resulted in weird situations where vital parts of company infrastructure were leased from a third-party mixing GPL code in with code containing (dubiously valued) trade secrets. As the code itself never left the corporate property of the developers, it was classified as not being distributed. This, however, was in a server / network environment. Blender, being a client utility, does not lend itself to such creative solutions. -- Regards, Benjamin Tolputt Analyst Programmer ___ 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 [33216] trunk/blender/source/blender/ editors/interface/interface.c: Bugfix #24825
Hi, Good find, will fix too! :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 22 Nov, 2010, at 6:37, Matt Ebb wrote: On Mon, Nov 22, 2010 at 4:23 AM, Ton Roosendaal t...@blender.org wrote: Revision: 33216 Log Message: --- Bugfix #24825 Error in alignment code caused some buttons to draw not nicely aligned, like the Frame rate buttons in Render properties. I think this commit may have had the side effect of disrupting the 3D View layer buttons.. ___ 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, Phew, mind boggling discussions here. I know GNU GPL isn't easy to understand, but it would improve readability of the traffic on this list if we can stop with interpretations of the GNU GPL now. :) However, taking a position on what we want for the future in general is still relevant. David raised an issue - and he wasn't the first one - how to cope with the fact that GPL is not very permissive to extend or use with proprietary development. Basically there are two cases we can investigate: 1) Allow anyone to extend Blender, linked dynamically with scripts or libraries or plugins 2) Allow anyone to dynamically link in Blender libraries in their own programs The LGPL will only allow the latter. For the first we have to devise an extension clause (if we want to stick to GPL). Actions: - I can do the next weeks/months more research to gather information via other OS projects about their experience with GPL in commercial environments. I'll report back on this. - Finding out from significant contributors to Blender how they personally feel about re-licensing or extensions My personal opinion: I don't like the idea to switch entire Blender to LGPL much. Blender is a 3D artist tool, not a development environment with libraries. It's positive that people can add libraries in Blender without forcing them to make it available for everyone as LGPL. Allowing Blender to be extended more easily (scripts, plugins, libs) is more interesting. In that respect I recognize practices in studios, and how support companies like to work. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] New procedural texture: Planet
Hi all :) This weekend I need to create a procedural planet for a local work, so I went straigth to tinkering with built in procedural textures, sadly there where no simple combination of procedurals that provide me satellite like view of planet surfaces, in order to achieve that a procedural should have some desired properties: It should have iso - lines that remind same high levels, like coastal lines or lines like rivers, erosion and features like that. (the closer built in procedural that currently have similar features in Blender is stucci at high octaves and turbulence and the magic one, but is not enough and are quite self similar at every scale) It should be fractal like but should not be very similar among scales because otherwise you get very similar and smooth detail at every scale (like currently happen with Cloud porcedural) It should provide detail enough at all scales in order to avoid increasing the number of noise octaves beyond wthat's currently blender have built in, for planet surfaces extremely close shorts should be made to the surface or build very big spheres, and from far away any smoothness will be inmediately spotted. The usual approach is to use lots of layers and composited procedurals in order to achive that, with the corresponding slow down, and trial and error approach or use some of the excelent directly aviable satellite pictures of planets (not an option for people offline like me). So I end up creating a new procedural: Planet texture, that has all the needed features and more, it provides enough detail at every scale and more important, is not very similar at different scales so zooming in will give you an entirely different view with new details and features in the terrain, it also have iso-lines and features that simulate erosion, rivers, platforms, and more , all using a single procedural!!! It also have a very interesting feature: at small scales it have a curl like behaviour, and adding more octaves, will add more small curls, unlike the current Magic texture that only add detail to the existent loops, this will prove usefull for rocks, and texture driven flow for particles. As always a picture worth a thousand word, judge yourself, I think this texture is worth integration ;) Hope you like it. I have send my post to Lapinou to be uploaded in my site soon. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New procedural texture: Planet
and no picture is worth exactly how many words? :) Daniel Salazar www.3developer.com On Mon, Nov 22, 2010 at 9:33 AM, ra...@info.upr.edu.cu wrote: Hi all :) This weekend I need to create a procedural planet for a local work, so I went straigth to tinkering with built in procedural textures, sadly there where no simple combination of procedurals that provide me satellite like view of planet surfaces, in order to achieve that a procedural should have some desired properties: It should have iso - lines that remind same high levels, like coastal lines or lines like rivers, erosion and features like that. (the closer built in procedural that currently have similar features in Blender is stucci at high octaves and turbulence and the magic one, but is not enough and are quite self similar at every scale) It should be fractal like but should not be very similar among scales because otherwise you get very similar and smooth detail at every scale (like currently happen with Cloud porcedural) It should provide detail enough at all scales in order to avoid increasing the number of noise octaves beyond wthat's currently blender have built in, for planet surfaces extremely close shorts should be made to the surface or build very big spheres, and from far away any smoothness will be inmediately spotted. The usual approach is to use lots of layers and composited procedurals in order to achive that, with the corresponding slow down, and trial and error approach or use some of the excelent directly aviable satellite pictures of planets (not an option for people offline like me). So I end up creating a new procedural: Planet texture, that has all the needed features and more, it provides enough detail at every scale and more important, is not very similar at different scales so zooming in will give you an entirely different view with new details and features in the terrain, it also have iso-lines and features that simulate erosion, rivers, platforms, and more , all using a single procedural!!! It also have a very interesting feature: at small scales it have a curl like behaviour, and adding more octaves, will add more small curls, unlike the current Magic texture that only add detail to the existent loops, this will prove usefull for rocks, and texture driven flow for particles. As always a picture worth a thousand word, judge yourself, I think this texture is worth integration ;) Hope you like it. I have send my post to Lapinou to be uploaded in my site soon. Cheers Farsthary ___ 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
On Sun, Nov 21, 2010 at 3:30 PM, Dan Eicher d...@trollwerks.org wrote: I believe it's important to many users (especially, but not limited to corporate users) to have a secondary 'proprietary plugin market', That option has been discussed and all but approved, the only hitch is the plugin writers also have to write and maintain the BSD (or whatever) api shim code. How is legally viable to make a capable BSD licensed API with the code under the GPL? The shim would be dependent on material details of the Blender design and internals. It would probably expose many of those details (such as UI panels, RNA) As a result, the shim should be under the GPL, and as a result, the extensions should be under the GPL. During this discussion we talked about the license extension exception. This applies to Blender embedding Python, effectively making it a 'library exception'. Python was a pre-existing library which is not-GPL, and thus is covered under the GPL library exception clause. Python does not depend on any details of blender. In fact, it's the other way around, Blender depends on Python. If I understand correctly, in order to apply this license exception, the authors of all those details (UI, RNA) would need to approve the 'exception' of the shim-library, and they would need to depend on it's details, not the other way around. It's interesting to note that if Blender wanted to be non-GPL, and Python was GPL, it wouldn't be legal to embed it into Blender. One of the biggest benefits of Python is that it can be linked with anything without license restriction. It's shown up in all kinda of software, free and commercial, and been a stronger open-source project for it. Ton wrote Basically there are two cases we can investigate: 1) Allow anyone to extend Blender, linked dynamically with scripts or libraries or plugins 2) Allow anyone to dynamically link in Blender libraries in their own programs The LGPL will only allow the latter. For the first we have to devise an extension clause (if we want to stick to GPL). The LGPL would allow either. In order for someone to write a non-LGPL plugin, their code must depend on details of the LGPL code, and link against the LGPL code, both of which are allowed by the LGPL. When you say extension clause are you referring to authoring a unique-to-Blender extension clause which deviates from the GPL? or using the GPL Library Exception provisions? As I wrote above, in order for the library-exception clause to allow closed-source extensions, Blender would need to carve bunch of existing code into a ui and rna library, which is put under a a less restrictive license and is then becomes the library exception. This is the route GIMP took. They used the LGPL for that library, since the LGPL allows you to link it into closed source without contamination. Using a less restrictive license would obviously also work. I don't see solid comfortable legal ground for claiming that all 3rd party extensions are after the fact library exceptions, using the GPL's library exception clause. If this is the route you intend, it would help substantially if you could get FSF to publish a specific position on this direction. It's kind of funny how people/companies are willing to contribute code to (and use) Linux more than all the BSD put together yet Linux has a more restrictive license. You'd think they would all be scared away from the GPL and go towards a license where they don't have to worry about having their code 'virally' infected or 'lost' if they (accidently or otherwise) distribute it. But they don't which IMHO says a lot. Linux can be extended by writing applications. Those applications do not sit in the same address-space as the Linux kernel, and they compile against glibc and other libraries, not the kernel itself. No GPL contamination. All that is required for the community to adopt a solution is for that solution to have critical mass and have a license compatible with them building and distributing anything they want, with any license they want. Linux provides this. A GPL Blender does not. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
Hi David, Sorry, my mistake :) LGPL covers both cases I sketched. For now I'd like to hear first from our key contributors how they feel about the general idea. There's no reason to hurry with this, I'll try to settle it with final proposal before we move to a final stable 2.6. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 22 Nov, 2010, at 17:02, David Jeske wrote: On Sun, Nov 21, 2010 at 3:30 PM, Dan Eicher d...@trollwerks.org wrote: I believe it's important to many users (especially, but not limited to corporate users) to have a secondary 'proprietary plugin market', That option has been discussed and all but approved, the only hitch is the plugin writers also have to write and maintain the BSD (or whatever) api shim code. How is legally viable to make a capable BSD licensed API with the code under the GPL? The shim would be dependent on material details of the Blender design and internals. It would probably expose many of those details (such as UI panels, RNA) As a result, the shim should be under the GPL, and as a result, the extensions should be under the GPL. During this discussion we talked about the license extension exception. This applies to Blender embedding Python, effectively making it a 'library exception'. Python was a pre-existing library which is not-GPL, and thus is covered under the GPL library exception clause. Python does not depend on any details of blender. In fact, it's the other way around, Blender depends on Python. If I understand correctly, in order to apply this license exception, the authors of all those details (UI, RNA) would need to approve the 'exception' of the shim-library, and they would need to depend on it's details, not the other way around. It's interesting to note that if Blender wanted to be non-GPL, and Python was GPL, it wouldn't be legal to embed it into Blender. One of the biggest benefits of Python is that it can be linked with anything without license restriction. It's shown up in all kinda of software, free and commercial, and been a stronger open-source project for it. Ton wrote Basically there are two cases we can investigate: 1) Allow anyone to extend Blender, linked dynamically with scripts or libraries or plugins 2) Allow anyone to dynamically link in Blender libraries in their own programs The LGPL will only allow the latter. For the first we have to devise an extension clause (if we want to stick to GPL). The LGPL would allow either. In order for someone to write a non-LGPL plugin, their code must depend on details of the LGPL code, and link against the LGPL code, both of which are allowed by the LGPL. When you say extension clause are you referring to authoring a unique-to-Blender extension clause which deviates from the GPL? or using the GPL Library Exception provisions? As I wrote above, in order for the library-exception clause to allow closed-source extensions, Blender would need to carve bunch of existing code into a ui and rna library, which is put under a a less restrictive license and is then becomes the library exception. This is the route GIMP took. They used the LGPL for that library, since the LGPL allows you to link it into closed source without contamination. Using a less restrictive license would obviously also work. I don't see solid comfortable legal ground for claiming that all 3rd party extensions are after the fact library exceptions, using the GPL's library exception clause. If this is the route you intend, it would help substantially if you could get FSF to publish a specific position on this direction. It's kind of funny how people/companies are willing to contribute code to (and use) Linux more than all the BSD put together yet Linux has a more restrictive license. You'd think they would all be scared away from the GPL and go towards a license where they don't have to worry about having their code 'virally' infected or 'lost' if they (accidently or otherwise) distribute it. But they don't which IMHO says a lot. Linux can be extended by writing applications. Those applications do not sit in the same address-space as the Linux kernel, and they compile against glibc and other libraries, not the kernel itself. No GPL contamination. All that is required for the community to adopt a solution is for that solution to have critical mass and have a license compatible with them building and distributing anything they want, with any license they want. Linux provides this. A GPL Blender does not. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New procedural texture: Planet
Thanks Tomas :) Yes, indeed will be very helpfull for your sci-fi project, as soon as Lapinou upload it check my site http://farsthary.wordpress.com , I made there a comparison with current textures to see their limitations. I will polish today the patch and will release it by tomorrow, hope it will help you, is a fairly simple patch and will not disrrupt anything in Blender Cheers Farsthary Hey Raul, this feature sounds just awesome! You have my full support on it! Something I wanted for 3 years... Can't wait to see images. cheers, Thomas Am 22.11.2010 16:33, schrieb ra...@info.upr.edu.cu: Hi all :) This weekend I need to create a procedural planet for a local work, so I went straigth to tinkering with built in procedural textures, sadly there where no simple combination of procedurals that provide me satellite like view of planet surfaces, in order to achieve that a procedural should have some desired properties: It should have iso - lines that remind same high levels, like coastal lines or lines like rivers, erosion and features like that. (the closer built in procedural that currently have similar features in Blender is stucci at high octaves and turbulence and the magic one, but is not enough and are quite self similar at every scale) It should be fractal like but should not be very similar among scales because otherwise you get very similar and smooth detail at every scale (like currently happen with Cloud porcedural) It should provide detail enough at all scales in order to avoid increasing the number of noise octaves beyond wthat's currently blender have built in, for planet surfaces extremely close shorts should be made to the surface or build very big spheres, and from far away any smoothness will be inmediately spotted. The usual approach is to use lots of layers and composited procedurals in order to achive that, with the corresponding slow down, and trial and error approach or use some of the excelent directly aviable satellite pictures of planets (not an option for people offline like me). So I end up creating a new procedural: Planet texture, that has all the needed features and more, it provides enough detail at every scale and more important, is not very similar at different scales so zooming in will give you an entirely different view with new details and features in the terrain, it also have iso-lines and features that simulate erosion, rivers, platforms, and more , all using a single proce ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On Mon, Nov 22, 2010 at 9:02 AM, David Jeske dav...@gmail.com wrote: On Sun, Nov 21, 2010 at 3:30 PM, Dan Eicher d...@trollwerks.org wrote: I believe it's important to many users (especially, but not limited to corporate users) to have a secondary 'proprietary plugin market', That option has been discussed and all but approved, the only hitch is the plugin writers also have to write and maintain the BSD (or whatever) api shim code. How is legally viable to make a capable BSD licensed API with the code under the GPL? The shim would be dependent on material details of the Blender design and internals. It would probably expose many of those details (such as UI panels, RNA) As a result, the shim should be under the GPL, and as a result, the extensions should be under the GPL. The same way the (BSD licensed) ofx api can load proprietary code/libs. Blender can link to the header files and the *users* load/link to the non-gpl compatible external code (which also links to the BSD'd header files)... everyone gets what they want and no copyrights are violated. Drinks for everyone!!! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FFMPEG properties from Blender presets overridden by defaults?
Don't forget that all of your work will be color clamped / matrixed if you encode directly using ffmpeg. Such is the nature of RGB to YCbCr / YUV transforms via ffmpeg's swscale. If you seek quality, your only recourse is to oversee the transforms from RGB to YUV or YCbCr yourself. Sincerely, TJS On Nov 20, 2010 9:26 AM, Randall Rickert rand...@rickert-digital.com wrote: My goal is to encode H264 Quicktime files that are compatible with Apple's Quicktime Player (should not be too much to ask, right?). Before 2.5, I could do this by tweaking the individual ffmpeg options that were exposed in the UI after selecting the H264 preset. That preset was clearly designed for making H264 AVI files, but it would work for Quicktime after changing the container format and tweaking ffmpeg options, especially getting rid of flags:loop. 2.5 doesn't expose those options in the UI. They seem to be hardcoded in source/blender/blenkernel/intern/writeffmpeg.c under case FFMPEG_PRESET_H264. They mirror the options in libx264-default.preset that is distributed with ffmpeg. So I'm editing the settings in writeffmpeg.c to see if I can get Blender to write a QT Player-compatible Quicktime movie. No matter what I do to those settings, Blender's stderr stream shows that it is still using the defaults, not the settings I modified. The settings seem to be stored in a RenderData-ffcodecdata.properties, but I get lost (I'm not a programmer) as I try to figure out where they come from, since they obviously don't come from the FFMPEG_PRESET_H264 settings I edited. Any help? Thanks, Randall p.s.: Please don't suggest rendering an image sequence, then encoding from the command line! That's what I do for 3D renders, but I want to encode output from the VSE. It seems stupid to render an image sequence from the VSE, because it would just duplicate the same frames I already have on disk but with different frame numbers, wasting a lot of disk space. ___ 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
On Mon, Nov 22, 2010 at 10:40 AM, Dan Eicher d...@trollwerks.org wrote: How is legally viable to make a capable BSD licensed API with the code under the GPL? The shim would be dependent on material details of the Blender design and internals. It would probably expose many of those details (such as UI panels, RNA) As a result, the shim should be under the GPL, and as a result, the extensions should be under the GPL. The same way the (BSD licensed) ofx api can load proprietary code/libs. BSD Licensed code can do anything it likes. BSD license does not attempt to control the license of other code it links to like the GPL does. This is not a valid example. Blender can link to the header files and the *users* load/link to the non-gpl compatible external code (which also links to the BSD'd header files)... everyone gets what they want and no copyrights are violated. Drinks for everyone!!! Although the BSD above is confusing the example, I agree that by my read of the GPL, an open-source GPL blender extension can load/call to a third-party closed-source binary code library under the GPL's library exception. What this means is that any extension UI, code that touches RNA, any code which touches any detail of blender would need to be open-sourced under the GPL. While the core algorithm which must not be at all dependent on or link against blender details, can be closed-source. This is unlike extensions for tools such as Maya or 3dsmax, where the entire extension, including UI and data-manipulation may all be closed source. I believe this means some types of commercial extensions are viable (such as a file format reader/writer), and some types of commercial extensions not as viable (a UI extension or addin based on data-transformation within blender). I'm undecided whether this is enough. A company considering releasing an extension for blender may find the idea of having to open-source a chunk of the extension is unfamiliar, which might prevent them from doing it. However, it looks like that chunk would merely contain glue-code that doesn't reveal their proprietary invention. I'll need to think about this some more and consult some contacts in the industry to form an opinion. This is an excellent point (which I think has been mentioned before, but I didn't quite see it this way until your paragraph above). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
Whatever licence that will not restrict Blender in the present and the future from being used in any enviroment, open or close, is ok to me :) Cheers Raul Hi David, Sorry, my mistake :) LGPL covers both cases I sketched. For now I'd like to hear first from our key contributors how they feel about the general idea. There's no reason to hurry with this, I'll try to settle it with final proposal before we move to a final stable 2.6. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On Mon, Nov 22, 2010 at 6:58 AM, Ton Roosendaal t...@blender.org wrote: Hi all, Phew, mind boggling discussions here. I know GNU GPL isn't easy to understand, but it would improve readability of the traffic on this list if we can stop with interpretations of the GNU GPL now. :) However, taking a position on what we want for the future in general is still relevant. David raised an issue - and he wasn't the first one - how to cope with the fact that GPL is not very permissive to extend or use with proprietary development. Basically there are two cases we can investigate: 1) Allow anyone to extend Blender, linked dynamically with scripts or libraries or plugins 2) Allow anyone to dynamically link in Blender libraries in their own programs The LGPL will only allow the latter. For the first we have to devise an extension clause (if we want to stick to GPL). Actions: - I can do the next weeks/months more research to gather information via other OS projects about their experience with GPL in commercial environments. I'll report back on this. - Finding out from significant contributors to Blender how they personally feel about re-licensing or extensions My personal opinion: I don't like the idea to switch entire Blender to LGPL much. Blender is a 3D artist tool, not a development environment with libraries. It's positive that people can add libraries in Blender without forcing them to make it available for everyone as LGPL. Allowing Blender to be extended more easily (scripts, plugins, libs) is more interesting. In that respect I recognize practices in studios, and how support companies like to work. Hey Ton You really nailed it with this post. Its really reassuring to see you understand the issues and you are not opposed to the idea of non-GPL licensing for extensions. I look forward to hearing the results of your research. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New procedural texture: Planet
Here are the pictures from Raul, pretty cool! http://www.pasteall.org/pic/show.php?id=7077 http://www.pasteall.org/pic/show.php?id=7078 http://www.pasteall.org/pic/show.php?id=7079 http://www.pasteall.org/pic/show.php?id=7080 http://www.pasteall.org/pic/show.php?id=7081 http://www.pasteall.org/pic/show.php?id=7082 http://www.pasteall.org/pic/show.php?id=7083 http://www.pasteall.org/pic/show.php?id=7084 http://www.pasteall.org/pic/show.php?id=7085 http://www.pasteall.org/pic/show.php?id=7086 http://www.pasteall.org/pic/show.php?id=7087 Daniel Salazar www.3developer.com On Mon, Nov 22, 2010 at 12:30 PM, ra...@info.upr.edu.cu wrote: Thanks Tomas :) Yes, indeed will be very helpfull for your sci-fi project, as soon as Lapinou upload it check my site http://farsthary.wordpress.com , I made there a comparison with current textures to see their limitations. I will polish today the patch and will release it by tomorrow, hope it will help you, is a fairly simple patch and will not disrrupt anything in Blender Cheers Farsthary Hey Raul, this feature sounds just awesome! You have my full support on it! Something I wanted for 3 years... Can't wait to see images. cheers, Thomas Am 22.11.2010 16:33, schrieb ra...@info.upr.edu.cu: Hi all :) This weekend I need to create a procedural planet for a local work, so I went straigth to tinkering with built in procedural textures, sadly there where no simple combination of procedurals that provide me satellite like view of planet surfaces, in order to achieve that a procedural should have some desired properties: It should have iso - lines that remind same high levels, like coastal lines or lines like rivers, erosion and features like that. (the closer built in procedural that currently have similar features in Blender is stucci at high octaves and turbulence and the magic one, but is not enough and are quite self similar at every scale) It should be fractal like but should not be very similar among scales because otherwise you get very similar and smooth detail at every scale (like currently happen with Cloud porcedural) It should provide detail enough at all scales in order to avoid increasing the number of noise octaves beyond wthat's currently blender have built in, for planet surfaces extremely close shorts should be made to the surface or build very big spheres, and from far away any smoothness will be inmediately spotted. The usual approach is to use lots of layers and composited procedurals in order to achive that, with the corresponding slow down, and trial and error approach or use some of the excelent directly aviable satellite pictures of planets (not an option for people offline like me). So I end up creating a new procedural: Planet texture, that has all the needed features and more, it provides enough detail at every scale and more important, is not very similar at different scales so zooming in will give you an entirely different view with new details and features in the terrain, it also have iso-lines and features that simulate erosion, rivers, platforms, and more , all using a single proce ___ 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
A reply to the list in general, People have wanted real world cases: The following is an example of where the GPL is being used to actively limit commercial use of a PHP add-on class. http://www.interpid.eu/component/content/article/47 Note that the GPL version is available to the general public, but to use it in business, you need to purchase a separate license so that your own code doesn't become GPL Very clever business model, but it highlights the issue well! Doug Ollivier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
What happens when a third party writes a script that links to an external library? an example in the current code would be the quicktime libs THE USER has to sign up for the licence agreement of the quicktime sdk, obtain the source and then compile their own blender... This is common in music software too for Steinbergs VST support: user gets SDK by signing up to EULA then compiles their own version It's fine in teh above cases to distribute the code without Infecting either Apples code or Steinbergs... Both SDKs have a EULA that prohibits re-distribution, which presumably protects them... it's the end user doing the linking In blender's case this becomes interesting with say the Autodesk FBX sdk which has a similar restriction... So here's what I don't get: Are things really any more complicated if a compile wasn't necessary? say if Quicktime support, VST or FBX could be added via a python script? just because it's compiled on the fly? Requiring the user to sign up to any 3rd party libs agreement with a no re-distribution clause (common in commercial software) then there can surely be a commercial path to extend blender already existing That or Apple, Steinberg and Autodesk are already infected by the GPL by no act of their own... I'm guessing this must be the case else the blender Vray script would infect vray? Or is the act of compiling the difference? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On 22/11/10 21:21, Michael Williamson wrote: . It's fine in teh above cases to distribute the code without Infecting either Apples code or Steinbergs... i meant the linking code! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
--- On Mon, 11/22/10, Doug Ollivier d...@flipdesign.co.nz wrote: A reply to the list in general, People have wanted real world cases: The following is an example of where the GPL is being used to actively limit commercial use of a PHP add-on class. http://www.interpid.eu/component/content/article/47 Note that the GPL version is available to the general public, but to use it in business, you need to purchase a separate license so that your own code doesn't become GPL Very clever business model, but it highlights the issue well! That is actually against the terms of the GPL. They cannot restrict usage like this. If that is what they want to do with their license, it is not GPL compatible and the FSF should send them a strongly worded leter. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
The GPL is not an exclusive license. Developers are free to publish their works under multiple licenses if they own the copyright outright. On Mon, Nov 22, 2010 at 1:47 PM, Martin Poirier the...@yahoo.com wrote: --- On Mon, 11/22/10, Doug Ollivier d...@flipdesign.co.nz wrote: A reply to the list in general, People have wanted real world cases: The following is an example of where the GPL is being used to actively limit commercial use of a PHP add-on class. http://www.interpid.eu/component/content/article/47 Note that the GPL version is available to the general public, but to use it in business, you need to purchase a separate license so that your own code doesn't become GPL Very clever business model, but it highlights the issue well! That is actually against the terms of the GPL. They cannot restrict usage like this. If that is what they want to do with their license, it is not GPL compatible and the FSF should send them a strongly worded leter. Martin ___ 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
--- On Mon, 11/22/10, Dahlia Trimble dahliatrim...@gmail.com wrote: The GPL is not an exclusive license. Developers are free to publish their works under multiple licenses if they own the copyright outright. Of course, that's nowhere near what I said. When they say that their GPL licensed version free is for non-commercial work only, they are putting further restrictions on their licensee, making their license not GPL compatible. Nothing is stopping them from also releasing a version under closed source license with a fee attached, to go along with their almost-GPL version. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
http://en.wikipedia.org/wiki/PyQt PyQt is developed by the British firm Riverbank Computing. It is available under similar terms to Qt versions older than 4.5; this means a variety of licenses including GNU General Public License (GPL) and commercial license, but not the GNU Lesser General Public License (LGPL). -- 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
