Re: Liberal corporate open source policies
On Tue, Mar 22, 2011 at 09:07:40PM -0700, Henri Yandell wrote: ... except that the ASF would never actually use this document. Legal affairs expertise is a limited resource, and if we don't have skin in the game, I'm hesitant to suggest that it live there. I'll challenge that one. The ASF employ individuals to develop, and they contribute back as a part of their job. Ah, good point! So potential goal there - your liberal policy would have to stretch to the extremes of the ASF and other foundation employers. +1. Let's at least draft it in such a way that the ASF might conceivably adopt it. ASF adoption might prove infeasible for any number of unforseen reasons, but if it happens, it will send a signal that we think the document is at least legally sound. You're right that setting that goal will constrain the policy's content. I imagine Joe Schaefer would chafe if he had to get management approval to whitelist each project he wanted to contribute to. :) I've looked around the community.apache.org website, and while there is not an obvious home for it there, it's an interesting question whether a place could be carved out for it. Trawling through email archives, past board reports, and blog entries, I see that coordinating Google Summer of Code has been a major focus, and that questions have been asked like How might we attract more technical writers to the ASF?. This seems like a similar outreach activity, intended to bring more people to the ASF and make it easier for them to contribute. The primary value would be in decreasing the time it takes for a company to go from user to contributor to committer-employer, incubator-source and/or sponsor. Well stated. That would be this document's value to the Apache Software Foundation directly, and provides justification for expending ASF resources to vet it and adopt it. Facilitating increased corporate contributions to the ASF also provides value to those of us who labor on ASF projects as developers, by increasing the demand for our services. I'm lucky -- I have a great job at a growing company where about 75% of my hours are spent on an ASF project. I would like more people to have jobs like mine, and if my fortunes were to change unexpectedly, I would like to be able to find another one like it. Extrapolating outwards for the sake of argument, increasing contributions to the ASF and to open source in general aids the software industry at large. To the extent that our industry competes with others within the broader economy, we are better off when we can pool resources. And it is to our advantage when software companies consumed by the creative destruction of capitalism leave something of value behind -- both in terms of raw code and developer track records. Nevertheless, the narrow interests of the company/organization must remain paramount as we draft this document. Companies should adopt this policy because it's a good deal for them: * It decreases costs. (They get to spend minimal time modifying a boilerplate document instead of drafting a custom document themselves.) * It lowers risk. (The policy was drafted by knowledgeable open source developers with the express goal of blessing common practice. As adoption spreads, developers will become increasingly familiar with how to comply with it effectively and its strengths and weaknesses will be probed at other companies.) * It lets employees and job candidates know where everyone stands, potentially yielding a recruiting advantage. Marvin Humphrey - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On Tue, Mar 22, 2011 at 09:07:40PM -0700, Henri Yandell wrote: Find a wiki and start documenting. :) I've started a page here: http://wiki.apache.org/general/OpenSourcePolicy So far, it contains materials from you, Ross, and myself. The permissions regime material involving supervisors was included but is expected to be modified; I'll change it out later if no one else beats me to it. Marvin Humphrey - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On 3/29/2011 5:52 PM, Marvin Humphrey wrote: In my opinion, it's important that the Policy make only one major distinction: between open source software and proprietary software. As a practical matter, advocating for particular technologies seems likely to alienate people at companies who have invested in competing technologies. Ideally, we would like this Policy to be as influential as possible, and to be adopted as widely as possible; anything that limits its audience is detrimental. Even advocating for particular licenses seems likely to to be a net negative. Keep in mind, that even open source and proprietary software often intersect. If the document wants to evangelize an 'all open' solution, so be it, this is your document :) But there are spaces where open source can supplement closed sources (think plug ins, extensions etc), or where closed projects might supplement open source development (think various code analysis utilities). Any document which helps increase the use of and contributions back towards open source by the corporate world will be a useful addition to the existing publications, so thanks for making this effort :) Bill - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On Tue, Mar 29, 2011 at 06:01:51PM -0500, William A. Rowe Jr. wrote: Keep in mind, that even open source and proprietary software often intersect. If the document wants to evangelize an 'all open' solution, so be it, I don't think it's desirable to advocate for all open, as it would potentially limit adoption. It's not necessary, either. Contribute a little, contribute a lot, this Policy will simply help your organization to interact with open source projects in an orderly and safe manner. this is your document :) I'll challenge that one.[1] :) It's already a collaborative effort which has been shaped by numerous authors and has taken on a form I did not anticipate. But there are spaces where open source can supplement closed sources (think plug ins, extensions etc), or where closed projects might supplement open source development (think various code analysis utilities). I don't think there's anything in the Policy itself. I made a change to one of the draft FAQ entries in response to your feedback, though. It is now explicitly agnostic about open source vs. proprietary solutions: http://wiki.apache.org/general/OpenSourcePolicy?action=diffrev2=3rev1=2 Marvin Humphrey [1] h/t: Henri :) - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On Mon, 21 Mar 2011 22:23 -0700, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Mar 17, 2011 at 02:40:31PM -0700, Keith Curtis wrote: I recommend separating things out into using free software versus writing free software. They're intimately tied, aren't they? One of the great freedoms of open source software is the ability to modify it -- whether that means a sysadmin hacking a broken installer until it works, a developer monkey-patching a Ruby module, or what have you. If you could read OSS but not modify it, it would be a lot less powerful. Using OSS becomes writing OSS almost right away. I think you overestimate the majority of developers. The bar to usage is downloading a resource, which is relatively easy. The bar to modification is at minimum downloading the source and building it, which is effort enough. Getting your changes accepted involves identifying the relevant community and engaging with it. This is something that many developers will neither find easy, nor feel inclined to do. I would say those that *are* inclined to contribute back are the exception. Upayavira So I suggest keeping those separate aspects in consideration. Convincing people to depend on Linux, Python, etc. (and giving back any bug / fixes to existing public codebases) is a relatively easy step and moves things in the right direction. It does seem like the policy should start with usage and progress through mailing list participation, minor contributions such as bugfixes, to ongoing development of major features. Marvin Humphrey - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On Mon, 21 Mar 2011 22:23 -0700, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Mar 17, 2011 at 02:40:31PM -0700, Keith Curtis wrote: I recommend separating things out into using free software versus writing free software. They're intimately tied, aren't they? Not necessarily. The point I'm getting at is that some people aren't even ready to take the step away from Windows, ASP.Net and towards LAMP. So I think that at least a preamble of a corporate policy ought to discuss why to depend on free software for the dependencies. It seems like an important building block on the way to making the case of why to write free software. -Keith
Re: Liberal corporate open source policies
On Tue, Mar 22, 2011 at 5:03 PM, William A. Rowe Jr. wr...@apache.orgwrote: This conversation seems to be moving sideways into nonsense. Open Source and LAMP have nothing to do with each other. There are a million ways to consume open source without touching a LAMP stack (some people even use apps... I mean, applications, which are neither 1. web based nor 2. mobile based. /shudder) Yes LAMP is one deployment model, so is WAMP, so is WIMP, so is... What about WAOA: Windows, Apache, Oracle, ASP.Net? I guess some might consider a solution like that no worse than any other but I think endorsing such a stack goes against a good policy. If you are going to make a policy, you should love the results it endorses. That is all I was trying to suggest. Regards, -Keith
Re: Liberal corporate open source policies
On Mon, Mar 21, 2011 at 01:01:24AM -0700, Henri Yandell wrote: Presumably this outline described procedures for obtaining clearance from management to work on open source projects? Depends how liberal you're talking. A liberal company would be more along the lines of: Let us know projects you work on. If anything terrifies us we'll let you know to back out and will add it to the 'please don't' list. It should be possible to accommodate a wide range of project clearance procedures using shared language. Something like this: * Permission must be obtained from a supervisor prior to contributing company IP to an open source project. * Permission may be granted for an employee to contribute to individual open source projects on an ongoing basis. * Employees who have received authorization for ongoing contributions must consult a supervisor when there is uncertainty as to whether IP should remain proprietary or be open sourced. What it takes to obtain said permission might vary widely across different organizations: managers might be empowered to grant permission directly, they might be required to engage the legal department on every single call, or anything in between. Where I think this liberal policy differs from more conservative policies is that it formally declares a procedure for ongoing permission to be granted where the individual developer is to be entrusted not to leak proprietary information. - we will honour all trademarks policies and licences relating to the projects This is more challenging than it sounds! The participating employees have to recieve sufficient training and guidance to execute the policy cleanly. If we assume the likely user of a liberal set of policies would be a startup, the main concern is in making sure no copyleft code ends up in a distributed product, and no network-copyleft code ends up 'networked' in. Startups tend to get strong advice to secure a few patents. Assuming they're taking that particular VC advice, then making sure staff know about the patents they have is very worthwhile and those areas can be forbidden for open source activities. That's a pretty small amount of required training. Draw a few architectural circles to pay more attention in, a few licenses to pay more attention to and discuss your patents internally such that employees know to avoid the space. That's an admirably concise description of the requirements, but it still seems to me that the knowledge a dev needs to understand and uphold those requirements is pretty substantial. How well do they need to grok copyleft, the FSF's position on derivative works, the Affero GPL, 3-clause vs. 4-clause BSD, etc? The internet is forever; they are representing the organization in an archived public venue. They had better know their stuff and take their responsibilities seriously. Nevertheless, the policy can be crafted to accommodate wildly divergent opinions on the subject. The policy should stipulate that all patches must be cleared by a direct supervisor unless the employee has been authorized to make ongoing contributions to a project. I mentioned above that different companies might have different procedures for granting permission; they might also have different *criteria* for qualifying an individual. Deny-by-default for patches seems like the only sensible rule; I doubt it will meaningfully obstruct ordinary usage of OSS, since as Upayavira asserted elsewhere in the thread, those inclined to give back will be the exception rather than the rule. Incidental contributions will inevitably slip through the cracks on user mailing lists and bug trackers, but that's just part of allowing your staff enough freedom to be productive users of OSS. Other small companies who aren't looking for a sale can afford to be more liberal. Non-project orgs for example (who I suspect would love such a liberal policy). (I suspect that should have read Non-profit orgs...) I hope that we don't have to craft a custom policy to accommodate the most lenient orgs. Perhaps they can just be more loose in their administration of the policy. So, here's my liberal, yet not non-existent, Open Source policy: * List of company products which require someone sign off on inclusion of Open Source unless under these licenses list permissive licenses. * List of licenses which require someone sign off on use anywhere: list. * List of company patents. * List of projects (or type of project) to avoid for specified reason. * Company email address to mail when contributing to a project (having checked above project-avoid list). * Company email address to mail to get CCLAs signed. Interesting. I was imagining a boilerplate document containing statements similar to what Ross put in his email. I hadn't thought of filling in the blanks like that -- but on close inspection, I don't see any incompatibilities. I'm not sure if it's a misguided priority or
Re: Liberal corporate open source policies
On 3/22/2011 7:19 PM, Keith Curtis wrote: I guess some might consider a solution like that no worse than any other but I think endorsing such a stack goes against a good policy. If you are going to make a policy, you should love the results it endorses. That is all I was trying to suggest. See, I guess that's where I think this discussion has gone off the rails for an Apache Software Foundation discussion. In large measure, ASF participants are pragmatists. This isn't a culture you might find in the Gnome or other FSF projects which seek to win an entirely free (as in beer) ecosystem. Linus himself is exempted from this gross over-generalization, as he does not come down against allowing vendors to interface closed source with his kernel or running his kernel on top of closed systems, so I'd place him in this same pragmatist culture. The ASF itself for its infrastructure runs mostly atop FreeBSD, with some Linux, Solaris, and Windows in this mix, mostly sliced by VMware for the virtual boxes in combination with Solaris zones. Of course much of the software that the infra team hosts is OSS, but not exclusively. And in the ultimate nod to pragmatism, the ASF is happy to run donated software in lieu of purchasing licenses. You might find this is orthogonal to our public letter to Sun with respect to Java, the TCK and the Apache Harmony project. But this was not; the letter simply sought the terms promised by Sun and their compliance to the JSPA which Sun authored. Had those promises and JSPA contract not existed, the ASF would have been just as likely to never attempt the Harmony project, yet it was still developing code in Java. The ASF still publishes open source which runs on proprietary languages (Java) and proprietary operating systems (Solaris, Windows) without any apologies or remorse. Advocacy for open source and/or completely open solutions is fine, but the two are not identical. And until there is an open chipset design for their target architecture, the entirely 100% open solution champions are being disingenuous, IMHO :) - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
Hi all; On Tue, Mar 22, 2011 at 7:14 PM, William A. Rowe Jr. wr...@apache.orgwrote: On 3/22/2011 7:19 PM, Keith Curtis wrote: I guess some might consider a solution like that no worse than any other but I think endorsing such a stack goes against a good policy. If you are going to make a policy, you should love the results it endorses. That is all I was trying to suggest. See, I guess that's where I think this discussion has gone off the rails for an Apache Software Foundation discussion. In large measure, ASF participants are pragmatists. This isn't a culture you might find in the Gnome or other FSF projects which seek to win an entirely free (as in beer) ecosystem. Linus himself is exempted from this gross over-generalization, as he does not come down against allowing vendors to interface closed source with his kernel or running his kernel on top of closed systems, so I'd place him in this same pragmatist culture. I try to be pragmatic as well but free software is better and cheaper and so these worthy goals and reasons should be reflected in the policies on a topic. You might find this is orthogonal to our public letter to Sun with respect to Java, the TCK and the Apache Harmony project. But this was not; the letter simply sought the terms promised by Sun and their compliance to the JSPA which Sun authored. Had those promises and JSPA contract not existed, the ASF would have been just as likely to never attempt the Harmony project, yet it was still developing code in Java. Since I'm off-topic, I'll mention that I wrote a chapter in my book on why Java should be abandoned. (http://keithcu.com/wordpress/?page_id=2228) Whatever you are working on with Oracle I hope is not distracting you. Sun never invested nearly as much into Java as MS did in .Net, and I can't imagine Oracle improving things. I live in the world of PHP, Python, and the Linux desktop, so don't run much ASF technologies I think you guys should make a goal of moving towards the Python community: http://scipy.org/Topical_Software Note this can be done in a pragmatic way. The point is to first have goals and then figure out how to get there. If you have pragmatic goals you are aiming too low. It is important to be practical about means but not about the ends. Advocacy for open source and/or completely open solutions is fine, but the two are not identical. And until there is an open chipset design for their target architecture, the entirely 100% open solution champions are being disingenuous, IMHO :) I have found that the hardware doesn't matter. A computer is happy to add 0 + 0 billions of times per second all day long. It is the software that matters. And the most important software is the programming language that you write your other software in. -Keith P.S. Here is a chunk of something I wrote about programming languages that is relevant here: --- http://keithcu.com/wordpress/?p=1691 The most popular free computer vision codebase is OpenCV, but it is time-consuming to integrate because it defines an entire world in C++ down to the matrix class. Because C/C++ didn’t define a matrix, nor provide code, countless groups have created their own. It is easier to build your own computer vision library using standard classes that do math, I/O, and graphics, than to integrate OpenCV. Getting productive in that codebase is months of work and people want to see results before then. Building it is a chore, and they have lost users because of that. Progress in the OpenCV core is very slow because the barriers to entry are high. OpenCV has some machine learning code, but they would be better delegating that out to others. They are now doing CUDA optimizations they could get from elsewhere. They also have 3 Python wrappers and several other wrappers as well; many groups spend more time working on wrappers than the underlying code. Using the wrappers is fine if you only want to call the software, but if you want to improve the underlying code, then the programming environment instantly becomes radically different and more complicated. There is a team working on Strong AI called OpenCog, a C++ codebase created in 2001. They are evolving slowly as they do not have a constant stream of demos. They don’t consider their codebase is a small amount of world-changing ideas buried in engineering baggage like STL. Their GC language for small pieces is Scheme, an unpopular GC language in the FOSS community. Some in their group recommend Erlang. The OpenCog team looks at their core of C++, and over to OpenCV’s core of C++, and concludes the situation is fine. One of the biggest features of the ROS (Robot OS), according to its documentation, is a re-implementation of RPC in C++, not what robotics was missing. I’ve emailed various groups and all know of GC, but they are afraid of any decrease in performance, and they do not think they will ever save time. The transition from brooms to vacuum cleaners was
Re: Liberal corporate open source policies
On 3/22/2011 10:24 PM, Keith Curtis wrote: I try to be pragmatic as well but free software is better and cheaper and so these worthy goals and reasons should be reflected in the policies on a topic. the policies, hmmm. Those would be 'your policies'. Which may or may not be what Marvin is attempting to compose. Your form of evangelism could be counterproductive to the audience who Marvin is addressing. Unless you are prepared to show data on better as well as cheaper, this is all a very hollow statement. You are certainly welcome at the ASF no matter if you have a FLOSS-centric or OSS-centric approach to source code, but enough proselytizing already. community@ is a gathering of minds, not a divisive exclusionary zone :) - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On Thu, Mar 17, 2011 at 6:44 PM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Mar 17, 2011 at 09:22:57PM +, Ross Gardler wrote: This is an interesting question. I was recently asked to help with exactly this issue and I also struggled. Perhaps we might consider working up an example policy ourselves? Cool idea :) It is in the interest of the ASF to make it as easy as possible for companies to contribute to our projects. Creating a company open source policy has a cost. If we provide a template policy that is rock solid with regards to using and contributing to ASF projects at the least -- and hopefully open source at large -- we can bring that cost down. In addition, if a company adopts the sample policy verbatim, it becomes easier for a candidate to assess whether they would be happy there. I can see a web startup with a limited budget taking the easy route and adopting an ASF-crafted open source policy verbatim. I don't know, though -- I'm just an ASF committer on an Incubator project, so I don't know whether any part of the ASF, if any, would take on such a project or in what form. It's a meritocracy; by stepping up with this email you've already started the project. Stay quietly persistent and keep it going (and I don't see why it can't stay on community@). Find a wiki and start documenting. :) Here's what I told the company that asked me about this: A healthy policy would look like the outline you describe, some (off the top of my head) statements that would be appropriate are: Presumably this outline described procedures for obtaining clearance from management to work on open source projects? Depends how liberal you're talking. A liberal company would be more along the lines of: Let us know projects you work on. If anything terrifies us we'll let you know to back out and will add it to the 'please don't' list. - we will honour all trademarks policies and licences relating to the projects This is more challenging than it sounds! The participating employees have to recieve sufficient training and guidance to execute the policy cleanly. If we assume the likely user of a liberal set of policies would be a startup, the main concern is in making sure no copyleft code ends up in a distributed product, and no network-copyleft code ends up 'networked' in. Startups tend to get strong advice to secure a few patents. Assuming they're taking that particular VC advice, then making sure staff know about the patents they have is very worthwhile and those areas can be forbidden for open source activities. That's a pretty small amount of required training. Draw a few architectural circles to pay more attention in, a few licenses to pay more attention to and discuss your patents internally such that employees know to avoid the space. Other small companies who aren't looking for a sale can afford to be more liberal. Non-project orgs for example (who I suspect would love such a liberal policy). So, here's my liberal, yet not non-existent, Open Source policy: * List of company products which require someone sign off on inclusion of Open Source unless under these licenses list permissive licenses. * List of licenses which require someone sign off on use anywhere: list. * List of company patents. * List of projects (or type of project) to avoid for specified reason. * Company email address to mail when contributing to a project (having checked above project-avoid list). * Company email address to mail to get CCLAs signed. Hen - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On Thu, Mar 17, 2011 at 02:40:31PM -0700, Keith Curtis wrote: I recommend separating things out into using free software versus writing free software. They're intimately tied, aren't they? One of the great freedoms of open source software is the ability to modify it -- whether that means a sysadmin hacking a broken installer until it works, a developer monkey-patching a Ruby module, or what have you. If you could read OSS but not modify it, it would be a lot less powerful. Using OSS becomes writing OSS almost right away. So I suggest keeping those separate aspects in consideration. Convincing people to depend on Linux, Python, etc. (and giving back any bug / fixes to existing public codebases) is a relatively easy step and moves things in the right direction. It does seem like the policy should start with usage and progress through mailing list participation, minor contributions such as bugfixes, to ongoing development of major features. Marvin Humphrey - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Liberal corporate open source policies
On 17/03/2011 20:44, Marvin Humphrey wrote: There's a fair amount of information out there on establishing corporate open source policies, but not much that seems appropriate for the company profile I'm interested in: * Web startup. * Software based around an open source ecosystem. * Actively recruits open source contributors to staff the engineering department. It doesn't have to be a web startup, but that's a good example. This is an interesting question. I was recently asked to help with exactly this issue and I also struggled. Any pointers towards sample policies or articles that help achieve these objectives? Or commentary on what aspects of typical open source polices noticeably constrain or don't constrain participation? Here's what I told the company that asked me about this: A healthy policy would look like the outline you describe, some (off the top of my head) statements that would be appropriate are: - we're a business, our goal is to serve our customers - sometimes we can do that best by collaborating on appropriate open source solutions - we will participate as and when we feel it is appropriate for our business and the broader community - we will encourage our development staff to lead our engagement with open source projects - we will do so with full respect for other members of the community - we expect to have only as much influence over a project as our contributions deserve - we will honour all trademarks policies and licences relating to the projects - we will seek to ensure the ongoing sustainability of the projects through our positive and collaborative contributions I'd be really interested to hear peoples comments or pointers to real policies out there. Ross - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
