decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Header copyright is not that moot! | 104 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Header copyright is not that moot!
Authored by: Anonymous on Saturday, April 21 2012 @ 11:36 AM EDT

Just look at the GNU LGPL clause that specify how much header code is fair use (the 10 line rule which makes LGPL useless for some heavily inlined libraries).

[ Reply to This | Parent | # ]

Hmmm, I just had thought
Authored by: Anonymous on Sunday, April 22 2012 @ 02:02 AM EDT
That's a viable observation, but things are not exactly that way. For example,
if you have a mixed Scala/Java project with mutual dependencies between Scala
and Java source code, then Scala compiler receives both Scala and Java files on
input. It can NOT compile Java code though (typically javac is later called
separately by Makefile, receiving as input Java source code and bytecode
produced by Scala compiler). The trick is - Scala compiler performs just partial
parsing of Java source files, extracting class and method signatures -
basically, the API of the Java part of the project (or third party library).

Notice that with this approach, one could feed Scala compiler with Java files
that contain no implementation code at all; only class/method signatures are
used. And then the resulting program could be used with any implementation of
that Java code, provided that it has compatible (not even necessary same)
class/methods signatures.

Alternatively, Scala compiler could extract the API info of Java based part of
the project (or Java libraries) from already compiled class files (provided you
can get them before compiling Scala code). And Java compiler works exactly the
same way with regard to third party Java libraries (including Java SE standard
API). Bytecode is not text file already, but principle is exactly the same - all
that compiler cares about is the library programming interface/API, while the
actual implementation code is not even parsed from bytecode - for purposes of
compiling it is sufficient to have library classes where all the implementation
code is replaced with do-nothing statements, or stubs returning bogus values.
Then, again, at runtime you could use any implementation or version of the
library, as long as API is compatible.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )