Simon, When I worked at IBM I worked on the internal architecture review board one of the questions we had to deal with was the licensing question (i.e. what license was any open source licensed under). The upshot was that legal had to approve the license. Some were already approved and variations need to be verified by legal via a self reporting process. The net result is that if the license is approved the software was approved for use on the IBM infrastructure. If you are producing a product there may be other issues.
On Thu, Sep 13, 2012 at 4:37 PM, Simon Helsen <[email protected]> wrote: > Andy, > > I'll bring this back to our legal, but they told me that apparently, when > a project in Apache releases, Apache has done the appropriate internal > legal review and makes certain guarantees. I do not know if that "internal > legal review" happens in practice, but for IBM that makes a big > difference, probably in terms of liability. Perhaps you are trying to say > that each produced build, and by that, I mean the sources packaged in that > build (not some PGP-signed binaries), are implicitly "cleared". If that is > true, things would be easier for us. > > I'll follow-up on this > > Simon > > > > From: > Andy Seaborne <[email protected]> > To: > Simon Helsen/Toronto/IBM@IBMCA > Cc: > [email protected] > Date: > 09/13/2012 11:20 AM > Subject: > Re: 2.7.4 release? > > > >> I definitely agree that the concept of RC cycles is good in principle, >> but I don't know if lightweight will do for us. As I explained before, >> we can only get comprehensive testing done with versions of Jena which I >> can safely deliver in our main source control stream. Because we publish >> milestone builds publically (on jazz.net if you're interested), each >> milestone needs legal approval for 3rd party libraries. I was told that >> for Apache libraries we can only do this for releases because of certain >> IBM assumptions about Apache releases (don't ask me what, IBM just has a >> certain relation with Apache which makes this the way it is). And this >> process fortunately does not take very long. >> >> In other words, if you introduce an RC, it would only help us if you >> perform the same tasks as you do with a regular release, make it >> available on the website like you do with a regular release, but just >> use a different name to indicate that it may not be mature. It would be >> a bit of a naming game, but it would take away the effect that you come >> out with a possibly buggy release, yet you give your consumers a chance >> to fully adopt and test the RC > > We use Continuous Integration - the nightly build runs all the tests > every time. We also use have a "green line" policy (we haven't > discussed this per se but it is how things run) whereby trunk always > works. So, in that sense, every nightly build is a uniquely labelled RC. > > As to releases - from Apache, only the source code has real status. The > maven binaries are PGP-signed by the person doing the build and not > Apache. "Open source" is both "open" (you can change it) and "source" > (not binary). A formal release is a vote on a specific source-release > artifact (which for Jena is a snapshot of SVN). > > A top level project has many degrees of freedom but this isn't one of > them. Sometime in the future, formal binaries may happen - OpenOffice > want to release ASF-signed binaries but it will involve getting > authenticated build systems in place. It's quite complicated because of > the implications and assurances that formal signing brings. > > Andy > >> >> thoughts? >> >> Simon >> >> >> From: Andy Seaborne <[email protected]> >> To: [email protected] >> Date: 09/13/2012 07:27 AM >> Subject: Re: 2.7.4 release? >> >> >> ------------------------------------------------------------------------ >> >> log.info("ABCDEFGHIJKLMNOP") ; > >> >> On 12/09/12 20:49, Simon Helsen wrote: >> > On the testing front, we just got one of our clients to run a >> > scalability test (meaning they run with a large starting repository > and >> > fire up multiple users to perform read/write activities) and they >> have not >> > observed any regressions compared to 2.7.1 and a slight overall speed >> > improvement (something like 6%, not stellar, but most importantly not >> > slower) >> >> Good to know. The crash-restart is the thing that's hardest to test for >> in the development test suite so feedback on that would be particularly >> useful. That's why a (lightweight) RC cycle struck me as important or >> else we'll end up in some kind of odd/event minor release cycle (odds >> are effectively RC's, evens are stable releases). Other people have >> been picking up the dev release as well. >> >> Andy >> >> >> > > > -- I like: Like Like - The likeliest place on the web Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
