felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <Peter.Kri...@aQute.se>
Subject Re[2]: Fixed bug in class loading
Date Thu, 13 Apr 2006 19:05:51 GMT
JM> I'm not a lawyer so will neither wrestle or argue legal points.  Some
JM> non-legal points
JM> - Signing will make changing JARs problematic.
If you wrap them, you do not touch the signatures.

JM> - Updates also will force you to retweak.
Yes, but that is true for any solution that requires additional

JM> - If the JARs are delivered as part of something else you may not have a
JM> chance to modify
But if you need to provide new metadata, you need to do something??

JM> - User permissions on the machine may not allow for modification (we have
JM> scenarios where we run off CDs and don't use any local storage)
Well, then you can't support native code, getDataFile(), caching, how
many bundles run in such a restricted env?

Kind regards,

     Peter Kriens
JM> Jeff

JM> Rob Walker <robw@ascert.com> 
JM> 04/13/2006 11:47 AM
JM> Please respond to
JM> felix-dev@incubator.apache.org

JM> To
JM> felix-dev@incubator.apache.org
JM> cc
JM> Jeff McAffer/Ottawa/IBM@IBMCA
JM> Subject
JM> Re: Fixed bug in class loading

JM> Does anyone have a real example where a commercial software vendor has
JM> actually refused to allow someone to adjust the bundle Manifest of their
JM> licensed bundle so that it would work better in an OSGi environment?

JM> As a commercial software vendor, I can quite honestly say:

JM>     * We include numerous 3rd party JARs, some commercial, in our OSGi
JM>       bundle set and in no case has any software vendor refused to allow
JM>       us to change or add to their manifest even if their license did
JM>       not explicitly grant this right
JM>     * Frankly we could care less if someone wants to modify bundle
JM>       manifests of any of our JARs, even if doing so is against the
JM>       letter of our license. As long as they are making legal use of our
JM>       software, and paying us any requisite fee we're happy to have them
JM>       as a customer. Ok, if their changes break something we might not
JM>       cover helping them fix it under standard support - but aside from
JM>       this, the widest possible legal use of our software is fine with us.

JM> Simply changing a manifest (esp. the import / export parts) may not be
JM> strictly legal - but I suspect most vendors won't object if you explain
JM> your needs and ask for permission. You wouldn't be getting any usage or
JM> redistribution rights out of doing so, but you'd be making use of their
JM> software which is what most vendors want!

JM> Regards

JM> -- Rob

Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

View raw message