OSL 2.0 and linking of libraries

Peter Prohaska pitrp at wg78.de
Fri Apr 2 05:14:42 UTC 2004

On Thu, Apr 01, 2004 at 02:46:01PM -0500, jcowan at reutershealth.com wrote:
> Lawrence E. Rosen scripsit:
> > You don't need the clarification. Simply linking a program against a library
> > or loading machine readable code compiled from source code doesn't create a
> > derivative work of software. 
> Well, that may turn out to be the case.  But there's enough dispute on
> the point that I wish you'd introduce an option into the OSL allowing
> the licensor to include or exclude such situations.  The fact that
> people believe (even though there's no empirical evidence for it)
> that the GPL prevents MPL-style forking by creating a Larger Work in
> fairly well-defined situations has been important to the well-being of
> many projects.

As this thread turns out again, I think, there is currently no way to know if
clarification is needed or not.

Since the copyright/license issue is a day to day problem in the life of
a developer, I would suggest to look at the problem from a users

The Creative Commons are a good example of what is practial licensing

(warning, lenghty and very biased by personal experience)

I think there are a few groups that need to be addressed:

a) initial author of the software (let's call him "creator")
b) someone contribution to the project (let's call him "contributor")
c) another developer using the code (let's call him "code user")
d) someone creating "real" derivative work (let's call him "derivator")
e) someone just using the resulting software - knowingly or not, because
   he might trust a distributor (let's call him "application user")

What do they want, need or like:

To keep the mail reasonable, i will only address the view of the
creator. The relations to the other groups are clear to see, i hope.

a) The Creator (who actually wants to share his code ;)

a.1) Find and understand a licence that fits his needs.
a.1.1) Where can i get advice?
- no easy to understand advice available
- read them all and better be a native speaker
=> license is often chosen out of pupularity (not good)

a.1.2) Can I adapt a license without creating a new one?
- If someone get's my code and reads GPL, he will assume that he
  may not link against it in a commercial project
- If he reads LGPL, he assumes that he may
- Annotations / clarification statements are not expected
=> If some extension mechanism is need, it should be well defined so
   that everyone who reads i.e. MY-PUBL should expect two files.
   One containing "MY-PUBL" and one containing something like
   "Clarifications on MY-Publ...consider linking...
   The license itself is included as "copying.my-publ"
   Even better would be one "glue" file and n copying files containing
   "license modules".
=> since i want people to use my code, it is essential that understanding
   the license does not become a stepping stone for others that want to
   reuse the code. That can best be achieved by using well known licenses
   and to collect project special adaptions in a well known location.

a.2) Apply license to my code.
a.2.1) Where can i find advice?
- hard to find, again
- for the GPL: in the license or on the FSF pages
- for the Creative Commons: online, easy to understand
=> A license that addresses source code should always be accompanied
   with information on how to apply it (an uri is sufficient, i think)
=> reference uris should include the version number of a licence and
   there should optionally be a "latest" uri.

(note that if you go to http://www.opensource.org/site_index.php and
click on the "Open Software License" link, you get version 1.0 as
http://www.opensource.org/licenses/osl.php . If you look at the bottom of
the page, you suddenly realise that there is a version 2.0 under
http://opensource.org/licenses/osl-2.0.php . Not very sane behaviour, i

a.2.2) What do i have to add to my code?
- is "For copyright see..." enough?
- do i need to include the whole license in every file?
- do i have to edit leagel code? IANAL!
=> Templates needed. Examples needed.
=> Providing RDF fragments and images like CC seems to be a good idea.
   (anyone installed the ccMoz plugin? It's worth a try for all wozilla

a.2.3) Can I automate the copyright application?
- can i create a template files tree that i can reuse for any future
  project without needing to change them?
- can a fellow programmer copy the license without checking the whole
  leagel file for project specific changes?
- I never want to edit legal code because i might break it
=> License with a name like "OSL" sould _not_ have options, neither should
   it contain your name.
=> Creative Commons approach to options is reasonable because each
   version has it's own name and it is made clear from the bottom up that
   (CC) means a set of licenses

1) It could be a good idea to contact the CC folks. Source code
   licensing is at least in their FAQ section.
   That clearly shows that other people than me are also interested in
   easing the selection, application and promotion of source code licenses
   in a userfriendly way. The CC-GPL / CC-LGPL aproach seems not too
   bad. No matter how the image looks, the availability of both in the
   "choose license" section is really worth something.

2) Please let us not create licenses with options in the sense that
   "the" license text varies from one project to another.

3) Let's discuss if the license should be modularised or if it is
   possible / makes sense to define a standard for "clarification"

4) Independent of contacting the CC folks, it would be greate to have a
   RDF template available (using the CC RDF) for advertising on

5) Having a general section on "how to apply you license" on the web
   would really make it a better web (world).

If you are still awake, thanks for reading and my best whishes,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20040402/ba17fe73/attachment.sig>

More information about the License-discuss mailing list