Sorry to chime in so late, but I have a question/concern about using the word 'Network'.
What about a situation where the user is utilizing the code or data stored on a machine that they do not own, but where they are sitting at that same terminal? For instance, I've thought of a "Free as in Freedom" cafe where customers could rent time on computers to use Free Software or rent a mini-theatre room where they could watch movies that are under a license permitting such performances. I would want those customers to be guaranteed an opportunity to make "at cost" copies of that code and data, but notice it wouldn't be over a network. Thanks, Patrick On Thu, Jul 10, 2008 at 12:31 PM, Rufus Pollock <[EMAIL PROTECTED]> wrote: > On 09/07/08 20:04, Mukundan R wrote: >> Dear all, >> >> Support for simple "Open Service" > > Just when it looked like we had consensus! That said, I think that Open > Network Service Definition is still the front-runner. In the interests > of closing this out if I don't hear any more comments by tomorrow > evening I'm going to assume that overall everyone is happy to go with ONSD. > >> agree with these very valid points. Addressing these issues will truly >> make it "open" which is better than "free" and why to confuse with a >> "free/open"? >> >> A data which has been "approved" by the provider for use in other places >> and other ways is more open. >> >> A few clarifications: >> How do we define personal data? > > A good question. I guess we could go with how it is traditionally > defined as data which provides information about you and which you would > expect to not be provided to a third party without your permission. > However I'm sure we could do better -- though I think for the purposes > of the definition as it stands, given that personal data must be > provided to its 'owner', simple 'personal data' will suffice. > >> The definition assumes API's to be by default Open. what would happen if >> the source was LGPL based? Do API's still remain open? > > I'm not sure how LGPL would make a difference here. No one could make > the APIs proprietary without violating the underlying F/OSS licence. > > Regards, > > Rufus > > _______________________________________________ > okfn-discuss mailing list > [email protected] > http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss > _______________________________________________ okfn-discuss mailing list [email protected] http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss
